- 服务器渲染：服务器生成整个的 HTML 页面（数据部分），CSS 和 JS 的部分是在浏览器端执行的。
- 前后端分离：后端偏向于提供单纯的API接口，前端就是调用API接口进行展示和业务调用。
在以前传统的网站开发中，前端一般扮演的只是切图的工作，只是简单地将 UI 设计师提供的原型图实现成静态的 HTML 页面，而具体的页面交互逻辑，比如与后台的数据交互工作等，可能都是由后台的开发人员来实现的，或者是前端是紧紧的耦合后台。比如，以前淘宝的 Web 基本上都是基于 MVC 框架 webx，架构决定了前端只能依赖后端。所以他们的开发模式依然是，前端写好静态 demo，后端翻译成 VM 模版。
而且更有可能后台人员直接兼顾前端的工作，一边实现 API 接口，一边开发页面，两者互相切换着做，而且根据不同的 URL 动态拼接页面，这也导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢，而且代码难以维护。而前后端分离的话，则可以很好的解决前后端分工不均的问题，将更多的交互逻辑分配给前端来处理，而后端则可以专注于其本职工作。而前端开发人员则可以利用 NodejJS 来搭建自己的本地服务器，直接在本地开发，然后通过一些插件来将 API 请求转发到后台，这样就可以完全模拟线上的场景，并且与后台解耦。前端可以独立完成与用户交互的整一个过程，两者都可以同时开工，不互相依赖，开发效率更快，而且分工比较均衡。
但是我们怎么才能知道，是不是需要这样的架构呢：页面交互是否复杂 ？是简单的提供页面给用户浏览？或者想要支持复杂的用户操作？是否需要搜索引擎优化？如果需要的话，那么从一开始我们就需要考虑后端渲染。能提升开发效率吗？如果不能有效的提升开发效率，为什么要作死呢？是否会提供 API 给 APP？如果我们已经有一个 API 提供给 APP，那么要做这件事就很容易了。如果未来会有的话，那么我们更应该尝试去分离。前端的修改是不是非常频繁？如果不需要经常修改的话，那么这种优化便没有优势。
当我们决定需要前后端分离时，我们仍然还需要面对一系列的问题： 是否足够的安全？如果我们设计出来的架构不够安全，那么这一系列的操作都是白搭。我们怎么去存储用户数据，使用 LocalStorage 的话，还要考虑加密。采用哪种认证方式来让用户登录，并保存相应的状态？是否有足够的技术来支撑前后端分离？有没有能力创建出符合 RESTful 风格的 API？是否有能力维护 API 接口？当前端或者后台需要修改接口时，是否能轻松地修改。前后端协作的成本高不高？前端和后台两个团队是不是很容易合作？是不是可以轻松地进行联调？前后端职责是否能明确？即：后台提供数据，前端负责显示。是否建立了前端的错误追踪机制？能否帮助我们快速地定位出问题。
参考文献
[1] 浅谈WEB前后端分离
[2] 前后端分离扫盲
网友评论