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

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

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

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

用户体验

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

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

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

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

• 开发效率

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

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

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

• 运维效率

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

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

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

03

淘系技术部  三半

结语

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