2023年6月29日发(作者：)

前后端分离⽅案以及技术选型前后端分离⽅案以及技术选型

⼀.什么是前后端分离？

理解前后端分离⼤概可以从3个⽅⾯理解：1. 交互形式2. 代码组织形式3. 开发模式与流程1.1 交互形式

前后端不分离后端将数据和页⾯组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引⼊的css、执⾏js脚本，完成最终的页⾯展⽰。

前后端分离后端只需要和前端约定好接收以及返回的数据格式（⼀般⽤JSON格式），向前端提供API接⼝。前端就可以通过HTTP请求调⽤API的⽅式进⾏交互。前端获取到数据后，进⾏页⾯组装、渲染，最终在浏览器呈现。

1.2 代码组织形式

前后端不分离在web应⽤早期的时候，前端页⾯以及后台业务数据处理的代码都放在⼀个⼯程下，甚⾄放在同⼀⽬录下，前端页⾯夹杂着后端代码。前、后端开发⼯程师都需要把整套代码导⼊开发⼯具才能开发。此阶段下前后端代码以及⼯作耦合度太⾼，前端不能独⽴开发和测试，后端⼈员也要依赖前端完成页⾯后才能完成开发。最糟糕的情况是前端⼯程师需要会后端模板技术（jsp），后端⼯程师还要会点前端技术，需要⼝头说明页⾯数据接⼝，才能配合完成开发。否则前端只能当⼀个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑⽆关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。

前后端分离前后端代码放在不同的⼯程下，前端代码可以独⽴开发，通过mock/easy-mock技术模拟后端API服务可以独⽴运⾏、测试；后端代码也可以独⽴开发，运⾏、测试，通过swagger技术能⾃动⽣成API⽂档供前端阅读，还可以进⾏⾃动化接⼝测试，保证API的可⽤性，降低集成风险。

1.3 开发模式与流程

前后端不分离在项⽬开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务⽆关的js（纯效果那些），完成后交给后台⼈员，后台⼈员将HTML转为jsp，并通过JSP的模板语法进⾏数据绑定以及⼀些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成⼀个war，然后部署到同⼀台服务器运⾏。顶多做⼀下动静分离，也就是把图⽚、css、js分开部署到nginx。具体开发流程如下：图略

前后端分离实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务⽆关的js（纯效果那些），后端也同时根据原型进⾏API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调⽤API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并⾏，或者前端先⾏于后端开发了。具体开发流程如下：图略

⼆、前后端分离的好处与坏处。

从上⾯3个⽅⾯对⽐了之后，前后端分离架构和传统的web架构相⽐，有很⼤的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。从⽬前应⽤软件开发的发展趋势来看，主要有两⽅⾯需要注意：越来越注重⽤户体验，随着互联⽹的发展，开始多终端化。⼤型应⽤架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构，为我们带来以下四个⽅⾯的提升：为优质产品打造精益团队通过将开发团队前后端分离化，让前后端⼯程师只需要专注于前端或后端的开发⼯作，是的前后端⼯程师实现⾃治，培养其独特的技术特性，然后构建出⼀个全栈式的精益开发团队。

提升开发效率前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应⽤所需接⼝以及接⼝参数，便可以开始并⾏开发，⽆需等待对⽅的开发⼯作结束。与此同时，即使需求发⽣变更，只要接⼝与数据格式不变，后端开发⼈员就不需要修改代码，只要前端进⾏变动即可。如此⼀来整个应⽤的开发效率必然会有质的提升。

完美应对复杂多变的前端需求如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独⽴化，让开发⼈员做到专注专精，开发能⼒必然会有所提升，能够完美应对各种复杂多变的前端需求。

增强代码可维护性前后端分离后，应⽤的代码不再是前后端混合，只有在运⾏期才会有调⽤依赖关系。应⽤代码将会变得整洁清晰，不论是代码阅读还是代码维护都会⽐以前轻松。 那么前后端分离有什么不好的地⽅吗？我⽬前是没有想到，除⾮你说会增加前端团队的配备，后端⼯程师会变的不全能。。。

⼆、前后端分离架构⽅案。实现前后端分离，主要是前端的技术架构变化较⼤，后端主要变为restfull 风格API，然后加上Swagger技术⾃动⽣成在线接⼝⽂档就差不多了。对于⽬前⽤于前后端分离⽅案的前端技术架构主要有两种：传统SPA服务端渲染SSR2.1 传统SPA传统SPA指的是单页⾯应⽤，也就是整个⽹站只有⼀个页⾯，所有功能都通过这⼀个页⾯来呈现。因为⼀个⼈的⾁眼，某⼀个时间点看⼀个页⾯，既然如此何必要不同功能做多个页⾯呢？只保留⼀个页⾯作为模板，然后通过路由跳转来更新这个模板页⾯的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻⽽易举就能实现⼀个单页⾯应⽤。

单页⾯应⽤的运⾏流程1.⽤户通过浏览器访问⽹站url2.单页⾯的html⽂件（）被下载到浏览器，接着下载html⾥⾯引⽤的css，js。，js下载到浏览器完成之后，浏览器开始解析执⾏js向后端服务异步请求数据。4.请求数据完成后，进⾏数据绑定、渲染，最终在⽤户浏览器呈现完整的页⾯。

