近来在开辟一个效劳端衬着东西，经由历程一篇小文大抵引见下效劳端衬着，和效劳端衬着的体式格局要领。在此文背面有两中效劳端衬着体式格局的构想，依据你对效劳端衬着的利害衡量，你会挑选哪种效劳端衬着体式格局呢？

什么是效劳器端衬着

运用 React 构建客户端运用程序，默许状况下，能够在浏览器中输出 React 组件，举行天生 DOM 和操纵 DOM。React 也能够在效劳端经由历程 Node.js 转换成 HTML，直接在浏览器端“显现”处理好的 HTML 字符串，这个历程能够被以为 “同构”，因为运用程序的大部份代码都能够在效劳器和客户端上运转。

为何运用效劳器端衬着

与传统 SPA(Single Page Application – 单页运用程序)比拟，效劳器端衬着(SSR)的上风重要在于：

1. 更好的 SEO，因为搜索引擎爬虫抓取东西能够直接检察完整衬着的页面。
2. 更好的用户体验，关于迟缓的收集状况或运转迟缓的装备，加载完资本浏览器直接显现，无需守候一切的 JavaScript 都完成下载并实行，才显现效劳器衬着的HTML。

效劳端衬着的弊病

1. 因为效劳端与浏览器客户端环境区分，挑选一些开源库须要注重，部份库是没法在效劳端实行，比方你有 document、window 等对象猎取操纵，都会在效劳端就会报错，所以在挑选的开源库要做鉴别。
2. 运用效劳端衬着，比方要起一个特地在效劳端衬着的效劳，与之前，尽管客户端所需静态资本差别，你还须要 Node.js 效劳端的和运维布置的学问，对你所须要控制的学问点要求更多
3. 效劳器须要更多的负载，在 Node.js 中完成衬着，因为 Node.js 的缘由大批的CPU资本会被占用。
4. 下文引见一种效劳端衬着的“操纵”，这个新的操纵具有新的题目，比方API要求两次，种种效劳端题目，你就无计可施了，因为这个新的东西用Golang写的，你的团队或许是你，须要相识一下Golang，你说气不气人又要多学东西。

效劳端衬着两种体式格局

依据上文引见对效劳端衬着利害有所相识，我们能够依据利害衡量弃取，近来在做效劳端衬着的项目，找到多种效劳端衬着处理计划，大抵分为两类。

第一种体式格局

传统体式格局效劳端衬着，处理用户体验和更好的 SEO，有诸多东西运用这类体式格局如React的(Next.js)、Vue的(Nuxt.js)等。

有些东西将 webpack 运转在效劳端临盆环境，实时编译，将编译效果缓存起来，这都照样传统的体式格局，只不过将 webpack 运转在效劳端实时编译，照样开辟环境编译预编译好的题目。

我挑选了将 webpack 放在开辟环境，只做开辟打包的功用，打包 客户端 bundle ，
效劳端 bundle，资本映照文件 assets.json，CSS 等资本举行布置。

• 效劳器 bundle 用于效劳器端衬着(SSR)
• 客户端 bundle 给浏览器加载，浏览器经由历程 bundle 加载更多别的模块(chunk)js
• 资本映照文件 assets.json 则是，效劳器 bundle 在预备所需 HTML，须要预插进去那些模块(chunk)js，和CSS，这只是进步用户体验。

详细运用要领，能够看我近来造的个轮子 kkt-ssr，这个轮子将东西的部份封装起来，你只须要写营业代码，和少许的效劳端衬着代码即可，还附赠十几个示例，加上一个相对比较完善的示例react-router+rematch，类似于 next.js，然则有相当大的区分。

第二种体式格局

这是一种立异的要领，前端单页面运用，之前怎样玩儿，如今还怎样玩儿，多的一步是，你得先接见一个Rendora的效劳，在前面阻拦是不是须要效劳端衬着。下图为官方图：

这类体式格局底本只是个主意，主意是前端不必管效劳端衬着的事儿了，不就是处理SEO？，这些爬虫过来的时刻，能够经由历程头信息推断，写个效劳，然后将须要的内容给爬虫就能够了，昨天碰巧在GitHub的趋向榜上，碰巧看到 Rendora 个东西，也就那末巧，恰好思绪一致，这个东西重要为收集爬虫供应零设置效劳器端衬着，以便毫不费力地改进在当代Javascript框架（如React.js，Vue.js，Angular.js等）中开辟的网站的SEO题目。

这类体式格局异常好，之前写好的项目一句不必改，只需新起 Rendora 效劳。关于来自前端效劳器或外部的每一个要求(百度谷歌爬虫)，Rendora会依据设置文件，依据头，途径来检测或过滤，以肯定 Rendora 是不是应当只通报从后端效劳器返回的初始HTML或运用Chrome供应的无头效劳器端显现的HTML。更详细地说，关于每一个要求，有2条途径：

1. 要求被列入白名单作为SSR的候选者(即过滤后的Get要求)，Rendora 会指导无头Chrome实例要求相应的页面，显现它，并返回包括终究效劳器端的相应显现出HTML。一般只须要将百度、谷歌、必应爬虫等收集抓取东西列入白名单即可。
2. 未列入白名单(即要求不是GET要求或未经由历程任何过滤器)，Rendora将只是充任反向HTTP代办，只是按原样传送要乞降相应。

Rendora能够看做是位于后端效劳器（比方Node.js / Express.js，Python / Django等等）之间的反向HTTP代办效劳器，也多是你的前端代办效劳器（比方nginx，traefik，apache等），

Rendora 是我见过的接近于圆满的动态衬着器，供应零设置效劳器端衬着

我们究竟挑选哪种效劳端衬着呢？

Rendora，新的体式格局异常凶猛，有许多上风：

1. 轻易迁徙老的项目，前端和后端代码不须要变动。
2. 能够更快的机能，资本(CPU)斲丧能够更少，Golang编写的二进制文件
3. 多种缓存战略
4. 已具有 docker 容器计划

此东西，效劳端衬着的页面须要缓存，缓存激发的小题目就是

1. 经由历程缓存处理，机能题目和挪用API两次的题目，效劳端衬着，客户端展现衬着，寻常挪用一次API，如今挪用了两次。
2. 被缓存的页面，不能实时清算，比方网站发明用户发了不良信息，须要清算，就须要清算缓存页面了。
3. 假如想进步用户体验，浏览器端一些页面须要效劳端衬着，这个时刻效劳端须要要求API，就会有权限题目，或许直接从缓存内里读取的HTML，到浏览器客户端，能够会有效劳端和浏览器端衬着不一致的毛病。

假如上面两种体式格局不在你的斟酌领域以内，那Rendora将是你圆满的效劳端衬着处理计划

总结

觉得我的轮子 kkt-ssr 彷佛白写了一样，经由剖析发明现在另有一点作用吧，最少处理了不多挪用一次API，和API挪用权限题目致使衬着不一致的题目。然则我更引荐Rendora的体式格局，这将是将来。