面向前端与未来标准的 Node.js Web 框架再进化

Question

Web 开发一直是 Node.js 的主流方向，无论新人必学的 Express / Koa，或者是社区流行的企业级框架 Egg / Nest，各类 Web 框架层出不穷。本次分享来自阿里巴巴前端技术专家刘子健（繁易）在第十六届 D2 前端技术论坛的分享，为大家带来 Node.js Web 框架的发展历程，分析各类框架的适用场景及利弊，并基于阿里的 Node.js 框架 Midway，为大家介绍在过去这两年，我们对下一代 Node.js Web 框架的思考、设计、实践，包含如何面向前端做一款前端“爱用”的 Node.js 框架，如何面向未来标准甚至参与标准来设计 Node.js Web 框架两部分。

Node.js & Web 框架简述

Node.js 是基于 Chrome V8 JavaScript 引擎的运行时，一般用于编写 CLI、处理数据、编写 Restful API、进行页面渲染等等多种作用。之前 JavaScript 在浏览器端限制比较多，但是自从有了 Node.js 以后，应用范围得到很大拓展。

Web 框架功能

现代的 Web 开发不管使用什么语言都离不开 Web 框架。Web 框架具有 Restful API、数据库 CRUD、页面渲染、身份校验等功能，提供了高效开发 Web 应用的方式，同时 Web 框架存在适用场景以及规则约束，有源源不断的框架推陈出新。

Node.js 框架的发展阶段

Node.js 的发展分成三个阶段，分别是起步期、企业架构期、面向前端期。

起步阶段，主打轻量

2009 年 Node.js 出现，2010 年 Express 框架出现，2013 年出现 Koa 框架。当时前端工程师主要是在尝鲜，不敢在业务上做太多的尝试和落地，更多的是验证 Node.js Web 场景可行性。在起步期阶段，框架主打轻量和极简。下面是两个框架的写法示例。

其优点是简单易学，易于集成，Express 框架容易集成到 Nest 和 Webpack 框架中，Koa.js 框架容易集成到 Egg 和 Midway 框架中，生态繁荣，久经考验。其缺陷也是比较明显，表现为缺乏规范和最佳实践、不利于团队协作和大规模开发、Express 年久失修。

企业阶段，主打架构

在 2014 年到 2017 年，Node.js 规模化落地，专业的 Node.js 工程师出现，主打企业级框架和架构以及规模化和团队协作化。在这一段时间主要出现的框架有 nest、Egg、Midway 框架，但大多以 Express 和 Koa 框架作为基础框架，如下图：

企业级框架优点为大而全，功能完善，规范并且最佳实践明确，易于团队协作，同时社区生态活跃。缺陷是大而全导致上手成本高；限制多，难扩展。

面向前端

从 2016 之后，Node.js 发展成熟完善，Node 4.0 发布，前端工程师人数急速增加，主打面向前端框架的设计，以及简洁和轻量，在这个阶段中主要框架是 Next.js 以及 Nuxt.js 框架。

这些框架的优点主要是来自于前端，全栈开发，简单容易学习，支持 Serverless 部署。其缺陷是后端功能较弱，自定义扩展困难，强依赖于平台支持。

下面是两个 Demo 示例：

上面是 Next.js，下面是 Nuxt.js

在 2020 年的时候，一份 stateofjs 2020 关于 Node.js Web 框架满意度对比的调查报告表明，Next.js 成功登顶，并且 Express.js 框架仍然受到关注。

Node.js Web 框架满意度调研（stateofjs 2020）

总结

1. Node.js Web 框架迭代与前端行业发展密切相关；
2. 前端应用场景多于纯 Node.js 后端场景；
3. 面向前端设计的全栈框架兴起，使得 Node.js 用法回归简洁和轻量。

Midway - 面向前端的框架演进之路

Midway 是 2014 年开发的框架，发布了 7 个大版本，2018 年正式开源。

Midway 作为一款企业级开发框架，技术选型上，主要有 TypeScript（静态类型、多人协作）、IoC（复杂架构、面向接口编程）、Egg（统一框架、复用生态）。Midway Demo 示例如下图：

Node.js 应用状况

集团在 2019 年的时候，Node.js 应用状况表现为：

1. 服务器利用率低：集团 1600+Node.js 应用，常年 cpu 利用率<10%，乃至 5%，服务器利用率低。
2. DevOps 成本高：前端维护乏力，由于是 Docker 应用、限流、日志、跨语言，所以导致 Devops 成本过高。

