React-SSR渲染调研

前期思考：

• 1、nodejs环境如何加载前端组件
  • 选用koa、express、egg
• 2、组件的数据如何获取
• 3、HRM怎么做（热替换？热重载？CSS HMR）
  • 是否使用webpack-dev-server
  • CSS 不使用style-loader(modul.hot,accept),使用react-hot=loader来实现一个css-hot-loader
• 4、css如何处理
• 5、如何拼接完整的HTML结构返回
  • renderToNodeStream
  • ReactDOM.hydrate
• 6、如何进行路由分割
  • 服务端路由和客户端路由公用一套
• 7、如何降级为客户端渲染
  • 当服务端渲染出现问题是，降级为客户端渲染
  • 同时支持两种SSR以及CSR两种开发模式，无缝切换
• 8、是否可以做到同构开发
• 9、生成环境如何发布应用
  • 如何做到每次不更新服务，react这些静态资源更新后

同构开发需要考量的点

• 代码或者框架层需要兼容server/client的runtime
  比较直接的一个就是fetch数据操作，如果服务端数据源有RPC协议或者请求的服务存在环境/网络隔离，需要封装成通用的http接口

• 更复杂的部署和打包构建
  部署和大奥构建过程加倍，简单地理解就是单独的server和单独的client的工作综合

• 增加服务端负责
  这个是SSR的通病，但使用同构开发方式后完全可以变成一个可有花的点，在使用同构方式时，可以正对服务端资源负载做监控，如果遇到服务端负载过大或者高峰时段，可以将渲染方式无缝切换成csr，待服务端负载正常或者流量回落时，在切换为SSR。

同构开发的优点

• 服务端和客户端公用代码
• 更快的页面内容达到时间
• 更友好的SEO
• 更优雅的降级方式，更健壮的应用

对比：beidou、next.js、easy team，对比方案

easy-team方案对比

• 与服务端框架不耦合，easy-team的实现方式与egg框架耦合的太过紧密
• 本地开发读取服务端bundle的方式更加优雅
• 通过config.default.js同时两种渲染模式无缝切换而easy-team需要在构建时指定渲染类型

与next.js方案对比

• 与服务端框架不耦合，next实现与http模块耦合紧密
• 本地开发读取服务端的bundle的方式更加优雅
• 体积小，同等复杂度项目大小为next.js生成文件的0.3b倍
• 实现非黑盒，关键配置皆可以通过config.default.js来配置

理想模型：koa+react+ReactDOMServer+midway+webpack

bigpipe的优点，分块传输优点非常明显，且浏览器友好，fb和微博，qunar都是受益者，node天然支持，res.writer很友好