三个分享

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:xxx 内置语法。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:test + node:assert

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、下一个十年、

cpu 密集计算。thread-worker 架构拆分 napi 调 rust，能力拆分是最有效的，比如让 golang
node 内置 ts 有可能嘛，有。
js+ts，根据类型做优化。是的，生态现在依赖 ts 的类型推断。

听完三个分享的展望#

三个人的确厉害，很多东西听不懂，是实战出来的经验。只是密度有点大。

第一个听完，终于对 worker 有进一步的理解了，也理解 cloudflare 上的 workers/ puppeteer/ d1 这些产品的场景限制了，原来做后端，不一定非得是 node

第二个有点难，level 有点高，细化的内容特别多，我没有实践过，能理解但消化不了。

第三个，重新看了 node 的这些变化，