传统应用的缺点限制了 Node.js 在阿里的进一步发展。

前端诉求

1. 后端往大后台下沉，前端往小前台发力，提升生产力。
2. 前端同学希望将中台服务快速组合为各类业务接口，和端侧同步快速交付前台，以更快的响应业务需求变化来帮助业务试错。

总体上需要赋能前端，让云原生给前端降本增效。

技术方向

通过以上现状和诉求，2019-2020 阿里巴巴前端委员会的四大技术方向为：

a、搭建服务；b、Serverless；c、智能化；d、IDE。

面临挑战

• 用户群体割裂，如何在一个框架下服务好两种用户？

前端工程师和 Node.js 工程师出现割裂。前端工程师偶尔写接口，希望简单易上手；对于 Node.js 工程师来说，因为日常管理上万行代码，更注重于复杂场景的应对能力。

• 使用场景不同，如何在一个框架下支持两种场景？

简单场景和企业级场景不同，简单场景要求快速实现 CRUD，接口聚合；企业级场景注重维护性，依赖注入，基础架构，简单场景将会逐步演化成为复杂场景。

• 前端范式变更

目前主流的前端都在从 Class Component 向 Function + Hooks 转变，包括 React、Vue 等，最终会导致函数式开发和 OOP 开发并存，如下图比较图：

同一个开发者在写前、后端的时候，思维是不一样的，那么框架有没有可能支持函数式开发，又能与 OOP 并存？

解决办法：渐进式设计

通过 Midway 的渐进式设计来解决，我们把 Midway 架构进行分层，从下到上主要为 Midway 核心、编码范式、生态、场景化、和 Modern Web。对于前端来说的解决方案就是 Hooks。

Hooks

函数即接口

JavaScript 函数即接口，统一并且无协议。

函数名称生成路径，可以根据参数的长度决定请求类型，通过 TyperScript 可以推断返回类型。通过这种方式，基于函数元信息生成接口。

获取请求上下文

针对前后端范式不一致的问题，设置了 useContext API，可以直接拿到运行时的参数，最终实现无需手动传入参数，就能够实现前端保持一致。示例代码如下：

获取 URL 查询参数

自定义 Hooks

面向全栈应用设计

典型工程代码目录

上图是典型工程代码目录，包括服务端目录、接口目录、页面资源、应用入口等，都在 src 下面，最终实现统一管理和配置，共享 src 代码、类型。

简化接口调用

零 API 调用

和传统接口调用不同，在一体化应用中，只需要导入函数，调用函数并使用返回值，因为都在一个 src 目录，且都是 TypeScript，这种直接导入的方式是可行的，同时后端的返回值也不需要生成或推断，最终实现“零”API 调用，节约时间，节省文档，实现直接调用。

• 渐进式-类似于搭积木一样进行演化

把 Midway 支持的功能按照项目类型、开发方式、拓展组件、触发器、部署平台进行罗列，可以像像搭积木一样，选择相应的积木就可以实现。比如面向前端一体化应用，可以选择一体化项目、函数式、Config、HTTP、FaaS，如下图：

如果是面向后端，可以使用 IoC+装饰器、Middleware、ORM、Swagger、Cache、HTTP、gRPC，部署在 Server 上，实现复杂的企业级应用。

也可以面向随着时间流逝复杂度增加的应用，如下图：

落地情况

Hooks 于 2020 年 4 月发布，有 2500 多个应用，是阿里前端的主流模式。

总结

1. 企业内仍存在简单场景与复杂场景，框架设计应考虑到此问题；
2. Node.js Web 框架应关注开发者体验，面向前端工程师设计；
3. 云 + 端的研发模式将成为未来的主流研发模式。

未来 - 面向标准&规划

类型安全

例如社区的 Prisma 框架，可以生成 ORM，ORM 可以根据数据库实时生成。如果前端也是自动生成，那么将会实现前端到后端再到数据库全链路的类型安全，如果后端修改了，那么前端也将会自动报错。

展望：云端融合

目前有两个在推的提案，分别为 JS Module Blocks（动态引入代码）和 JS Module Fragments（模块可以命名，模块可以静态导入）。

根据这两个提案，引入我们的第三个方向，最终实现在一个文件中，可以实现 server 端和 ssr 端以及 client 端融合。