你是小阿巴，刚入职的全栈程序员。
所谓全栈，就是 全干 ，整个网站项目的后端和前端都由你一个人负责开发。
当用户打开一个网站，能直观看到、可交互操作的界面，就是前端。
而当用户点击操作按钮后，触发的操作验证、数据查询、业务逻辑处理等种种 "看不到" 的操作，都由后端来完成。
本文对应视频版：https://bilibili.com/video/BV1AasqzWEj5
你使用的开发技术是比你年龄都大的 JSP，它的特点是把前端 HTML 网页代码和后端 Java 代码混在一起写。
刚开始项目代码不多的时候，你写的很舒服。
但随着项目越做越大，更多同事加入了这个项目的开发，你也渐渐发现了几个问题。
-
代码混乱难维护：前端后端代码纠缠在一起，不利于阅读，也不利于排查 Bug。
-
团队协作困难：你在改前端样式，同事在改后端逻辑，经常改着改着就冲突了。
-
人员要求更高：开发人员必须同时学习前端和后端技术，今天写 CSS 调样式，明天写 SQL 查数据库，根本忙不过来。
-
部署效率低下：由于前端后端写在一起，哪怕改个按钮颜色都要重新编译部署整个项目。
受这些问题的影响，项目开发效率越来越低，Bug 却越来越多，你压力山大、发如雨下。
老板看出了你毛儿的不易，给公司请来了一位新的技术导师，号称 "全栈冤种" 的鱼皮。
鱼皮看了看你的项目，摇了摇头：连前后端分离都不做么？
你疑惑地问：前后端分离？没听说过。
这时，你的同事阿土申插嘴道：我知道啊！我们现在把前端静态文件放在 static 文件夹，JSP 代码放在 jsp 文件夹，这不就是前后端分离吗？
鱼皮皱眉：那只是文件夹分离，不是真正的前后端分离。
阿土申不服：鱼皮老狗，那你说说用什么技术才算是前后端分离？
鱼皮笑道：前后端分离可不是某种特定的技术，而是一种 架构 思想。
看看你们现在的项目，用户访问网站时，是由后端服务器接收请求，然后在后端查询数据并拼接到 HTML 网页模板中，生成完整的网页，最后再返回给用户。
显然，后端承受了太多！
而如果改造为前后端分离：
-
前端专注于用户界面的呈现和交互逻辑
-
后端专注于数据处理和业务逻辑，不涉及界面代码和网页生成
-
用户在前端进行操作时，前端通过 API 接口 向后端发送请求，由后端处理操作并返回数据给前端，由前端完成数据的最终展示。
你不明觉厉：可是这样做有什么好处呢？
鱼皮指着你之前列出的问题说：前后端分离就是专门解决这些痛点的！
1）首先是 代码分离 ：将前端代码和后端代码完全分开，最好是 2 个独立的项目
2）代码分离后，就可以 开发分离 ：前端和后端程序员可以同时干活，互不干扰。
3）还可以 部署分离 ：前端和后端项目各自独立部署，后端出了问题或者修改了逻辑，不用重新部署前端。
4）做到前面 3 个分离后，我们便能实现前后端分离的本质 ------ 职责分离 ，专业的人干专业的事情，各自发挥特长，整体效率自然更高。当然最主要的是，后端出了问题，前端不用背锅。
听着鱼皮滔滔不绝，你双眼放光：前后端分离这么厉害，是不是还能提升网站性能呢？
鱼皮摇摇头：不一定，而且有时前后端分离可能更慢！因为用户访问网站时，浏览器需要先加载前端页面，然后执行 JavaScript 脚本请求后端数据，这比传统的后端直接返回完整页面多了一次网络请求。
但是也别灰心，前后端分离后，前端和后端都可以分别进行优化，更灵活。
你点了点头：原来如此，看来前后端分离的主要目的是 提升开发效率和代码维护性 ，而不是提升性能。
于是你带领团队开始重构项目，前端用 React 框架重写了整个界面，打包成静态文件部署到 CDN 加速网络上；后端则专门提供 API 接口，返回 JSON 数据，部署在独立的服务器上，互不影响。
几个月后，你感受到了前后端分离的优势：
-
团队成员各司其职
-
前端技术灵活选择
-
后端服务多端复用
虽然前端和后端对接的过程中偶尔会斗嘴打架，但你也通过自己总结的一套前后端分离的实战经验完美解决。
你兴奋地对鱼皮说：前后端分离也太爽了吧！
鱼皮笑着问：那我问你，前后端分离一定比不分离更好么？
你不假思索：那当然了！你看看这盛世岂不如你所愿？
鱼皮摇摇头：小阿巴你要记住，没有最好的架构，只有相对更合适的架构！是否采用前后端分离，要根据团队项目规模、项目实际需求、团队技术能力等综合决定。
你：我明白了，抛开实际场景谈架构都是耍流氓~
鱼皮：最后问个问题，用了 React 框架一定就是前后端分离么？
朋友，说说你的看法吧。