2.2 服务端渲染服务端渲染的⽅案指的是数据绑定，渲染等⼯作都放在服务端完成，服务端向浏览器输出最终的html。⼤家看完这个是不是有个疑问，这不是⼜回到了前后端不分离的时代了吗？答案是否定的，因为这⾥的服务端是⽤来执⾏前端数据绑定、渲染的，也就是把浏览器的⼀部分⼯作分担到了服务端。⽽⽬前具备这只种能⼒的服务端是NodeJs服务端。它的原理其实就是在浏览器与前端代码中间插⼊了⼀个NodeJs服务端。浏览器请求前端页⾯时，会先经过NodeJS服务端，由NodeJs去读取前端页⾯，并执⾏异步后端API，获取到数据后进⾏页⾯数据绑定，渲染等⼯作，完成⼀个最终的html然后返回浏览器，最后浏览器进⾏展⽰。

服务端渲染应⽤的运⾏流程：1.⽤户通过浏览器访问⽹站服务端接收到请求，读取到对应的前端html，css，js。解析执⾏js向后端API异步请求数据。请求数据完成之后，进⾏数据绑定、渲染，得到⼀个最终的html。向浏览器输出html，浏览器进⾏展⽰。

PS：其实本质就是把前端编写成⼀个nodeJs的服务端web应⽤。实施服务端渲染后，我们最终运⾏的是⼀个Nodejs服务端应⽤。⽽单页⾯应⽤是把静态页⾯部署到静态资源服务器进⾏运⾏。 看到这⾥，你是否⼜有疑问，为什么要这么⿇烦搞服务端渲染呢？

2.3 SPA与服务端渲染⽅案对⽐SPA的优点是开发简单，部署简单；缺点是⾸次加载较慢，需要较好的⽹络，不友好的SEO。

so，以下就是使⽤服务端渲染的理由了（摘取vue官⽅说法）：与传统 SPA (单页应⽤程序 (Single-Page Application)) 相⽐，服务器端渲染 (SSR) 的优势主要在于：更好的 SEO，由于搜索引擎爬⾍抓取⼯具可以直接查看完全渲染的页⾯。请注意，截⾄⽬前，Google 和 Bing 可以很好对同步 JavaScript 应⽤程序进⾏索引。在这⾥，同步是关键。如果你的应⽤程序初始展⽰loading 菊花图，然后通过 Ajax 获取内容，抓取⼯具并不会等待异步完成后再⾏抓取页⾯内容。也就是说，如果 SEO 对你的站点⾄关重要，⽽你的页⾯⼜是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

更快的内容到达时间 (time-to-content)，特别是对于缓慢的⽹络情况或运⾏缓慢的设备。⽆需等待所有的 JavaScript 都完成下载并执⾏，才显⽰服务器渲染的标记，所以你的⽤户将会更快速地看到完整渲染的页⾯。通常可以产⽣更好的⽤户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应⽤程序⽽⾔，服务器端渲染 (SSR) ⾄关重要。

使⽤服务器端渲染 (SSR) 时还需要有⼀些权衡之处：开发条件所限。浏览器特定的代码，只能在某些⽣命周期钩⼦函数 (lifecycle hook) 中使⽤；⼀些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应⽤程序中运⾏。涉及构建设置和部署的更多要求。与可以部署在任何静态⽂件服务器上的完全静态单页⾯应⽤程序 (SPA) 不同，服务器渲染应⽤程序，需要处于 server 运⾏环境。更多的服务器端负载。在 中渲染完整的应⽤程序，显然会⽐仅仅提供静态⽂件的 server 更加⼤量占⽤ CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在⾼流量环境 (high traffic) 下使⽤，请准备相应的服务器负载，并明智地采⽤缓存策略。

2.4 预渲染技术如果你调研服务器端渲染 (SSR) 只是⽤来改善少数营销页⾯（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。⽆需使⽤web 服务器实时动态编译 HTML，⽽是使⽤预渲染⽅式，在构建时 (build time) 简单地⽣成针对特定路由的静态 HTML ⽂件。优点是设置预渲染更简单，并可以将你的前端作为⼀个完全静态的站点。如果你使⽤ webpack，你可以使⽤ prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应⽤程序⼴泛测试 - 事实上，作者是 Vue核⼼团队的成员。

三、前后端分离技术选型- artTemplate + bootstrap（不推荐， 不算完全前后端分离）- vue全家桶（推荐）- react全家桶 （推荐，⽣态全）

后续会继续完善前后端分离⽅案具体实践的⽂章，敬请期待。。。 PS:本⽂属于本⼈原创⽂章,转载请注明出处，如果你觉得这篇⽂章对你有帮助或启发，也可以来请我喝咖啡。利益相关：本篇⽂章所有提到的商业品牌或⽹站链接均为笔者随意想到的或⽇常使⽤的，⽆任何⼴告费⽤。