什么是前后端分离
每个人对于前后端分离的理解都不太一样,大多数人会从物理层做区分,认为客户端的部分是前端,服务器端的部分是后端。但是,更为准确的分法是从职责上区分:
- 负责交互与展示的部分为前端
- 提供数据,处理业务的部分为后端
前后端分离意味着,前后端之间只通过API交互。从此,后端选用的技术栈不影响前端。当后端开发人员选择 Java 的时候,我可以不用 JSP 来编写前端页面,继续使用我的 React 又或者 Vue。而我使用 React 时,也不影响后端使用某一个框架。
前后端分离是在于技术架构上,而不是组织/流程、职位/工种的分离。所有组织/流程、职位/工种的限定,是为了更好的协作,而不应该限制人能力的发挥。如果人的能力强,当然可以全栈开发。且小团队肯定效率更高。反过来,跨部门联调这种事情,必定非常低效,且多后患,应极力避免。
为什么要前后端分离
-
提高工作效率,分工更加明确
前端只关注前端的事,后端只关心后端的活,两者开发可以同时进行。在后端还没有提供接口的时候,前端可以先通过Mock的方式模拟接口数据。页面的增加和路由的修改也不必再去麻烦后端,页面模板可以重复使用,开发更加灵活。
-
性能提升
前端页面可以按需加载,服务器也不需要解析前端页面,在页面交互及用户体验上有所提升。
-
降低维护成本
页面的调试不再需要后端人员的参与,可以非常快速的定位及发现问题所在,代码重构及可维护性增强。
需要明确一点,并非所有的项目都需要前后端分离。前后端要不要分,怎么分,是由具体业务决定的。前后端分离的最终目的还是为了提高效率,所以如果影响效率,不分也罢。
下面列举一些推荐进行前后端分离的场景:
- 网站需要跨设备兼容
- 网站展示方式变换频繁
- 页面交互比较复杂
- 不需要搜索引擎优化(SEO)
- 有专业的前后端团队
- 有一套合理/可升级/客户端友好的API
当我们决定使用前后端分离时,我们仍然需要解决一系列的问题:
- 接口的安全性是否足够
- 采用哪种认证方式
- 如何存储用户状态
- 是否有明确的API文档
随着前端技术的发展和迭代,前端MV*框架应运而生,利用目前主流的前端框架,如React、Vue、Angular等我们可以轻松的构建起一个无需服务器端渲染就可以展示的网站,同时这类框架都提供了前端路由功能,后台可以不再控制路由的跳转,将原本属于前端的业务逻辑全部丢给前端,这样前后端分离可以说是最为彻底。
前后端分离的实现对前端人员的要求会上升一个层次,前端需要处理服务器返回的各种数据格式,还需要掌握一系列的数据处理逻辑、MVC思想和各种主流框架。
常见的前后端分离方案
SPA
使用目前主流的前端框架开发,由前端路由的方式代替后端的 controller,页面的展现完全靠JavaScript控制,使用 restful api 实现与后端的数据交互。
SPA 是一个可以解决前后端分离的有效方案,适用于无 SEO 要求的项目。
Node.js 中间层
最早见于淘宝的前端团队在14年4月份提出的中途岛(Midway Framework)架构中
参考资料
实践中的前后端分离
Web 前后端分离的意义大吗?
前端工程师你真的懂前后端分离是什么意思吗?
我们为什么要尝试前后端分离