前端的爆发，说来也就是最近 3、4 年的事情，其中 Node.js 给前端如此繁荣的环境提供了很大的助力。Node.js 让更多人看到了前端的潜力，从服务器端开发，到各种脚手架、开发工具，前端开始沉浸在造轮子的世界里无法自拔。组件化后，比如 SSR、PWA 等辅助前端开发的快速开发实践你几乎躲不过去，再到 API 中间层、代理层到专业的后端开发都有非常成熟的经验。

Node.js 在大前端布局里意义重大，除了基本构建和 Web 服务外，这里我还想讲两点。

首先它打破了原有的前端边界，之前应用开发只分前端和 API 开发。但通过引入 Node.js 做 BFF 这样的 API proxy 中间层，使得 API 开发也成了前端的工作范围，让后端同学专注于开发 RPC 服务，很明显这样明确的分工是极好的。

其次，在前端开发过程中，有很多问题不依赖服务器端是做不到的，比如场景的性能优化，在使用 React 后，导致 bundle 过大，首屏渲染时间过长，而且存在 SEO 问题，这时候使用 Node.js 做 SSR 就是非常好的。

当然，前端开发 Node.js 还是存在一些成本，要了解运维等，会略微复杂一些，不过也有解决方案，比如 Servlerless 就可以降级运维成本，又能完成前端开发。直白点讲，在已有 Node.js 拓展的边界内，降级运维成本，提高开发的灵活性，这一定会是一个大趋势。“

五件事

• 《狼书（卷1）：更了不起的Node.js》已预售
• 连发明人都抛弃node.js了，还有前途吗？
• 前端开发下一个“风口”是什么？
• 用node.js模板写的页面算不算ssr呢？
• GMTC大会Node.js专场有哪些分享？

下面会一一介绍。

《狼书（卷1）：更了不起的Node.js》已预售

催书群有一个段子，还挺有意思，录下供各位乐呵乐呵。

当年苏轼在杭州做官的时候，常在西湖泛舟游玩，一个歌女提着锡壶为苏轼倒酒，不慎将锡壶掉进了西湖中，于是有位朋友出了个上联：“游西湖提锡壶，锡壶掉西湖，惜乎锡壶”，面对这个上联，苏轼也没能接出下联，就此苏轼甚是不爽的结束了游玩！一千年后群友在狼叔的群里催书，甚至有网友打赌称狼叔的书要太监了。没想到催了三年的书终于要出版了，至此苏轼的千年上联也终于有了下联：“催狼叔写狼书，狼叔赌狼书，郎输狼书”。

京东上可以购买 https://item.jd.com/12623248.html

连发明人都抛弃node.js了，还有前途吗？

ry在2012年之后就没有贡献过代码了，包括iojs事件也没参与。到现在node 12了，依然稳定坚挺，要感谢node社区和庞大的贡献者。所以这个立论是不对的。

论前途，在前端不了解node不太可能，你说重要不？node可以覆盖你见到的所有场景，包括db操作，但一般不建议前端这样做。前端主要做api代理，即bff层。

未来servless，省去运维苦恼，前端更加会大量用node的。

前途一片大好的。

前端开发下一个“风口”是什么？

前端接手所有应用逻辑开发，让业务后端躲在rpc服务后面。

• servless让前端不关心node运维，轻松扩容，解决api层所有痛点
• 基础运维被云计算打败，servicemesh更是将基础服务进一步服务化，如果根据流量动态实例化容器，pe还有必要么？现在数据库单表60亿很正常，crud的rpc服务可以量产，异构数据汇总越来越简单，流式处理更是极致。唯有端上，被产品蹂躏。
• js跨端开发是必然。无论rn，nativescript，小程序，还是flutter，都是极好的尝试，投入产出比极高（flutter的点是基于skia引擎，意图跨端，像rn，weex这种是每个平台实现一套，而flutter更狠，直接2d上画，跨端实现会更容易，提供了更高级的玩法。dart感觉就是作死的货[捂脸]，没有热更新，感觉过年很难火）
• 前端技术栈趋于稳定，接下来就是降低难度，最终服务化，上云。

servless云服务解决方案，让前端受益最大。应用只会无限增多，前端未来不愁，必然是下一个风口。

用node.js模板写的页面算不算ssr呢？

服务端渲染是很古老的话题，从CGI到PHP、ASP、JSP时代，都是采用服务端渲染的，包括Node.js Web应用开发最常见的也是服务器端渲染。但随着前端技术爆发式增长，使得React类的组件开发成为主流的技术选型，是典型的客户端渲染方式。随着React技术栈深入落地，基于React的服务器渲染的需求也日益增多，尤其是直接面向用户的C端场景下。

