2.2　业界用Node.js做什么

在日常工作中，前端工程师通常会使用Node.js做哪些事情呢？下面来看一下。

2.2.1　前端工程化

毫不夸张地说，Node.js对前端开发的推动作用简直就像“工业革命”对生产力的推进作用一样。十几年前，JavaScript连最基本的模块化规范都没有，代码的优化也只能依赖于IDE的简陋工具和手动优化。现今的前端开发工作流则已经拥有了全生命周期的自动化工具支持：Yeoman提供的脚手架定制能力可以使开发人员快速生成指定技术栈的目录框架；使用npm包管理工具可以直接通过命令行获取所需要的依赖库；以webpack为代表的打包工具不仅能够在开发过程中提供实时编译和热更新支持，还能够依靠高可定制的参数配置对源代码进行优化，并最终构建出可用于生产环境的程序；ESLint提供了代码校验功能；Prettier提供了格式美化功能；Babel提供了“ES6+”代码到低版本JavaScript语言的编译功能；Mocha和Karma提供了跨浏览器自动化测试的功能；Istanbul提供了代码测试覆盖率检测的功能；TypeScript提供了强类型和面向对象的特性；Git命令行提供了代码管理功能。更重要的是，开发人员可以通过Node.js定制私有的命令行工具集，来对这些基础的工程能力进行集成和扩展，从而打造出属于自己团队的前端自动化工具链或解决方案。

除此之外，“多端编译”技术也是前端工程化领域的热门方向之一，它可以让开发人员只编写一套源代码，即可通过配置编译出H5程序、Android、iOS及多个平台的小程序，业界已经有很多团队推出了相关的技术。而这些技术变革的推动力，正是Node.js那看似平淡无奇的文件读写能力。当然随着技术的发展和演进，像Esbuild这类尝试通过跨语言实现高性能的工具也在逐渐兴起。

2.2.2　中间层

在前后端分离的时代，前端开发人员自然希望后台返回的数据正好就是自己需要的格式，这样只需要把这些数据挂载到相应的组件属性上，剩下的事情交给框架就可以了，省去了二次加工的过程，前端代码通常也会因此变得更加简洁。然而，在后端开发人员的认知里，这种杂务当然最好由前端来完成。

Node.js的服务端开发能力使得业界在“前后端分离”的基础上衍生出了“中间层”的概念，并为这部分烦琐却都觉得“应该由别人来实现”的代码提供了一种优雅的实现方式。“中间层”，顾名思义就是建立在前端和后端之间的逻辑分层，最大的作用就是整合，包括整合接口、整合数据、整合逻辑，通常由前端工程师编写和实现。中间层的出现，既可以使客户端工程师专注于编写清晰的“声明式组件”代码，也可以使后端工程师在提供相应的业务逻辑接口后，能够专注于系统性能和稳定性的提升，其他的事情则可以放到中间层完成。

如果你所面对的数据存在很多历史遗留问题，组装的过程也非常复杂，那么可以将它们放在中间层，利用服务端的运算能力来处理，就不必考虑在耗时的数据拼装过程中如何保证浏览器的主线程不会因为阻塞而失去响应了。作为数据的消费者，如果客户端程序获取的数据直接可用，那无疑会是一种福利。有时候需要展示的数据来自不同团队维护的不同接口，这些接口之间可能是协作关系，也可能是竞态关系，甚至有些重要的接口是需要隐藏起来的。这时，利用中间层来聚合接口和逻辑，就可以将复杂的逻辑链条和各个请求细节都隐藏在服务端，只为客户端暴露一个调用接口，并最终返回数据或包装后的异常信息。除了接口整合和数据清洗之外，中间层代码还可以完美胜任鉴权和会话管理、请求过滤、访问日志记录、应用接口升级等任务。

中间层的出现也是“单一职责原则”的体现，它使得整体的技术架构变得更清晰，每个环节需要承担的宏观任务类型也变得更加清晰。客户端负责交互、渲染和状态记录，中间层负责整合连接和清洗数据，后端负责基础服务逻辑、性能和容错。这样的架构能够使不同的模块职责更加清晰，代码的可维护性也会变得更好。

