小项目需要前后端分离吗？

客官°小女子只卖身不卖艺 2022-09-16 14:27 187阅读 0赞

![629bb39bdc2b7655f25728e2926e7f2b.gif][]

有网友提问：听说前后端分离是为了让前端人员专注前端，后端人员专注后端，但如果项目比较简单，并且总共也就几个人在开发，前后端分离还有意义吗？

今天我们邀请了 4 名淘系技术的前端以及后端工程师，结合他们自身在项目操作中的感受，给大家分享一些**他们对于小项目前后端实际体验的总结**，希望能够对你有帮助。

**01**

淘系技术部 逆葵

**小项目是否需要前后端分离，取决于哪种方式能够『时间最快、成本最小地完成当前的业务需求』。**

脱离实际场景谈这个问题是没有意义的，毕竟技术架构的选择需要服务于业务。

小项目有多小？它的生命周期有多久？是一个只会存在极短时间的临时系统，还是在可预见的未来有扩展成大型项目的可能？维护这个小项目的技术人员有几个？他们分别是什么技术工种？这些都是需要考虑在内的点。**小项目是否需要前后端分离，取决于哪种方式能够『时间最快、成本最小地完成当前的业务需求』。**

我们都知道前后端分离是为了让技术人员各司其职，提高效率，在成熟的互联网公司也都是这种运作方式。在人手充裕且技术人员职责清晰的情况下，无论是考虑开发效率、系统可维护度还是系统可扩展性，前后端分离显然都是最合适的选择。毕竟互联网技术发展到今天，前后端已经不是早期那样可以一个人一把梭搞定的了，两种技术已经产生了明显的鸿沟，前端更关注交互和体验，后端更关注数据和并发。

当然，回到背景设定上来，怎么选择依然要取决于你的团队开发人员的实际情况。比如说，如果开发人员只有一个 PHP 工程师，而他刚好对现代的前端框架不太熟悉，平时都是开发 PHP 页面，HTML/PHP/JS 一通杂糅，这个时候强行要求前后端分离显然并不合理。

不过从上面的举例描述来看也能发现，前后端不分离的情况已经是比较落后的生产方式了。今天，以笔者的经历来看，哪怕是学校里的工作室创业，也都是尽量通过多个技术工种协作完成项目。即使一个人身兼数职开发，代码组织方式也基本都是前后端分离的。虽说过度设计是架构中比较忌讳的地方，但是在前后端分离这一点上，已经有充足的实践证明它的优越性。

笔者作为前端，接触到的 Node.js Web 框架都是以前后端分离作为设计原则之一，甚至前后端不分离的经典语言 —— PHP 中最流行的 Web 框架之一 Laravel 也都是推荐使用现代前端框架 Vue.js 来完成页面开发的。究其原因，现代前端技术的复杂度，从开发阶段的工程架构到提升页面性能的种种优化措施，都不太适合再和后端耦合在一起。

所以，我们的结论依然不变：是否需要前后端分离，取决于哪种方式能够『时间最快、成本最小地完成当前的业务需求』。当然，考虑实际情况，前后端分离是更加普适、先进且合理的方式。

多说一句，时下比较流行的云端一体的应用开发方式，看似是和前后端分离背道而驰，实际上核心原则是一致的。借助 Serverless，前端工程师能够在专注前端 UI 的基础上，更深入地拿到数据的处理权限，某种程度上来说是更为高效的开发方式。至于更偏后端的并发、扩容、服务器运维等，则交给 Serverless 容器来解决。这也是一种前后端分离的实践。笔者认为，在小项目中，可以大胆尝试云端一体开发。

**02**

淘系技术部 千灭

#### **可以从用户****体验、开发效率和运维效率三方面来看待前后端是否分离。** ####

我认为在绝大部分场景下，前后端分离优于不分离。

接下来我会从三个主要的场景来分析前后端分离与否：用户体验、开发效率和运维效率。

**用****户体验**

