一、客户痛点
为追求速度体验和极致的 SEO 效果，越来越多的技术管理者和架构师倾向于采用 SSR (Server Side Rendering) 技术来构建前端项目，以支持同构代码的服务器端渲染。企业团队在2016年时开始使用 React，2017年开始研究并尝试 React Server Render，同期 Facebook 网站已经采用 Isomorphic 技术实现，性能相对较好。为满足公司业务需求和技术传承，客户自研了前端技术框架 Koot.js，目前已成为客户前端的主要技术方案。
HTML、CSS、JS 以及其他资源都能够做到按需加载，但 SSR 更能够 Isomorphic（前后端同构），结合 SSR (Server Side Rendering) 和 CSR (Client Side Render) 的优点，让用户浏览网页时不管是首屏还是随后操作的其他页面都能更快的展示响应。
SSR 项目落地的时候通常不是很顺畅，项目部署的时候需要具备服务器技术能力才能和运维顺畅沟通，因此项目落地不仅需要前端同学掌握后端开发能力还需要对运维技术、并发等问题多方面考虑，这对前端技术同学的技术能力有较高要求。
二、Serverless 解决方案
Serverless 技术可以降低前端对服务端和运维的技术能力要求，更适合大部分需要使用 SSR 的前端团队。腾讯云 Serverless 提供了比较全面的组件支持，与 Serverless Cloud Framework 基本无缝结合，周边社区和生态支持也比较到位，使用过程中能避免很多问题。在选定平台之后接下来的部署将较为顺畅，因为 Serverless Cloud Framework 提供了很多标准化的接口，在封装 Koot.js Serveless 组件的过程中能够更便捷省心。
客户早期就进行了前端分离的开发，前后端完全使用 API 对接，协作改变不大。由于使用了 Isomorphic，因此对 API 的要求变高，用户的请求不止来源于 Node 服务器，还有来自浏览器的请求，对安全性要求也会更高。
三、SSR 落地建议
未来的 SSR 都应该是 Isomorphic 模式，带来的好处是减少传输成本，分摊渲染压力，用户体验也会有所提升。体验的提升其实非常小，网络情况好时，用户几乎感知不到，但小小的提升在技术开发中却做出了非常多的工作，因此我们会越来越完善技术框架，让业务开发同学能够快速开发出需求，同时又享有 Isomorphic 带来的技术体验。
对于还未开始使用 SSR 的团队，如果是 ToC 产品业务，建议尝试 SSR，能够让用户尽快看见页面内容。
前端的 SSR 一定会考虑是否需要 Isomorphic，如果小团队建议先尝试比较流行的框架，例如 Next.js、Nuxt.js 等，也推荐体验 Koot.js。Next.js、Nuxt.js 这类框架在腾讯云 Serverless Cloud Framework 都有现成的组件支持。无论是 SSR 还是 Serverless，最好都是基于现有框架，如果没有足够业务支持建议无需浪费精力自己研发框架，学会一个框架的成本要远小于维护一个框架的成本。