1. React SSR的C端实践 狼叔 阿里巴巴前端技术专家
7. 目录 1、为什么要上SSR？ 2、从CSR到SSR演进之路 3、API与模块拆分 4、优化实践
10. 前端痛点 有限资源做事 能做的更多，想做的更多 前端 事多 运维 很差 API 超多
11. 三大场景和六种组合 React 1.React：现有中后台开发模式 2.Api： 只做Api聚合，内置配置、缓存、rpc等 3.Api + SSR：对于c端，将接口中间层和ssr放到一起 SSR 4.Api + React：典型的BFF模式 5.Api + SSR + React：全栈模式 API 6.SSR + React：已有项目快速提升性能，尤其是对 toB的项目非常有帮助
13. 能不能更简单？ 既要也要还要 无服务 NoOPS 函数粒度 降低构建复杂度 拥抱变化
14. 今年重点工作 收回npm包youku和tudou包名 今年会做些开源项目
18. 2.1、Client-Side Rendering (CSR) 所有逻辑，数据获取，模板编译，路由等都是在浏览器做的
20. CSR最佳实践和问题 dynamic imports umi vs cra
23. 2.2、预渲染(Prerending) Jekyll/Hexo/Gatsby/Next.js/Vuepress jsx编译成html 模板+webpack stats 布局SPA静态页面 Lazy load（可选）
25. 2.3、React SSR 模板 + 数据 => HTML 布局 Node获取数据 bundle.js CSR Ajax获取数据
26. 2.3.1、常规SSR 布局，首屏渲染，seo 加载bundle.js， hydrate绑定事件
28. 渲染方式2：renderToNodeStream
30. 有render的地方大都可以用缓存 1. 前端资源 2. 获取的数据 3. 编译结果
31. Next.js特性 1. SSR 2. Static Exporting 3. CSS-in-JS 在scr/pages/*.js都是遵守 文件名即path的做法。内 部使用react-router封 装。在执行过程中 -loadGetInitialProps()， 获得执行getInitialProps 静态方法的返回值props - 将props传给 src/pages/*.js里标准 react组件的props
32. Umi SSR 方案1：页面级别 类似于Next模式 loadGetInitialProps() 执行获得执行getInitialProps 赋值给组件的props 方案2：组件级别 bigpipe方式组件写法同next loadGetInitialProps() 执行获得执行getInitialProps 赋值给组件的props
33. 2.3.2、扩展SSR 常规SSR，只处理了一个Stream 通过bigpipe，组合多个Stream
34. CSR 和 SSR能融合么？ 核心是请求约定为getInitialProps 通过高阶组件包一下
36. Faas和 SSR能融合么？ 完美兼容faas runtime Aws lambda 构建or直接用
37. Serverless Server-Side Rendering
38. 当前端更纯粹 视图+Ajax=CSR API 视图+API（Node）=SSR 页面即服务 API开发简化 NoOPS 面向组件开发 页面即函数 CasF = as function
39. 3、API与模块拆分 你会的越多，解决问题越容易 •产品需要应变，后端不好变，前端更容易 •后端讨厌（应付）前端，几种api都懒得根据ui/ue去定 制，能偷懒就偷懒
40. API问题 1. 一个页面的Api非常多 2. 跨域(Jsonp?) 3. Api返回的数据对前端不友好 4. 需求决定Api，Api不一定给的及时
42. SSR里API与模块拆分 每个模块是一个API layout main others
43. 拆还是合？同步还是异步 没有对错，只是看哪种场景更合适。最重要的是手里有选择权
45. 函数即API 1. 2. 3. 4. 可靠性：99.999999999% 可用性：99.99%无限存储空间按量付费
46. 4、优化实践 Node没问题 Node + SSR怎么会有问题？ 编译 vs 缓存 QPS提升和性能排查
51. 未来的前端思考 前端 事多 页面即应用 函数即组件 运维 很差 API 超多 Servless，上云 不需要运维 函数即API 整个前端简单了，但应用会越来越多，未来会很好 少抱怨，多思考，未来更美好
