有网友提问：听说前后端分离是为了让前端人员专注于前端，后端人员专注于后端，但是如果项目比较简单，只有少数人在开发，前后端分离还有意义吗？今天我们请到了4位淘科技的前后端工程师，结合自己在项目运营中的感受，给大家分享一些他们在小项目前后端的实际经验总结，希望对你有帮助。01淘科技部的年亏小项目是否需要前后端分离，要看哪种方式能够“以最快的时间、最低的成本完成当前的业务需求”。离开实际场景谈论这个问题是没有意义的。毕竟技术架构的选择需要服务于业务。小项目有多小？它的生命周期有多长？它是一个只会存在很短时间的临时系统，还是可以在可预见的未来扩展成一个大型项目？维护这个小项目的技术人员有多少？他们是什么技术工作？这些都是需要考虑的要点。一个小项目是否需要前后端分离，取决于哪种方式能够“以最快的时间、最低的成本完成当前的业务需求”。我们都知道，前后端分离是为了让技术人员各司其职，提高效率。这也是成熟互联网公司的运作方式。在人力充足、技术人员职责明确的情况下，无论是考虑开发效率、系统可维护性还是系统扩展性，前后端分离显然是最合适的选择。毕竟在互联网技术发达的今天，前端和后端已经不能像早期那样一个人搞定了。这两种技术之间存在明显的差距。前端更注重交互和体验，后端更注重数据和并发。当然，回到后台设置，如何选择还是要看你团队开发者的实际情况。比如开发者只有一个PHP工程师，而他又恰好不是很熟悉现代前端框架，平时开发PHP页面，HTML/PHP/JS混杂在一起，强行让此时前后端分离。但是从以上的例子和描述中也可以发现，前后端不分离的情况已经是一种比较落后的生产方式了。今天，根据笔者的经验，即使是在学校开工作室创业，也试图通过多个技术岗位的合作来完成项目。即便一个人做几份工作开发，代码组织方式也基本是前后端分离的。虽然过度设计是架构中比较忌讳的地方，但是已经有足够的实践证明其在前后端分离方面的优越性。作为前端，笔者接触到的Node.jsWeb框架是前后端分离的设计原则之一，甚至是前后端不分离的经典语言——Laravel，PHP中最流行的web框架之一，也推荐使用现代前端框架Vue.js来完成页面开发。究其原因，现代前端技术的复杂性，从开发阶段的工程架构到提升页面性能的各种优化措施，都不适合与后端耦合。因此，我们的结论是一样的：是否需要前后端分离，取决于哪种方式能够“以最快的时间、最低的成本完成当前的业务需求”。当然，考虑到实际情况，前后端分离是一种更通用、更先进、更合理的方式。还有一点，现在比较流行的云集成应用开发方式，看似与前后端分离背道而驰，但其实核心原理是一样的。借助Serverless，前端工程师在专注于前端UI的基础上，可以获得更深入的数据处理权限，某种程度上是一种更高效的开发方式。至于更多的后端并发、扩容、服务器运维等，交给serverless容器来解决。这也是一种前后端分离的做法。笔者认为，在小项目中，可以大胆尝试云集成开发。02淘科技部可以从用户体验、开发效率、运维效率三个方面看前后端是否分离。我觉得在大多数场景下，前后端分离总比不分离好。接下来我将从用户体验、开发效率、运维效率三个主要场景来分析前后端是否分离。用户体验如果你在做餐厅点餐系统，那么对系统用户最基本的要求就是界面美观，加载速度快。对于这种以前端效果为主的项目，如果使用传统的前后端一体化项目，在界面交互方面，除非有专业的前端程序员，否则普通的服务端程序员无法使用JSP来实现复杂的前端交互逻辑。并为其添加丰富的主题和动效，极有可能UI由保时捷绘制，由夏利开发。你可以回忆一下10年前的网站风格，你可以想象得到。在加载速度上，由于所有资源都放在服务器端，第一次加载没有浏览器缓存，需要加载大量的js、css、静态资源，这在今天几乎是无法接受的。即使资源放在了Ngnix服务器上，也没有办法做到极致加速。如果采用前后端分离的开发模式，前端项目负责前端。在界面交互方面，可以直接使用已有的前端脚手架。一键导入效率和复杂的交互。加载速度方面，前端资源单独发布部署，可通过CDN预热加速。如果你做的是一个只被用户服务器接口调用的工具项目，对用户的基本要求是系统能够被理解并成功运行。对于这种注重服务端结果的项目，如果功能变化Low，可以使用前后端一体化开发模式，光速开发上线！一套系统解决所有问题。如果项目以前端交互为主，最好采用前后端分离的方式。如果项目以服务端功能为主，没有复杂的交互，前后端融合更快。它的服务器基于订购和支付的基本逻辑。显然，基于传统的前后端一体化的JSP模型，很难实现一个需要复杂交互的前端页面。第一个难点在于页面开发。先开发HTML，再服务如果客户端改成jsp，实现功能的复杂度已经很高，而且不能保证美观，对前端的技术要求很高。第二个难点在于流畅度。前后端一体化项目的加载页面需要通过Nginx发送到服务器。如果第一次访问没有流量缓存，可能需要多次下载静态资源。页面加载很慢，服务器也没有办法解决这个问题。如果选择前后端分离，可以直接使用已有的前端脚手架实现前端页面。各种优秀的前端框架已经支持了绝大部分的UI组件，集成了动效、样式和交互，绑定了服务端数据集就是了。在加载速度方面，可以通过CDN对前端资源进行加速，实现快速加载。当然，如果你是开发内部使用的工具项目，前端逻辑简单，改动少，使用前后端一体化可能效率更高。对于注重前端效果的项目，建议前后端分离。前端和前端开发效率一体化的项目只在前端界面交互简单，变更频率低的服务型项目中略有优势，因为这类项目的核心是服务，而前端是只需要一个服务调用入口，比postman调用接口稍微产品化一点就可以了，不需要投入前端人力，服务器也能顺利开发。这种场景下，使用jsp成本最低，效率最高。对于任何需要前端接口和交互，并且会长期迭代的项目，无论项目大小，使用前后端分离的效率都比前后端分离要高-结束整合。前后端分离，可以通过定义服务接口并行开发，互不影响，实现双倍效率。专业的人做专业的事，专业的领域有更多专业的工具，可以达到事半功倍的效果。前后端一体化的适用场景非常有限。凡是需要前端交互的项目，都应该采用前后端分离的方式进行开发。运维效率前后端项目全耦合，前后端一次部署即可同时上线。但一旦服务器宕机，前端页面无法显示，影响所有用户，且服务器和前端迭代都需要重新发布，不保证前后端互不影响，这增加了迭代的风险。对于前后端分离的项目，前后端由不同的应用托管，迭代和发布可以独立进行，实现完全解耦，几乎没有依赖，服务器宕机可以和前端交互-端底页减少影响，独立运维巨大降低迭代风险。随着前端的发展，运维工具非常齐全，成本也很低。与诸多风险相比，独立运维带来的成本增加可以忽略不计。在大多数场景下，前后端分离的运维效率要高于前后端一体化。综上所述，前后端分离已经成为当前技术环境下的大势所趋。在用户体验、开发效率、运维效率等方面领先于前后端一体化解决方案。在互联网技术深入发展的今天，行业对技术人员的要求已经从技术广度向技术深度转变，专业的人做专业的事。所以，即使是小项目，还是建议前后端分离！03淘系技术部的第三半居然练出来了，分离的也很快。试一试你就知道了。先说结论：基于现有的前后端技术和运维能力，即使是小项目，也建议前后端分离；方法。先说说什么是小项目，开发周期短（两天内上线）的项目？维护时间短的项目（这次用这个项目应急，下次就不用了）？功能简单的项目（只是简单的数据库查询，以后不会有需求变化）？核心问题是小项目的成本比较？我的观点：无论项目大小，要实现的产品功能绝对不会减少。基础开发工作量差别不大，所以是前后端分离的运维成本对比。如果有的话最好从运维的经验来讲。根据我的工作经验，运维成本相差不大。接下来说说分离的好处。不得不提的是耦合问题；前后端分离自然而然地理清了双方的交互/开发边界，面向json的数据对接大大节省了联调成本，前后端可以并行。开发，问题定位更快，更清晰，更可维护，更方便后期重构，更具可读性等等。这个问题其实挺简单的。有的人觉得小项目就是这么简单，搞出来的，觉得不是分开的。它会更快。其实经过真正的修炼，分离的也很快。试一试你就知道了。04淘系技术部享受持续交付，项目周期越长，后期前端分离效应越明显。这个问题往往是由项目是否需要持续交付和开发周期的长短来决定的。对于持续交付、周期较长的项目，前后端分离的效果在后期会更加明显。通常前端和后端关注和解决的问题不同。前端注重交互和体验，忽略业务关系，需要有随时调整投放的能力；而后端侧重于数据逻辑，侧重于业务逻辑。都说稳定决定一切。所以是否需要分离取决于项目的交付要求和频率，以及对项目的影响程度。在一般的真实业务场景中，前后端分离开发通常是更好的选择：同步开发可以降低交付延迟的风险完整的接口和文档化，降低双方理解和沟通的成本了解风险和提前对项目的难点，有一个比较明确的维护、维护、还是维护的心理预期。对于第一点，在多人的项目中，协助可以获得更多的开发时间，这绝对是降低延期风险最有效的手段。第二，前后端分离可以更好的解决依赖困境，通过各种工具或者文档实现自己的开发进度。最重要的是，前后端分离后，使用的技术在实现和选型上不受约束。为后期维护带来方便。结论在大多数情况下，前后端分离是一种更通用、更先进、更合理的方式。
