前言
最近在对 18 级的同学们进行培训，正好讲到 jinja2 这一块，在进行了仔细的梳理之后，忽然发现 jinja2 这种渲染模式与国内目前的潮流–前后端分离所不符合。
所以作为一个负责的老学长，我写下这一篇，来给 18 级的学弟学妹们介绍、分析一下，免得入了歧途。
传统的开发模式
前端写好静态的 HTML 页面交付给后端开发。静态页面可以本地开发，也无需考虑业务逻辑只需要实现 View 即可。
后端使用模板引擎去套模板，当年使用最广泛的就是 jsp，freemarker 等等，同时内嵌一些后端提供的模板变量和一些逻辑操作。
然后前后端集成对接，遇到问题，前台返工，后台返工。
然后在集成，直至集成成功。
前后端分离的开发模式
前后端分离并不只是开发模式，而是 web 应用的一种架构模式。在开发阶段，前后端工程师约定好数据交互接口，实现并行开发和测试；在运行阶段前后端分离模式需要对 web 应用进行分离部署，前后端之前使用 HTTP 或者其他协议进行交互请求。
客户端和服务端采用 RESTFul API 的交互方式进行交互
前后端代码库分离
如何分离
对于 node.js 这类可以直接在前端进行处理的,由前端负责 view 和 controller 层,后端只负责 model 层，业务处理与数据持久化等
但是对于我们所使用的纯粹 flask 开发,MVC 就全部交由后端来负责,前端只需要完成静态页面的开发即可.
如何取舍
如何取舍的问题归根到底是如何分工的问题
比如工作室的项目,在新的成员加入进来之前,我在负责了前后端的全部工作,所以我选择了耦合度较高的前后端结合开发模式.
这样的好处是开发迅速,而且高耦合往往意味着高效率.
但是这对后期接手的人不太友好,因为并不是每一个人对前后端都有所了解.
所以在后期,工作室的其他人加入进来之后,我就选择了前后端分离的开发模式.
注意,低耦合度的 API 交互的形式比直接渲染,数据的冗余度要高很多.如果 API 交互过于频繁,会给服务器造成很大的压力.
并且，解耦合后，可能会出现一些安全性的问题，要注意应对恶意请求。
再往后面 API 会讲一下 API 设计的相关内容.
(补充)前后端分离架构后的优点
为优质产品打造精益团队
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。
提升开发效率
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
完美应对复杂多变的前端需求
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。
增强代码可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
后记
又是不知道干了啥的一天
于学姐冲冲冲
