掘力计划第 26 期北京站线下沙龙｜聊聊 node.js 的实践和未来 - 掘金
三个分享
1/3 浅谈 SSR 和 Worker#
梁伟文字节跳动 - NodeJs Infra - 研发工程师
五年前端工作经历，先后就职美团、字节跳动。目前在字节跳动从事基础技术研发。
SSR 相关#
SSR 基础概念介绍，区分 CSR 概念。
SSR 的好处
- 更好的 SEO
- 不外乎 fp/fcp 的时间更关注。
- 统一语言
- 可选引入
不用 SSR 的场景
- 为了更好的响应 TTFB - time to first byte
- 更早的交互 TTI - time to interactive
- 沉重的 UI 交互
- 复杂的用户验证
运行时支持 Node.js、Deno、cf workers 等
Worker#
引入 service worker 可以引入 fetch，相当于构建了请求。从这个角度出发，引入了 winterCG 的组织，包含了不同的运行时。兼容 web api 的标准化，一套代码可以在不同运行时运行。
复合标准的标准的运行时。
worker 的优点
- web 标准运行时。
- 基于 v8 开发标准运行时，实现独立、可控，从 api 到运行时都可以掌控
- 开发私有 api
- 轻量，服务器负担很低，pm2 启动 3-4 个实例，如果使用自己的 worker，可以运行上百的进程
- 部署也快，举例字节内部从 node -> worker，部署时间降低 90%
- 通用的方案，可以同构，用同一套工具、开发流程
worker 的问题
- 不可能完整兼容 node 环境，没有 fs net 之类的，比如 pupeteer node-gyp 之类的
- 只有 fetch 触发请求，不能 rpc 和定时器等，不能 tcp 数据库
- 链路追踪的 id 没有标准，容易混乱
兼容问题较多。
延伸一个技术分享《字节跳动 Serverless 高密度部署与 Web-interoperable Runtime 实践》
worker 实际落地，生成 qrcode 的服务，很快上线二维码。因为 serverless 高密度部署系统，不用关心伸缩性、性能规格。
特点：轻量、部署快。
落地场景：
- 可以把 worker 作为一个流程引擎，执行代码的节点嵌入。比如 langchain 去处理，处理输入和输出。
- 广告规则的计算。费用
- 产品策略选择。以上主要还是在快、轻量、好上线
- 比如一些核心服务的伴生服务，不能对原来服务有负担
- 自动化生产的产物，比如配置接口，得出接口服务
SSR 和 worker 的结合#
- SSR 需要 js runtime 运行时，worker 就是
- SSR web 标准
- SSR simple logic
使用场景举例，忽略。
SSR 放到 worker，worker 不熟到 edge、CDN 等。
既然把 SSR 放到 worker 上，那么就可以在不同的场景上去运行：
- nsr-native side render 移动端渲染，预测下一页渲染，得到移动端的秒开
- 流式渲染，为了解决 ttfb，现出来一部分内容
- edge 部署，可以 ttfb 优化，也会有其他问题
- csr 兜底，错误回退
- 可以缓存比如存储设置或者 cdn
QA 部分#
- SSR 和 auth 的结合，问能不能实现和用户权限打通，答案是看选择，缓存要小心
- SSR 有 SSR+csr 的部分，如何区分一些逻辑的运行时机，比如 window 对象、location 对象
- 服务段就是没有 window，要么引入 polyfill 让 window 不报错，也么判断是否 csr 更合适
- 如何区分 SSR 还是 csr 的请求？这可能需要标记链路追踪
延伸#
Roll your own javascript runtime
2/3 用户体验数字化建设及提效#
去哪儿 qunar 酒店前端负责人任龙飞
大纲
- 用户体验数字化
- 前端数字化提效
- 总结和展望
用户体验数字化#
业务背景和分析
用户运营场景细化。用户体验、开发体验。
如何度量用户体验？不同的指标，这里给了一个图。有颜色的部分。
细化方向。
距离技术视角
之前零碎的工具和指标，这里做整体的数字化。
指标部分比如流畅度 tti/fcp/lcp 等，稳定性 crash exception killRate、能耗 energy cpu overheat 等
能力部分，架空，apm，报表等。
要做整体数字化，不外乎定指标、做监控、做平台，嘉宾给了图，做细节展示。
这里讲的我陌生，具体讲如何落地优化体验，先有评价指标，所有部门对齐认知，汇总可行性方案。具体部门做了优化体验的部分，就抽象出来去推广，让基础部门做方案。
之后全生命周期测数据，分别做专项优化。
但，前端优化是有瓶颈的，到最后还是数据获取阶段。怎么优化，还是预测、预搜，让用户进下个页面能更快，空间换时间。
就变成预请求方案设计。还是通过不同的策略，计算什么行为之后触发提前请求。
技术收益：预测请求命中率 31%，TTI 降低 60%+
触发时机，比如首屏触发、浏览触发、跳转触发。
有了测算，就可以做监控，看趋势，找问题，拆指标，专项优化。
竞品分析，尽量自动化测试。比如准备手机截屏、代码注入、ocr 识别等，还是落实到自动化手段，数据结合。
这是为了同行业对比数字化。
定期和竞品比对。定义指标、测量数据、汇总分析。
前端数字化提效#
对业务负责，牵扯线上服务内容比较多，如何优化前端效率呢？
低代码平台的配置。BFF 也是做 serverless 上线服务。
这里介绍了如何自研 Serverless 平台，看图没什么，后面需要了可以回来听。
从本地到云上开发。还介绍了系统成品。系统设计图。toC 的容器流量一直有。
单 pod，多函数，安全性考虑业务隔离。
总结#
qa 部分
- 单 pod 稳定性、熔断怎么处理？比如某个单函数 pod 打满了，副本数如何设置，很专业呐
- 系统是内部平台，不会开源
- 用的 aws 资源，用的 nestjs，函数之间互相调用之间有瓶颈，如何处理
- 函数都能调用到，都可以通过 invoke 或者 new 起来
- aws 用的 iam role 区分资源，函数资源权限控制如何做？目前是默认全开
- 函数自定义运行时，只做了 node 运行时
- 可视化编辑，有没有做 sdk 编排，怎么做，编辑实体、运行。多个服务调用是否可以编排。实施难度比较大
3/3 AI 时代给 node.js V20 带来的一些机遇#
狼叔！
- node 版本变化
- node v20 介绍
- ai 时代新机遇
- 再看全栈
node 版本变化#
2017 node v8 - 2023node v21
v20 很多特性已经稳定了。
node v20#
一些科普和实践。
从 commonjs -> esm by default，曾经比较混乱，现在统一，到了 v21 默认扶正，更简单。
社区方面积极推进 esm 落地，只支持 esm 不支持 cjs，延伸提到 sindresorhus 发表的 esm only 渲染。算是一个契机。
- esm 服务转换：
- 比如传统的 react 项目，通过分析把依赖专程 esm.sh 上的依赖。
- 遇到 ts 资源可以通过 sucrase 转译成 esm 本地直接运行
- 通过自定义 render，把标签内容写入 html，就能实现浏览器开发，搞定页面渲染
- 低代码情况下，完全可以不用 cli 去实现
- vite 为代表，转 rust，为了可能不需要 cli，esm 方向没有 cli 可能是一个趋势
- node 可以运行 web container
未来可期
node 内置语法。node v20 已经可以实现 deno 这种 from remote，只是还没上到最新版本里。
异步流程控制。error first/promise/async-await 三种方式。历史上的 geneator/blue brid 什么的就比较少了，主流已经接受了 Promise 和 async/await 的方案。
测试方向 xv，写一个 node assert 测试语句，用 xv 运行，很轻量。
测试框架内置 node:test，以前用框架和断言库，现在不需要了。直接 node --test --test-reporter spec --watch ./*..test.js*，node + node
ts 作为一等公民，deno/bun 都内置支持。知识进阶，equal 类型体操 tsc/tsd/tsx/tsup/tsdoc 等，ioc 装饰器、设计模式、oop 等。
从 mongo 到 primay /drizzle 等，引入了类型。Proxy/Reflex，事务处理还比较麻烦，开箱即用的还偏少一点。
oop 未来和 java 差异不会太大。
现在写一个 node 模块也不是很容易了。如果使用 deno/bun 要简化一些。
和 deno bun 对比。优势缺点。
node 更关注兼容和安全，不是直接追求更快。node 的性能是足够的。from matteo collina 的《why is bun faster than node.js》
更轻量级的运行时。比如 noslate workers，对 wintercg 实现比较好的 worker，场景 faas + er
thread worker/vm/vm2 方案有很多。
知道 node 擅长、和副作用。少做补充。
node v8 到 v20 增加的东西。
ai 时代新机遇#
融合和生态。
从 prd 识别 ui，到代码，每一步骤都有大量的计算。比较痛苦。
理解 ai 辅助写代码，更多是专家 + ai
ai sdk 的支持，都对 node 有支持，多应用更快。做应用层比其他语言更快。
下图是 ai 技术方案
使用 node 快速组装上线，node + ai 有好处。
documate + node，胜场 ai 文档，aricode 开源的。看他的依赖，orama 向量数据库，代码实现简单，node 很适合实现功能。
融合，trpc 实现前后端调用有类型 @trpc/client。提到了 aircode
使用 httpc.dev 可以实现调用。类似 sdk 上拼装参数，去 invoke 对应函数。
node - faas 变轻，通过 sdk 隐藏了 http 的相关知识，难度变小
再看全栈#
前端已死？外包、服务端替换的现象。
next.js 直接调用 use server 的现象，感觉回到 php 的时代。前端没有大的革新。前后端轮回，全栈。
讲 rails dhh 的变化
低代码，工作总量不变，如何减少工作量、减少中间环节。讲 retool.com 卷低代码、sql、自动 UI。
写卷 4、下一个十年、
QA
- cpu 密集计算。thread-worker 架构拆分 napi 调 rust，能力拆分是最有效的，比如让 golang
- node 内置 ts 有可能嘛，有。
- js+ts，根据类型做优化。是的，生态现在依赖 ts 的类型推断。
听完三个分享的展望#
三个人的确厉害，很多东西听不懂，是实战出来的经验。只是密度有点大。
第一个听完，终于对 worker 有进一步的理解了，也理解 cloudflare 上的 workers/puppeteer/ d1 这些产品的场景限制了，原来做后端，不一定非得是 node
第二个有点难，level 有点高，细化的内容特别多，我没有实践过，能理解但消化不了。
第三个，重新看了 node 的这些变化，