但是，你真的清楚服务端渲染的发展阶段，以及每个阶段的核心原理么？

这里总结了服务端渲染演进四阶段。

1/原始阶段：php，jsp，asp这种都算，当然node渲染模板也算，node世界模板最丰富。但，你真的了解模板引擎原理和服务端渲染过程么？

2/Bigpipe增强阶段：虽然bigpipe很老了，但分块传输有点是非常明显的，且浏览器友好。fb和微博，qunar都是受益者。node天然支持，res.write爽歪歪。你真的了解bigpipe原理，以及企业中大流量页面中应用bigpipe的最佳实践么？

3/组件化渲染阶段：基于组件写法的ssr，比如react ssr。时代变了，ssr也要跟上。vdom+hydrate玩的可以很嗨，连bigpipe也可以结合起来。umi ssr和rax ssr未来可期。你真的了解当下最流行的服务端方案的原理和实现么？

4/同构阶段：真正的同构，即csr和ssr写法一致，未来不再区分概念，在servless里，api和渲染都是函数。你能想象的到，在未来，前端是如何工作的么？

这些问题统统和服务端渲染有关，以服务端渲染为中心，将后端和前端技术栈串起来，能够为大家建立起更好的大局观，并在开发中，对技术选型，架构设计起到参考作用。

刚好我们团队最近做了一个最小而美的egg + react + ssr 方案 https://github.com/ykfe/egg-react-ssr ，推荐大家使用。

已完成特性如下

• 基于cra脚手架开发，由cra开发的React App可无缝迁移，如果你熟悉cra的配置，上手成本几乎为0
• 小而美，相比于beidou，next.js这样的高度封装方案，我们的实现原理和开发模式一目了然
• 同时支持SSR以及CSR两种开发模式,本地开发环境以及线上环境皆可无缝切换两种渲染模式
• 统一前端路由与服务端路由，无需重复编写路由文件配置
• 支持切换路由时自动获取数据
• 支持本地开发HMR
• 稳定性经过线上大规模应用验证，可提供性能优化方案
• 支持tree shaking以及打包去重依赖，使得打包的bundle非常小，为同样复杂度的next.js项目的0.4倍
• 支持csr/ssr自定义layout，无需通过path来手动区分

参见最小而美的Egg + React + SSR应用骨架

另外umi ssr也是我们参与贡献的 https://github.com/umijs/umi/pull/2543

示例：https://github.com/umijs/umi-example-ssr

GMTC大会Node.js专场有哪些分享？

这次GMTC北京2019上，我将会担任Node技术专场的出品人，来现场跟大家聊一聊Node.js对于前端技术发展的意义和未来的技术趋势。

今年会以Typescript和Servless，DevOps为主。其实很简单，ts已经成为事实上的主流开发语言。而Servless对于前段意义更大，不需要运维，开发更简单，不需要担心qps，无论哪个点都在值得前端投入，必定流行。最后选了一个DevOps，我个人以为Node.js开发在运维侧是偏弱的，行业里很多好的实践也希望能够在Node方向落地。

在说一下作者，张挺是淘宝Node.js一号位，对于集团Node.js应用治理，数据采集，框架开发，function runtime等研究的非常深，有员外之称，https://github.com/midwayjs 下的项目绝大部分都出自员外之手，实力强悍，去年GMTC就邀请他来讲过，今年90分钟，相信大家一定会非常过瘾的。Starkwang是Node代码核心贡献者，鹅厂，能力和背景都非常好，也有D2等分享经验，其实大家可以和他聊聊如何成为Node代码贡献者，也应该是蛮有趣的。金炳是网易Node.js开发，基于Knative平台做servless应用，有一定经验，今年收到过不少关于servless的topic，最终选了这个，Knative是谷歌开源的servless平台，大家是可以非常容易落地的，期望他能够讲出最佳实践。

下面是本专题下的具体议题内容介绍：

TypeScript多场景设计方案及应用实践

内容简介：

淘宝从2017年之前就开始探索TypeScript的落地方式，随着时间的推移已经将新的模块和框架全部迁移到TypeScript体系，在2019年，TypeScript应用已经遍地开花，提前完成了非常不错的布局。 本次分享主要介绍淘宝最近开源的Midway框架在新的场景、新的体系下如何和现有的Egg体系保持良好的兼容性，同时又能在TypeScript的使用中有着独特的体验，通过针对不同场景的情况，我们引入相同的解决方案，为未来打下了夯实的基础。

