Web开发一直是Node.js的主流方向，不管是新人必学的Express/Koa，还是Egg/Nest，一个社区流行的企业级框架，各种web框架层出不穷。本次分享来自阿里巴巴前端技术专家刘子健（Flexible）在第16届D2前端技术论坛，为大家带来Node.jsWeb框架的发展历程，分析各种框架的适用场景和优缺点，以及基于阿里的Node.js框架Midway，我们将介绍近两年我们对下一代Node.jsWeb框架的思考、设计和实践，包括如何做一个前端“爱”的Node.js对于前端Framework，如何设计未来标准的Node.jsWeb框架，甚至参与标准。Node.js和Web框架简介Node.js是一个基于ChromeV8JavaScript引擎的运行时。一般用于编写CLI，处理数据，编写RestfulAPI，执行页面渲染等功能。以前JavaScript在浏览器端的限制比较多，但是自从引入了Node.js之后，应用范围得到了极大的扩展。Web框架功能现代Web开发无论使用什么语言都离不开Web框架。Web框架具有RestfulAPI、数据库CRUD、页面渲染、身份验证等功能，为开发Web应用程序提供了一种高效的方式。同时，web框架有适用场景和规则约束，新框架源源不断。Node.js框架的发展阶段Node.js的发展分为三个阶段，即初级阶段、企业架构阶段和前端阶段。起步阶段，2009年出现Node.js，2010年出现Express框架，2013年出现Koa框架，当时前端工程师主要是尝鲜，不敢做太多尝试以及在业务中的实现。他们更关心验证Node.jsWeb场景的可行性。在初始阶段，该框架侧重于轻量级和极简主义。下面举例说明这两个框架是如何写的。它的优点是简单易学，易于集成。Express框架易于集成到Nest和Webpack框架中，Koa.js框架易于集成到Egg和Midway框架中。生态繁荣，久经考验。它的缺陷也比较明显，表现在缺乏规范和最佳实践，不利于团队协作和大规模开发，而且Express年久失修。企业阶段，主要架构是2014年到2017年，Node.js大规模落地，出现了专业的Node.js工程师，专注于企业级的框架和架构，以及规模化和团队协作。这段时间出现的框架主要有nest、Egg、Midway框架，但大多以Express和Koa框架为基础框架，如下图：企业级框架的优势在于大而全，功能齐全，规范清晰的最佳实践，轻松的团队协作和活跃的社区生态。缺点是大而全，导致入门成本高；限制多，扩展难。面向前端从2016年开始，Node.js日渐成熟。随着Node4.0的发布，前端工程师的数量迅速增加。主要侧重于前端框架的设计，以及简单和轻便。现阶段主要框架是Next.js和Nuxt.js框架。这些框架的优势主要来自前端，全栈开发，简单易学，支持Serverless部署。缺点是后端功能弱，自定义扩展困难，对平台支持依赖性强。下面是两个demo例子：上面是Next.js，下面是2020年的Nuxt.js。一份stateofjs2020Node.jsweb框架满意度对比调查报告显示，Next.js成功登顶，Express.js框架仍在获得关注。Node.jsWebFrameworkSatisfactionSurvey(stateofjs2020)总结Node.jsWeb框架迭代与前端行业的发展息息相关；前端应用场景不止是纯Node。.js的使用回归简单和轻便。Midway——前端框架的演进之路Midway是一个2014年开发的框架，发布了7个大版本，2018年正式开源。作为企业级开发框架，Midway主要包括TypeScript（静态类型，多人协作）、IoC（复杂架构、面向接口编程）、Egg（统一框架、复用生态）在技术选型上。MidwayDemo示例如下图所示：Node.js应用情况2019年集团Node.js应用情况：服务器利用率低：集团有1600+Node.js应用，每年cpu利用率率<10%，甚至5%，服务器利用率低。DevOps成本高：前端维护薄弱，Docker应用、限流、日志、跨语言等，DevOps成本过高。传统应用的不足限制了Node.js在阿里的进一步发展。前端呼吁后端下沉到大后台，前端向小前端发力，提高生产力。前端同学希望能够将中端服务快速组合成各种业务接口，并与端侧同步快速交付到前端，从而更快地响应业务需求的变化，助力业务试运行和错误。总的来说，就是要为前端赋能，让云原生为前端降本增效。技术方向基于以上现状和诉求，阿里巴巴前端委员会2019-2020年的四大技术方向分别为：建设服务;b.无服务器；C。智力;d.集成开发环境。面对用户群体分化的挑战，如何在一个框架下服务两类用户？前端工程师和Node.js工程师之间存在分歧。前端工程师偶尔会写接口，希望简单易用；对于Node.js工程师来说，因为每天要管理上万行代码，所以更看重的是应对复杂场景的能力。使用场景不同，如何在一个框架下支持两种场景？简单场景不同于企业级场景。简单场景需要快速实现CRUD和接口聚合；企业级场景侧重于可维护性、依赖注入和基础设施。简单的场景会逐渐演变为复杂的场景。前端范式转变目前主流前端正在从ClassComponent向Function+Hooks转变，包括React、Vue等，最终将导致函数式开发和OOP开发并存。那时候思路不一样了，那么框架有没有可能支持函数式开发，和OOP共存呢？解决方案：渐进式设计通过Midway的渐进式设计来解决。我们从下往上对Midway架构进行分层，主要包括Midway核心、编码范式、生态、场景、ModernWeb。前端的解决方案是Hooks。Hooks函数是接口JavaScript函数是接口，统一无协议。函数名生成路径，请求类型可根据参数长度确定，返回类型可通过TyperScript推断。这样就根据函数元信息生成了界面。获取请求上下文针对前后端范式不一致的问题，设置useContextAPI直接获取运行时参数。最后不用手动传入参数也能保持前端一致。示例代码如下：获取URL查询参数。CustomHooks专为全栈应用程序而设计。典型的项目代码目录。上图是一个典型的项目代码目录，包括服务器目录、界面目录、页面资源、应用入口等，都在src下，最终实现了统一管理和配置，共享src代码和类型。简化的接口调用“零”API调用不同于传统的接口调用。在集成应用中，只需要导入函数、调用函数和使用返回值，因为它们都在同一个src目录下，而且都是TypeScript。这种直接导入的方式是可行的，同时不需要生成和推断后端的返回值，最终实现“零”API调用，节省时间，节省文档，实现直接调用。渐进式-像积木一样进化。按照项目类型、开发方式、扩展组件、触发器、部署平台列出Midway支持的功能。就像搭积木一样，选择相应的积木即可实现。比如前端集成应用，可以选择集成项目、functional、Config、HTTP、FaaS，如下图：如果是后端，可以使用IoC+decorators、Middleware、ORM,Swagger,Cache,HTTP,gRPC,anddeploy在Server上实现复杂的企业级应用。也可以用于复杂度随时间增加的应用，如下图：ImplementationHooks于2020年4月发布，应用量超过2500个，是阿里前端的主流模型。综上所述，企业中还是存在简单场景和复杂场景，框架设计要考虑到这个问题；Node.jsweb框架应该专注于前端工程师的开发体验和设计；云+端研发模式将成为未来的主流研发模式。Future-standards-oriented&plannedtypesafety，比如社区的Prisma框架，可以生成ORM，可以根据数据库实时生成ORM。如果前端也自动生成，那么就实现了从前端到后端再到数据库整个链路的类型安全。如果后端修改了，前端也会自动报错。展望：目前云集成的提案有两种，分别是JSModuleBlocks（动态导入代码）和JSModuleFragments（模块可以命名，模块可以静态导入）。根据这两个方案，介绍我们的第三个方向，最终在一个文件中实现，可以实现server端，ssr端，client端的整合。方向示例目前正在与前端委员会标准化组推进TC39提案，反馈场景，争取推进到Stage2。项目网址：https://github.com/tc39/proposal-module-fragments/问题/14