如果你正在做一个门店点餐系统，那么用户对该系统最基本的要求就是界面美观、加载速度快。对于这种侧重于前端效果的项目，如果使用传统的前后端一体项目，界面交互方面，除非有专业的前端程序员，一般的服务端程序员是无法通过JSP来实现如果复杂的前端交互逻辑，并且在其中加上丰富的主题和动效的，极大的可能性就是UI画的是保时捷，开发出来是夏利。大家可以回忆下10年前的网站风格就可以想象了。加载速度方面，因为资源全部放在服务端，首次加载没有浏览器缓存，需要加载大量的js、css以及静态资源，这在今天几乎是不可接受的，即使将资源放在Ngnix服务器，也没办法做到极致加速。如果使用的前后端分离的开发模式，前端由前端项目负责，界面交互方面，可以直接使用现有的前端脚手架来实现，业内已经有专门设计师设计的UI框架供选择，均实现了丰富的动效和复杂交互，一键引入即可。加载速度方面，前端资源单独发布部署，可以通过cdn预热和极致加速。

如果你正在做一个仅用户服务端接口调用的工具类项目，那用户对该系统的基本要求就是能看懂、能操作成功即可，对于这种侧重于服务端结果的项目，如果功能变化概率较低，完全可以使用前后端一体开发模式，光速开发上线！一套系统解决所有问题。

如果项目是侧重前端交互的，那么最好使用前后端分离，如果项目侧重服务端功能，无复杂交互，前后端一体速度更快。它的服务端就是下单支付这种基本逻辑，很明显，基于传统前后端一体的JSP模式来实现需要有复杂交互的前端页面是很难的，难度一在于页面开发，首先开发html然后由服务端转化为jsp，实现功能的复杂度已经很高了，美观程度更无法保证，这对前端有很高的技术要求。难度二在于流畅性，前后端一体项目加载页面需要经过Nginx打到服务端，如果首次访问没有流量器缓存可能需要多次下载静态资源，页面加载非常的慢，并且服务端没办法解决这个问题。如果选择前后端分离，前端页面可以直接使用现有的前端脚手架来实现，各种优秀的前端框架已经支持了绝大部分的UI组件，集成了动效、样式和交互，绑定服务端数据集即可。加载速度方面前端的资源可以通过cdn加速，实现急速加载。 当然如果你开发的是内部使用的工具类项目，前端逻辑简单并且变化很少，使用前后端一体效率可能更高。

**对于侧重前端效果的项目，建议前后端分离。**

*  **开发效率**

前后端一体的项目，仅在前端界面交互简单且变更频次低的服务型项目上占有微小优势，因为此类项目核心是服务，前端仅仅是服务调用入口，只是比postman调用接口稍微产品化一点点的界面而已，不需要投入前端人力，服务端可以顺手开发，这种场景下使用jsp成本最低，效率最高。

而对于任意一个对前端界面以及交互又要求，并且会长期迭代的项目，不管项目大小，使用前后端分离的效率都要比前后端一体要高，前后端分离可以通过定义服务接口并行开发，互不影响，实现双倍提效。专业的人做专业的事，并且专业的领域有更多专业的工具，可以达到事半功倍的效果。

前后端一体的适用场景非常有限，任何一个对前端交互有要求的项目，都应该采用前后端分离的方式去开发。

*  **运维效率**

前后端一体的项目，前后端完全耦合，一次部署可实现前后端同时上线，但是一旦服务端宕机，前端页面无法展示，影响全部用户，而且不管是服务端还是前端的迭代都需要重新发布，无法保证前后端互不影响，增大了迭代风险。

对于前后端分离项目，前后端由不同的应用承载，迭代和发布都可以独立进行，实现完全解耦，几乎没有依赖，服务端宕机可以由前端兜底页面交互降低影响面，单独运维极大降低迭代风险，在前端发展到如今，运维工具非常完善，成本很低，相对于诸多风险，单独运维带来的成本增加可以忽略不计。前后端分离在绝大部分场景下的运维效率高于前后端一体。

综上所述，前后端分离在当前的技术环境下已经是大势所趋，其在用户体验、开发效率以及运维效率上均领先于前后端一体的方案，在互联网技术深度发展的今天，行业对技术人员的要求从技术广度转变为技术深度，专业人做专业事，所以，即使小项目也依然推荐前后端分离！

**03**

淘系技术部 三半

#### **其实真正实践下****来，分离也很快的，尝试一下就知道了。** ####

先说结论：

基于现有的前后端技术和运维能力，即使是小项目，也建议前后端分离；当然如果说10年前技术还不成熟，前后端不分离也是项目快速上线的一个比较好的手段。

**先谈下何为小项目**