2.2.3　SSR引擎

SSR是指服务端渲染（Server Side Render），其实服务端渲染并不是什么新技术，只是在Node.js的帮助下，前端工程师可以更方便地实现该技术。在Ajax技术出现以前，网页本来就是在服务端渲染的，例如，Java技术栈使用的JSP技术就是在服务端动态生成网页，然后传输给客户端进行显示的。但随着单页面应用模型的广泛使用，以及浏览器性能的不断提升，前端可以自行在JavaScript程序中独立完成页面的动态渲染，所以除了那些对访问速度有较高要求且变化较少的项目，更多的项目仍然会采用客户端渲染的方式来实现。在现代开发中，基于框架的SSR技术也称为同构直出技术。“同构”是指开发者在服务端开发时，可以使用与客户端开发一样的技术栈并复用同样的组件，三大SPA框架都推出了自己的同构直出框架；“直出”则是指模板渲染的过程是在服务端完成的，从而将可直接使用的页面、文档片段和脚本返回给客户端。SSR技术通常可用于以下几个典型场景。

1. 提升首屏渲染速度

由于SPA框架具有动态渲染的特点，因此在渲染首屏之前往往要进行初始化操作，同时加载其他资源，这就使得使用者不得不面对一段较长的白屏时间，既影响使用体验也容易造成用户流失。为了解决这个问题，将首屏内容或经过设计的等待页面放在服务端渲染，并优先展示给用户，可以有效提升用户体验，从而避免用户流失。

2. 提升搜索引擎优化（SEO）性能

现代SPA框架的动态渲染特性使其在应对搜索引擎爬虫时表现得很不友好，因为爬虫只能抓取静态页面的内容，而SPA框架的静态HTML页面通常只是一个包含了内容挂载点的空页面。利用服务端技术就可以很好地解决这个问题，当检测到访问者为爬虫机器人时，会返回渲染好的页面，以便它可以分析其中的内容，从而提升网站的搜索引擎优化性能。

3. 独立运营页面的制作

运营页面通常是独立于主程序而存在的，其内容会随着运营活动的变化而不断更新，且访问量较大。用SSR技术来实现可以让页面更快地完成构建和渲染，因为它不必加载主程序中那些自己并不依赖的第三方库。同时，运营页面本身就具备时效性，服务端渲染的实现方式也使得它更容易在使用后下架。

2.2.4　协作连接

Node.js无疑是一种能够帮助前端工程师成为团队核心成员的技术，它提供了一种更加简单有效地推动团队协作的方法，那就是不要总提要求，而是要为团队成员提供自动化的工具。与UI人员进行协作时，可以使用BackstopJS来完成开发结果与UI的自动化回归测试，或者像阿里集团的开源项目Fusion Design那样尝试提供开发端和设计端两种工具，从而帮助设计师和开发者统一认知和物料。在与后端人员进行协作时，可以使用DocLever或Rap2搭建内部API管理平台，推动更加规范的API管理工作流，以免因为API的不断变动而承担额外的工作。又或者通过在中间层提供日志来协助运维人员获得更多有针对性的信息，甚至对于一些更大体量的可视化工具的开发，即使Node.js没有出现在生产环境的技术选型中，它也依然拥有属于自己的重要角色。

协作中遇到问题是在所难免的，不断指出别人的问题总归是一件影响团队协作的事情。有了Node.js的帮助，前端工程师就可以主动思考和优化与团队其他成员的合作方式，并将可行的实践转化为工具，提供给其他与自己工作有交集的协作者，以便在实践中逐步完善。试问谁不喜欢与这样的同事合作呢？当你用解决方案取代命令和抱怨时，自然会赢得属于自己的那份尊重。在这个过程中，你也更容易学会从用户和产品的角度来看待事物，这是很多初级开发者都缺乏的视角。