演讲提纲：

1. 使用TypeScript （1）规模化编程和全栈带来的挑战 （2）面向接口编程 （3）新特性，装饰器的使用

2. 基于Egg创造性Web框架Midway (1) 从Egg开始 (2) 引入 IoC (3) 和框架解耦 (4) 和目录结构解耦 (5) 引入自定义装饰器 (6) 实践讲解

3. 多场景设计实践 (1) 跨场景的实现 (2) FaaS场景的设计和代码迁移 (3) 跨其他场景的解决方案

听众收益： 当前Node.js的场景越来越多，很多代码都需要跨不同场景进行共享和迁移，在这些过程中，如果代码能够尽可能少的变化，势必会减少很多工作量和重构量，也使得在业务迁移过程中能够更加专注业务本身，而不是新框架的使用方式。

海量Node.js云服务的DevOps实践

内容简介： Node.js近几年在服务端开发的比重越来越大，各大公司或多或少都选用它作为构建业务链路中不可缺少的一环。但Node.js本身极度灵活、轻量的特性，让它对DevOps上并不是那么的友好，一直被业界诟病为前端工程师的“玩具”。这些问题对于构建高可用服务非常重要。

腾讯云云开发团队从业务最初启动时，就选用了Node.js作为接入层的运行时环境，从业务上线到现在每天数亿级体量的云服务调用，在这个发展过程中，DevOps也从刀耕火种的原始阶段，逐渐构建了一套比较完善、严谨的流程。本次分享主要介绍Node.js在云开发团队业务架构中的定位，如何为Node.js设计一套稳定可靠的DevOps流程，在这个流程中会遇到哪些坑，如何在业务快速迭代的同时，保证服务的高度可用性。

演讲提纲：

1. Node.js in CloudBase （1）Node.js在云开发团队的发展历程 （2）Node.js在业务架构中的定位

2. 渐进式迁移到静态语言 （1）TypeScript的语言优势 （2）TS在实际业务中的最佳实践

3. 为项目编写高质量的测试 （1）测试的基础知识 （2）单元测试 （3）集成测试 （4）端到端测试

4. 持续集成 （1）持续集成的基础知识 （2）Git Flow + Node.js最佳实践 （3）如何使用CI系统科学、自动地测试代码 （4）发布流程与发布策略

5. 日志、监控与容灾 （1）日志规范与日志系统 （2）如何通过监控告警快速定位问题 （3）容灾：主备、异地多集群

听众收益：

1. 了解为Node.js搭建DevOps流程中的技术选型、演化以及经验
2. 了解业界DevOps的最新理念和规范

网易严选企业级Node框架及Serverless应用实践

内容简介： 网易严选作为原创生活类自营电商品牌，其供应链、采购、财务、数据等，具有业务变更频繁、流程复杂性高、跨系统协作多的现状，使得业务系统前端开发在开发和维护中变得越来越困难。因此，构建一个架构设计优良、功能全面、质量稳定的Node应用框架显得尤为重要。

我们基于TypeScript设计和开发了严选Node框架，抽象了应用生命周期管理，完成了Node生态建设，建立了与业务系统和技术中台的对接规范。在整个框架的开发和落地过程中，我们还实践了Serverless场景的应用，探索了Service Mesh在Node应用中的价值，希望能给大家带来一些思想的碰撞。

演讲提纲：

1. Node应用场景 （1）我们的Node应用场景 （2）我们需要什么样的框架

2. 自研框架的介绍 （1）框架设计思想 （2）框架功能介绍 （3）框架生态建设 （4）框架质量保障

3. Serverless实践介绍 （1）Serverless原因 （2）方案选型 （3）Knative应用、扩展开发 （4）应用场景

4. Service Mesh在Node应用中的价值 （1）Service Mesh介绍 （2）Istio带来的价值

听众收益：

1. 完整了解企业级Node框架开发过程，掌握框架设计思想
2. 了解Serverless、Service Mesh对Node应用的价值，拓展Node应用场景

除了上述议题之外，在GMTC全球大前端技术大会上还有关于前端框架、工程化、性能优化、跨平台、小程序、Flutter、移动AI、前端团队管理等内容的70+干货技术案例分享。

目前大会报名倒计时 进行中，购票咨询：18514549229（同微信），欢迎来“Node“技术专场面基，点击“阅读原文”了解大会更多详情。

阅读原文链接：https://gmtc2019.geekbang.org/schedule?utm_source=cnode&utm_medium=node

狼叔有2个讲师优惠码，八折，需要的可以找我。