版权归作者所有。商业转载请联系Scott获得授权，非商业转载请注明出处【务必保留全文，请勿删改】。在过去的两年里，无论是线下和线上的面试还是技术分享，Scott都认识了很多前端同学。由于团队原因、个人原因、职业成长、技术方向，甚至家庭原因等等，理想国与现实存在差距，在放弃与坚持之间，不断摇摆，心碎与倔强，你可以和我聊南北，多了解工程师命运，多看多听，Scott微信：codingdream。本系列共有15篇文章，这是第二篇。大家看完转发朋友圈后我就很满意了。任何可以用JavaScript编写的应用程序最终都会用JavaScript编写。--Atwood'sLaw本文一步步介绍了NodeJS的使用方法，以及它在小菜前端基础架构过程中扮演的角色。支持、技术探索和突破等有什么现实意义，为什么它代替Python/C++/PHP/Java成为了前端团队的核心技术栈。NodeJS加速了框架的进化速度2019年的前端和2009年的前端已经住在长江头，我住在长江尾。短短十年，人不同，React/Vue一统天下，Webpack标配江湖。看看过去2年的【NpmTrends】：或者参考一下过去10年的【GoogleTrends】：受欢迎程度在一定程度上反映了社区的活跃度和市场的规模。可以发现AngularJS也经历了过山车，市场不断被React/Vue蚕食，再加入jQuery再看：如火如荼的今天，它远低于jQuery和NodeJS，尤其是jQuery，在整个互联网的搜索热度上，虽然jQuery的热度持续下降，但它仍然是整个互联网不可忽视的重要组成部分.虽然早期还有很多和jQuery同一个时代的其他框架库，比如ExtJS/Mooltools/Dojo/Yui/Kissy等等，但是它们的体量还是远远不如jQuery的。如果把你近十年听到看到的框架都列出来，几十个甚至上百个都不成问题，生命周期能超过5年，但很少，尤其是NodeJS推广到一定规模之后2012年在全球范围内，框架诞生和迭代更新换代的速度更快，所以从框架的生命力来看，到目前为止，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搭建一些简单的服务。抛开ReactNative/Webpack等前端开发包需要依赖NodeJS打包编译的场景，我们第一次真正使用NodeJS是ReactNativeAPP开发的热更新系统，代号DoctorFantastic，以及用于服务器端框架的ThinkJS框架。现在是2016年年中，斯科特甚至还没有开始工作。这样的热更新发布系统可以让客户端APP动态更新为增量代码包。最原始的更新流程如下图所示：在热更新系统中，需要为iOS/AndroidIPA/APK包更新特定操作系统的资源。解包、增量包/原生包入库、包版本管理、权限管理等功能，这些东西不太可能是Java童鞋等服务端童鞋给你做的，只能由前端来做本身，也只有用NodeJS才能快速开发。系统上线后，整个公司的APP发布频率从一个月一两次（审核会回调）增加到一周三四次。效率提升了至少10倍，用户的更新体验得到了质的提升。/operations/products/users具有很大的价值。这个时候，我们概念中的NodeJS可能更像是一个针对特定场景的功能性玩具，我们还没有去探究它的重要性和可能性。虽然尝到了甜头，但一年多来我们还没有继续探索。小菜的第二个NodeJS尝鲜者——APP打包平台Scott从2011年开始接触和使用NodeJS，从2013年开始，技术栈一直以NodeJS为主，他尝试构建更复杂的系统。他很清楚它的优点和缺点。2017年下半年开始带领前端团队时，收到了很多反馈和投诉，主要分为两大类：APP更新失败（迭代节奏非常快的情况下）和界面问题/前后端协同的联调问题，针对APP更新失败的问题，先还原一下当时的开发状态。如果你也有多人协作开发RNAPP，可以参考我们接下来的做法，相信对你有用。我们当时有5个APP——宋小菜（外部）、宋小菜司机（外部）、宋小菜供应商（外部）、宋小福（内部）、菜米（内部）。所有app均为RN开发，有iOS/Android两个版本，其中外部版为商业开发版，必须发布到AppleStore并推送到特定渠道，内部版为企业包，不向公众披露。我们通过公司自己的网站托管应用程序供员工安装。这些应用的业务之间也存在一定的联系。通常在开发宋小菜的时候，也会链接修改宋小芙或者菜米。在本地开发的时候，需要在每个包中区分是连接到日常测试环境还是上线。在生产环境中，还需要区分是可以打印日志的debug包还是非debug包。最后上线前，每位同学在本地Mac打印一个包上传到热更新平台。会有很多Question，我曾经画过这样一张图来给服务端的同学解释为什么前端打包APP上线时经常出问题：这样一来，就会有很多组合。需要区分：哪个app是iOS包还是Android包，哪个是官方环境包，还是天天测试环境包。是否开启热更新功能？连接本地打一些日志，就是Debug包是否打印在哪个同学的电脑上。这种硬组合可以产生64个不同的包，也就是说配置文件可能需要修改64次。另外，每个同学的电脑上的Mac操作系统版本都会不一样，XCode/Gradle的版本也可能不一样，更不用说Node和NPM安装的三方包了，就连本地的预装的开发者证书有时不一致，所以整个团队都卡住了。为了解决打包/打包正确性/一致性/是否可以打出一堆问题，对外难以解释，相互之间也很难合作。针对这个问题，我们的想法是让所有这些事情都稍微自动化一点，并由团队共享。一个打包环境，基于它打包的包，所以我们推出了Dabobo打包平台，购买了一台高端的MacMini部署在内网，通过接口管理所有的配置项。大致过程如下：接口1开始很简单，大概是这样的：系统上线一年来，我们打包了1000多个包，0个因为打包导致的环境错误，大大解放了团队的效率，提高了打包的正确性。更重要的是，对于团队来说，也积累了一些基于Node的技能，更加坚定了大家使用它的信心：小菜第三个尝鲜NodeJS——快速报表制作平台，不管是toB还是toC公司，提取将数据库中的数据导出到Excel或者通过接口导出到前端页面是硬性需求，小菜也不例外，早些年小菜的业务变化非常频繁。每次有变化，需要一堆报表需求来监控调整前后。业务变化是否符合预期，如果没有报告，那全是算命一样的猜测，再这样的平凡就不能再平凡了然而，小菜的整个产品技术团队多年来一直面临着头疼的问题。在紧张的业务开发项目中，前后端抽取资源将报表字段一一对接，然后使用接口-页面联调发布是非常重要的。浪费资源，后端感觉是SQL和接口胶水代码，前端感觉是纯Table报表页面boy，经常资源冲突导致报表优先级低甚至延迟很久才可以交给了业务方，所以公司干了3年，只做了50多份报表，散落在ERP系统中。针对这个问题，前端推出了一个项目——大表哥报表平台，用于解决报表输出效率的问题。题目是实现自动生成SQL到页面。后端工程师，甚至懂SQL的产品经理和运维人员都可以到平台上，按照约定的规则粘贴一些SQL，或者根据编辑页面拼装一些SQL子语句，咔咔！报表生成，这个系统上线一年，生产力一下子释放出来，总共生成了400多份报表：公司员工每天浏览报表一两千次，并且直接导出到Excel已导出16000多次。是公司最成功的工具产品，服务于公司各部门。报表展示大概是这样的：制作报表的界面是这样的：通过将各种查询词的组成部分封装在SQL中，可以从界面快速生成报表。数据库中可执行的复杂SQL语句，或符合规则的反向粘贴SQL，自动拆解成报表表头（字段中文名），并自动映射到组件（日期、排序）、过滤、二次跳转）子报表等），包括整个报表的需求、描述、声明、线上线下、生产发布工作流程等都是用NodeJS实现的。这个尝鲜不仅奠定了NodeJS在前端团队中的绝对地位，而且实质上，我们在支撑业务方面也取得了不错的成绩。更让我们欣喜的是在报表系统中使用GraphQL是多么的方便。同时，前端部门独立支撑数据相关业务产品是可行的。NodeJS的作用从工具扩展到了业务。小菜第四个尝鲜NodeJS——前后端数据聚合服务。如果说前面几项是和服务端团队解耦，可以由前端独立完成的话，那么这一次，就跟服务端的功能和系统有关了。互联网上有强耦合，是跨团队研发层面的一种尝试。这次是在2018年2月，也就是在前两次尝鲜之后，我们又一次大胆的突破。这里的后台依然是前端页面和后端的接口。关于这一点，会有专门的文章详细谈谈我们对前后端合作的思考。数据格式和字段约定，一个吐出数据，一个消费数据，吐出什么样的数据取决于消费什么样的数据，消费的数据来源于产品流程上的UI展示形式，统一数据概念，有可能会拆分成两个UI块进行展示和复用，这可能会让界面粒度变小拆分成2个，或者共享一个大的。更高频率的UI改版也会导致界面通用性变弱，最终产生一堆大而全的大容量界面，进而对前端维护页面和用户的加载带来更大的影响。而且，界面始终是一个黑盒子，前端看不到整个界面的能力。一旦文档跟不上，界面的输出就会和UI的使用脱节，给产品的运行带来更大的不稳定，所以我们希望界面是纯粹的，输出为许多字段，因为它们被使用，并输出使用的任何格式。对于同一个页面的数据，尽量只返回一个接口，而不是三四个接口，但是这样明显影响服务。也是很多企业试图从前端产品层面提拔后端团队而无功而返的最大阻力。在一群人中，大多数人在看到对自己的好处太多之前往往不会做出改变，而且大多数人会在短期成本和长期红利之间选择短期，因为它很容易预测。我们的方案是用NodeJS（EggJS）+GraphQL搭建一个系统，负责三件事：负责在前端输出需要的数据（单一接口，你想要什么，没有冗余可以组合）负责获取所有服务器端微服务接口数据（HTTP协议或RPC协议）提供了一个编辑系统，可以在线连接接口、约束字段和实时mocks。它的需求是在线编辑、联调测试、数据热发布和热回滚，系统上线后，我们接手了两个APP的接口需求。前端组装页面和组合数据变得更加灵活。同时，正向和反向数据监控让我们对数据有了更多的掌控。对于服务器来说，可以少关注UI，多关注业务领域的构建和标准数据接口的封装。它的界面是这样的：还有界面图、数据关系网、界面字段监控、Mock系统等，一张一张的截图可以看出NodeJS构建的系统复杂度相当高。上线后，我们专门组织了一场技术分享会——杭州首届GraphQLParty，将其开源。我们觉得需要更多的NodeJS，只有领域内的专家进来进一步完善系统，才能真正达到开源标准，并且还在公司内部使用。综上所述，基于NodeJS，小菜前端不仅解决了EatYourOwnShit的内部场景，还有直接服务于前端产品的工具，也有直接将数据作为业务来服务的业务产品支持公司决策，专注前后端研发。从内到外，从前台到后台，对高效数据聚合层的全方位尝试，而这些系统尝试为前端团队积累了大量的服务端能力和系统设计能力，甚至带来了跨语言堆栈的变化。童鞋们的技术能力也有了很大的提升，所以NodeJS越来越成为前端团队的核心技术栈。目前NodeJS的第五次大规模使用集中在运维健康体系的构建上。我相信在你的团队中，基于它的深度使用，只要能贴合你团队的痛点，公司业务的痛点，解决问题带来价值，那么这些尝试或者试错都是值得肯定和鼓励。最后，作为一篇预热文章，本文旨在为大家输出以下主题：输出一个团队从0到1的成长过程总结，从野蛮到自动化运维到社区，帮助更多的小团队少走弯路量化的方式将困惑、沉淀和方法路径聚集在小菜前端，给团队带来更多的创作成就感。从更多的角度，进入团队管理/技术进化/个人成长的过程，探索工程师团队的价值最大化。如果大家感兴趣，我们小菜前端团队会集思广益，编写并出版一本关于前端职业、技术成长和团队成长的小册子，回馈给大家。记得在文章后面留言求需求，别忘了加Scott微信：codingdream。
