任何可以用 JavaScript 写的应用最终会被使用 JavaScript 来写。 -- 阿特伍德定律
本文介绍了小菜前端的基础设施在一步步走过的过程中，NodeJS 如何使用和发挥什么作用，对工程师个人、团队能力、公司研发效率、业务支持、技术探索和突破等有什么实际意义，为什么不是？ Python/C /PHP/Java 成为前端团队的核心技术栈。
被 NodeJS 框架进化速度加快
2019 年的前端与 2009 年的前端早已是君住长江头，我住长江尾，短短十年，人是物非，React/Vue 一统天下，Webpack 标配江湖，简单看近 2 年的 【Npm Trends】:
或者参考近 10 年的【Google Trends】：
热度在一定程度上反映了社区活动和占领市场的规模 AngularJS 也经历了过山车，市场被打破了 React/Vue 继续侵蚀，然后再把 jQuery 加进来看看:
即使是瞪口呆，即使 React/Vue(绿色和紫色) 如今，整个网络的搜索热度远低于 jQuery 和 NodeJS，尤其是 jQuery，尽管它的热度不断下降，但它仍然是整个互联网不可忽视的重要组成部分，
虽然早期与 jQuery 同时，还有许多其他框架类库，如 ExtJS/Mooltools/Dojo/Yui/Kissy 等等，但它们的体积比较 jQuery 如果列出你在过去十年里听到和看到的框架，数十或数百都不是问题，生命周期可以超过 5 年却很少，尤其是在 2012 年 NodeJS 框架的诞生迭代替换在全球推广到一定规模后更快，所以从框架的生命力来看，jQuery 到目前为止，它仍然是一个赢家，那就跟着吧 NodeJS 有什么关系？
NodeJS 持续变热，jQuery 部分原因是它继续冷却 NodeJS 新的框架和解决方案(不限于生态基础设施能力增长(不限于 AngularJS/React/Vue），也在不断蚕食 jQuery 如果没有市场 NodeJS，自然也不可能有新框架的繁荣之态，今天可能还是这样 jQuery 江湖统一。
无论是今天 Angular/React/Vue/Webpack，从开发经验、单元测试到包装编译 NodeJS 不能正常运转的生态，NodeJS 是整个上层建筑的物理基础和配套设施。
现在我们已经从宏观上了解了 NodeJS 对于前端框架进化和保证的重要性，下一步，结合菜肴前端 NodeJS 我们来谈谈它的重要性。 多年来，我们重用 NodeJS 参与了十几个重要工具/产品/系统的建设。以下是四个有代表性的分享：
第一次尝鲜 NodeJS - APP 热更新服务
写一些 NodeJS 自动脚本、代码验证甚至使用 Express/Koa 建立一些简单的服务并不是真正的意义 NodeJS，我们也抛开 ReactNative/Webpack 前端开发、包装和编译需要依赖 NodeJS 我们第一次真正使用这样的场景。 NodeJS， 就是对 ReactNative APP 开发的热更新系统，代号神奇博士，服务器框架 ThinkJS 框架，当时是 2016 年中，Scott 还没入职小菜。
这样的热更新发布系统可以让客户端 APP 最原始的更新流程如下图所示：
在热更新系统中，需要针对 iOS/Android 的 IPA/APK 对于特定操作系统的资源拆包、增量包/原包存储、包版管理、权限管理等功能，服务端童鞋等不太可能 Java 童鞋只能在前端自己做，也只能用 NodeJS 快速发展。
系统上线后，整个公司 App 发布频率从一个月一两次(审核会被打回)提高到一周三四次，效率至少会提高。 10 而且用户的更新体验得到了质的提升，对业务/运营/产品/用户都有很大的价值。
这时，我们概念中的这个时候 NodeJS 它可能更像是一个具体场景的功能玩具，并没有深入挖掘它的重要性和可能性。虽然它尝到了甜味，但它在未来一年多没有继续挖掘。
第二次尝鲜 NodeJS - APP 打包平台
Scott 是从 2011 接触和使用始于年 NodeJS，从 2013 年后技术栈以 NodeJS 开始尝试建立一个更复杂的系统，非常清楚它的优缺点，在 2017 年下半年开始带前端团队时，收到了很多反馈和投诉，主要分为两类：APP 更新失败的问题(在很高的迭代节奏下) 针对与前后端合作的接口/协调问题 APP 更新失败的问题。让我们先恢复当时的发展状态。如果有很多人合作 RN APP 可以参考我们下一步的做法，相信对你有用。
我们的 APP 当时一共有 5 个 - 宋小菜(对外)、宋小菜司机(对外)、宋小菜供应商(对外)、宋小福(对内)、秘密(对内) APP 都是 RN 开发，都有 iOS/Android 两个版本，包括商业开发版，要发布到苹果店，推到特定渠道，内部是企业包，不公开，我们通过公司自己的网站托管应用程序为员工安装。
这些 APP 业务之间也有一定的联系，通常开发宋小菜，也会联动修改宋小福或秘密，在当地开发中，需要在每个包里，区分连接是日常测试环境，还是在线生产环境，也区分可以打印日志 debug 包，还是非 debug 包，最后上线前，每个学生都在当地 Mac 在这个过程中上传到热更新平台。在这个过程中会有很多问题。我曾经画过这样一张图片，向服务器的学生解释为什么前端包装 APP 上线经常会出现问题:
这样会有很多组合，有的包要经常打，有的偶尔来几次，打包的时候要区分:
是哪一个 APP
是打 iOS 还是 Android 的包
是正式环境还是日常测试环境
打包要不要打开热更新功能，不打开就不会在线热更新流程
这个包应该实时连接到本地吗？ log 出来，也就是说，是否需要 Debug
哪个同学在电脑上打包？
这样，就可以打出硬组合 64 不同的包意味着可能需要修改配置文件 64 第二，此外，每个学生的电脑 Mac 操作系统版本会有所不同，XCode/Gradle 也许版本不同，更不用说了 Node 以及 NPM 安装的三方包，甚至当地预装的开发者证书也不一致，因此，整个团队陷入了包装/包装的正确性/一致性/能否打出一堆问题形成的泥坑，难以向外界解释，难以相互配合。针对这个问题，我们的想法是让这些傻瓜自动化一点，让团队共享一个包装环境，以包装为准，于是我们启动了叔叔的包装平台，购买了一个高配置 Mac Mini 在内网部署，通过界面管理所有配置项，简要流程如下：
一开始界面很简单，看起来是这样的:
该系统在线 1 年来，我们已经打了 1000 多个包因包装而出现环境错误 0 第二，大大解放了团队效率，提高了包装的正确性。更重要的是，团队也沉淀了一些基础 Node 使用技能增强了每个人使用它的信心：
第三次尝鲜 NodeJS - 报告快速制作平台
无论是 toB 还是 toC 无论是直接导出，公司都会将数据库中的数据提出 Excel，或者通过接口输出到前端页面显示，只是需要，配菜也不例外，配菜业务早年变化特别频繁，每次变化都需要提出一堆报告需求来监控调整业务变化是否符合预期，如果没有报告就像算命一样依赖猜测，然后这样一个普通的需求不能再普通了，却让整个产品技术团队头疼了好几年。
在紧张的业务开发项目中，让前后端抽出资源对接报告字段，然后通过接口 - 页面的联合调和发布是一件非常浪费资源的事情。后端感觉像是在写 SQL 接口胶代码，前端感觉纯粹 Table 报表页面小，资源交叉冲突往往导致报表优先级降低，甚至长期拖延给业务方，所以公司做了整整 3 年，总共产出 50 多个报表零散的扔在 ERP 在系统中，针对这个问题，前端启动了一个项目 - 大表哥报表平台用于解决报表输出效率问题 SQL 自动生成到页面，后端工程师，甚至 SQL 产品经理和运营商可以在平台上按照约定的规则粘贴一些 SQL，或者基于编辑页面组装一些 SQL 子句，咔咔！该系统在线生成报表 1 在过去的几年里，生产力突然释放，总共产出 400 多张报表：
公司员工每天浏览报表一两千次，直接导出 Excel 就导出了 1 万 6 一千多次，已成为公司内部最成功的工具产品之一，服务于全公司各部门，报表显示如下：
一个报表的制作界面大概长这样：
通过对SQL 的各种查询词的组件封装，可以从界面快速生成一个可在数据库执行的复杂 SQL 语句，或者反向贴入符合规则的 SQL，自动拆解成报表的表头（字段的中文名称），自动映射到组件（日期、排序、筛选、二级跳转的子报表等等），包括整个报表的需求提出、描述、认领、上下线、制作和发布这样的工作流等等也全部用 NodeJS 实现，这次尝鲜不仅奠定了 NodeJS 在前端团队绝对的位置，也实质性的在支撑业务这里拿到了很好的结果，更让我们感到欣喜的是，在报表系统里面使用 GraphQL 是多么的便捷，同时前端部门独立支撑数据相关的业务产品这条路变得可行，NodeJS 的角色从工具也延展到了业务。
第四次尝鲜 NodeJS - 前后端数据聚合服务
如果说前面几个，都是与服务端团队解耦的，是前端可以独立完成的，那么这一次，则是跟服务端在职能上和系统上都有强耦合的地方，是跨团队研发层面的尝试，这次发生在 2018 年 2 月份，也就是在前两次尝鲜后，我们又一次比较大胆的突破。
背景依然是前端的页面与后端的接口这里，关于这个后面会专门有一篇详细与大家聊聊前后端合作研发上我们的思考，这里我简述一下，前后端的合作方式通常是数据接口，也就是数据格式和字段约定，一个吐数据一个消费数据，吐什么样的数据取决于消费什么样的数据，消费的数据则来源于产品流程上的 UI 展示形式，一份概念里统一的数据，是有可能被分拆成两个 UI 块展示和复用，可能会让接口颗粒度更小拆成 2 个，或者共用一个大的，频次高一些的 UI 改版也会导致接口的通用性变得很弱，最终产生一堆大而全的重体积接口，进而对前端维护页面和用户的加载产生较大的影响。
而且接口里面永远是黑盒，在前端是看不全接口的能力了，一旦文档没有跟上，接口的输出与 UI 的使用便会脱节，为产品运行的带来了更强的不稳定性，所以我们会希望接口都是纯粹的，用到多少字段就输出多少字段，用到什么格式就输出什么格式，同一个页面的数据，尽量一个接口返回而不是三四个接口返回，但这显然对服务端提出了更高的要求，也是很多公司从前端产品层面试图推动后端团队时候无功而返的最大阻力。一个人群中，大部分人都倾向于不作出改变，在没有看到太多对自己带来的好处之前，而短期成本与长期红利之间大部分会选择短期，因为它容易预见。
我们的解决办法是，用 NodeJS(EggJS) + GraphQL 搭建一个系统，它负责三件事：
负责对前端输出所需数据（单接口，要什么给什么，无冗余可组合）
负责去拿所有的服务端微服务接口数据（HTTP 协议或者 RPC 协议）
提供一个可以在线连接接口、约束字段以及实时 Mock 的编辑系统
对它的要求是可在线编辑，可联调测试，可数据热发布与热回滚，这个系统上线后，我们接管了 2 款 App 的接口需求，前端拼装页面和组合数据时候变得更灵活自如，同时正向逆向的数据监控，让我们对数据更有把控力，对于服务端来说，也可以更加不关注 UI 如何，更关注业务领域的搭建与标准数据接口的封装，它的界面长这个样子：
还有接口地图、数据关系网络、接口字段监控、Mock 系统等等不再一一截图，这个 NodeJS 搭建的系统的复杂度还是蛮高的，上线后我们专门组织了一场技术分享 - 杭州第一届 GraphQLParty，让它开源的群众呼声很高，我们觉得还需要更多 NodeJS 的专家进来把系统进一步完善后，才真正能达到开源的标准，目前依然是在公司内部使用。
第五次尝鲜 NodeJS - 全链路端监控系统
小菜从 2014 年第一款 APP 上线，到如今将近 5 年，5 年风雨 5 年征程，虽然技术部有 80 人，前端有 20 人，我们依然对自己所研发的 8 款 APP、4 款小程序、6 款 H5 商城系统、10+ 个 PC CRM/IM/ERP/TMS 中台运营系统的用户使用情况、线上异常情况、设备分布情况、营销活动的 PV/UV 转化情况统统一无所知，**于是启动了全链路监控这个项目，这个项目几乎全部由前端独立完成，有使用到服务端团队搭建的 ELK，一共历经 60 天的疯狂开发，沉淀了如下几个 Node 系统或者服务：
Node 服务 1：数据转发器 DataTransfer
Node 应用 2：监控后台
Node 服务 3：任务控制器 Controller
Node 服务 4：任务执行器 Instpector
以控制器 Controller 为例，它主要针对 issue 的管理，功能纯粹但逻辑略重：
线上 bug 发现，新 issue 的生成、分类和发送警告
某一个 bug 在某个时间段内发生次数过多(如 100次/1m )的警告
某一个已经标记为已解决的 issue 又再次发生，需要通知到相关 issue 的负责人
bug 报告生成，这样就能让开发负责人们对端质量上有一个更量化认识
除了 UV/PV 等访问型数据，异常聚合的 issue 也可以很方便的管理：
整体的架构关系图如下，可以看到控制器所在的位置：
从这样图也可以看到，小菜前端不再是单点建设，而是更有层次的将 Node 应用组合起来，来共同完成全链路监控这样复杂的事务，这一次尝鲜是小菜前端新的里程碑，标志着我们正式具备了处理复杂问题的能力。
关于这个监控系统，之前有过专门的分享，大家可以翻看公众号 - 前端早早聊 的历史文章。
综上，小菜前端基于 NodeJS 既有 Eat My Own Shit 的内部场景的问题解决，也有直接服务于前端产品的工具，也有直接把数据当做业务来支撑公司决策的业务产品，还有专注在前后端研发效率的数据聚合层的全方位尝试，从内到外从前到后，而这些系统的尝试，又为前端团队沉淀了非常多的服务端能力，系统设计能力，甚至带来跨语言栈的变化，所有的这些变化可以影响到整个团队的基础设施建设速度和质量，虽然我们有了如此多的尝鲜，但我们也仅仅从一个刀耕火种的前端团队，刚刚开始迈向工程化的大前端团队，可以从下图看到整个团队的基建进展情况：
这张图上，绝大多数的系统建设，都离不开 Node.js，更关键的是，团队的童鞋们，经过这些基建的硬仗，技术能力也都有很大幅的提升，所以 NodeJS 越来越成为前端团队的核心技术栈，一切基于它的深度尝试，只要能贴合你团队的痛点，公司业务的痛点，那么都是值得尝试的。
Scott 近年面试或线下线上技术分享，遇到太多前端同学，由于团队原因/个人原因/职业成长/技术与管理通道，甚至家庭城市等等原因，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，大家可以找我聊聊南聊聊北，对工程师的宿命和价值有更多的看见与了解，Scott 微信：codingdream，也可以来关注 Scott 跟进我的动态。