这种方式非常好，之前写好的项目一句不用改，只需新起 Rendora 服务。对于来自前端服务器或外部的每个请求(百度谷歌爬虫)，Rendora会根据配置文件，根据头，路径来检测或过滤，以确定 Rendora 是否应该只传递从后端服务器返回的初始HTML或使用Chrome提供的无头服务器端呈现的HTML。更具体地说，对于每个请求，有2条路径：
请求被列入白名单作为SSR的候选者(即过滤后的Get请求)，Rendora 会指示无头Chrome实例请求相应的页面，呈现它，并返回包含最终服务器端的响应呈现出HTML。通常只需要将百度、谷歌、必应爬虫等网络抓取工具列入白名单即可。
未列入白名单(即请求不是GET请求或未通过任何过滤器)，Rendora将只是充当反向HTTP代理，只是按原样传送请求和响应。
Rendora可以看作是位于后端服务器（例如Node.js / Express.js，Python / Django等等）之间的反向HTTP代理服务器，也可能是你的前端代理服务器（例如nginx，traefik，apache等），
Rendora 是我见过的接近于完美的动态渲染器，提供零配置服务器端渲染
我们到底选择哪一种服务端渲染呢？
Rendora，新的方式非常厉害，有很多优势：
方便迁移老的项目，前端和后端代码不需要更改。
可能更快的性能，资源(CPU)消耗可能更少，Golang编写的二进制文件
多种缓存策略
已经拥有 docker 容器方案
此工具，服务端渲染的页面需要缓存，缓存引发的小问题就是
通过缓存解决，性能问题和调用API两次的问题，服务端渲染，客户端展示渲染，平常调用一次API，现在调用了两次。
被缓存的页面，不能及时清理，比如网站发现用户发了不良信息，需要清理，就需要清理缓存页面了。
如果想提高用户体验，浏览器端一些页面需要服务端渲染，这个时候服务端需要请求API，就会有权限问题，或者直接从缓存里面读取的HTML，到浏览器客户端，可能会有服务端和浏览器端渲染不一致的错误。
如果上面两种方式不在你的考虑范畴之内，那Rendora将是你完美的服务端渲染解决方案
总结感觉我的轮子 kkt-ssr 好像白写了一样，经过分析发现目前还有一点作用吧，至少解决了不多调用一次API，和API调用权限问题导致渲染不一致的问题。但是我更推荐Rendora的方式，这将是未来。
不管怎样，轮子还需要Star的，来撮这里， kkt-ssr 。