前期思考：
- 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很友好
网友评论