1.  开发周期短的项目（两天内要上线）？
2.  维护时间短的项目（这个项目用这次紧急用一下，下次就不用了）？
3.  功能简单的项目（就一个简单的数据库查询，未来不会有需求变更）？

**核心问题就是小项目的成本对比？**

我的观点：无论项目有多大或者多小，要实现的产品功能肯定是不会变少的，基本的开发工作量差异并不大，那么就是前后端分离的运维成本对比了，这个如果有运维现身说法更好，按照我的工作经验来看，运维成本也没太大的差别。

**接下来就要谈谈分离的优点了**

1.  必须要说到的就是耦合问题；前后端分离天然地把双方的交互/开发边界厘清了，面向json的数据对接
2.  大大节省了联调成本，前后端可以并行开发，问题定位更加快速清晰
3.  可维护性更高，也更加方便后期的重构
4.  可读性更强等等

这个问题其实挺简单的，会有人觉得小项目怎么简单怎么来，而且先入为主的觉得不分离会更快，其实真正实践下来，分离也很快的，尝试一下就知道了。

**04**

淘系技术部 饕飨

**持续交付且周期越长的项目****，前后端分离效果越到后期优势越明显**

这个问题往往更多的是看这个项目是否有需要持续交付目的和开发周期长短来确定的。持续交付且周期越长的项目，前后端分离效果越到后期优势越明显。

通常前端和后端所关注和解决的问题是不同的，前端关注的是交互和体验，轻业务关系，需要有随时的调整的交付能力；而后端关注的是数据逻辑，重业务逻辑，相对来说稳定确定一切。

那么是否需要分离，就要看项目交付要求及频次，对项目的影响程度来决定。

一般真实的业务场景来看，前后端分离开发通常是属于较优的选择：

1.  可同步开发，降低交付延期风险
2.  完全接口化文档化，减少双方的理解和沟通成本
3.  提前了解到项目的风险和难度，有更明确的心理预期
4.  维护，维护，还是维护

对于第一点，在超过1人以上项目，协助能获得更多开发时间，绝对是降低延期风险最有效的手段。其二，前后端分离能较好地解决依赖困局，通过各种工具或者文档执行各自的开发进度，最重要的是，前后端分离后，采用的技术在实现和选择时不被束缚。为后期的维护带来方便。

**结语**

大多数情况下，前后端分离是更加普适、先进且合理的方式。

你觉得呢？评论区留下你的经验和观点吧~

✿ **拓展阅读**

[![fd9750389857c5a04eed99470c4f2548.png][]][fd9750389857c5a04eed99470c4f2548.png 1]

[![574ade5c3535504ba6877a27b1865ad2.png][]][574ade5c3535504ba6877a27b1865ad2.png 1]

**作者|**淘系技术

**编辑|**橙子君

**出品|**阿里巴巴新零售淘系技术

![38a93d80870defec285a2755124bc5b3.png][]

![1554b95fa38502d2b6b495cf827ef19f.png][]

[629bb39bdc2b7655f25728e2926e7f2b.gif]: /images/20220828/c13e1f33cb894a9ca0eb9c1b77d01033.png
[fd9750389857c5a04eed99470c4f2548.png]: /images/20220828/9a7c474d647d449fa7a1feef9c982150.png
[fd9750389857c5a04eed99470c4f2548.png 1]: http://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650435520&idx=1&sn=22743ffb535e8cbfe6eb8824b9beec47&chksm=8396a7d8b4e12ece8f8f3d856d5cb9576636ac5e7b7e65695cfa5bebf2f9bf1396e679c9020a&scene=21#wechat_redirect
[574ade5c3535504ba6877a27b1865ad2.png]: /images/20220828/380df033541845469bd6e8c8b49a9e44.png
[574ade5c3535504ba6877a27b1865ad2.png 1]: http://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650433207&idx=1&sn=05cab918e88e0c15ba0f19927c296088&chksm=8396aeafb4e127b98ab61f9d843b7114fd71cefa8a08368f1634caf87b7ff7b3abd3ff0bc6c9&scene=21#wechat_redirect
[38a93d80870defec285a2755124bc5b3.png]: /images/20220828/114e9eb1a45d4808ae9713a06818cacc.png
[1554b95fa38502d2b6b495cf827ef19f.png]: /images/20220828/99fdf8050da749d0b0e0b1478aa8cde6.png