第十期 AMA，掘金团队请来了阿里 Node 基础框架 EggJS 的核心开发者 -- 天猪做了为期三天的 Ask Me Anything (AMA) 活动（已结束）。

我们在此精选了一些来自用户的提问及天猪的回答。

关于天猪

个人 GitHub：https://github.com/atian25

个人知乎：https://www.zhihu.com/people/liuyong25/activities

个人掘金主页：https://juejin.cn/user/289926769031149

个人微博：https://weibo.com/liuyong25?is_hot=1

社区小伙伴精选提问

Egg 的最大的亮点是什么？ ─ @Lanwy

围观大佬，可以说下你觉得 Egg 的最大的亮点是什么吗？😃只能说一点

最大的亮点是定位吧，Egg 的定位是框架的框架，在 Koa 的基础上提供了一套加载规范，从而延伸出插件和上层框架的概念，达到生态共建和差异化定制的平衡点，助力不同团队的架构师孵化出适合自身业务场景的上层框架。

过多约束是否阻碍 egg 的大规模推广─ @托尼的夏天

egg 相比其他 node 框架，约束太多了，这是否阻碍了它的大规模推广

首先，Egg 是很轻量的，它的约束其实很少，就寥寥几个扩展点，比起 sails loopback 等上层框架可谓极简了，它专注于提供这些上层框架的最核心的共性 - 一套加载器。你觉得太多，可能是我们官网文档的问题，很多都是插件提供的，并没有集成。

其次，Egg 并不太需要推广，它最初是为了支撑阿里内部各大 BU 之间的协作问题，涉及到各行各业，譬如电商，自媒体，游戏，金融等等千差万别的业务场景，因此我们的定位是专注于做框架的框架。如下图所示

另外，我们这几个人一直都受益于开源，因此一开始的目标就确定要开源出来。至于推广，老实说，不是我们的 KPI。

hapi 和 egg 的差异在哪？ ─ @chenchao

都是配置优先，请问，hapi和egg的差异在哪？在企业开发中，如何抉择？两者有没有哪些对比express凸显出来的劣势？

hapi 并没有配置优先吧，它跟 Express，Koa 是差不多层次的，都在微框架这一层。Egg 是在它们之上加了一层 Loader 机制。一般我们基于 Express 或 Koa 开发的时候，团队里面往往都会在上面封装一层业务框架，Egg 的定位就是抽象出这一层的一些通用能力，让大家基于同一套基础规则来封装上层业务框架，达成生态共享的状态。

Express 的局限性，刚好最近我的一本书中有总结了下，主要在于：

只是对 Node 的 HTTP API 做了一层很薄的封装，暴露给开发者的 API 抽象程度不够，不便管控。

中间件模型是线性的，管进不管出，只是处理了 req 进来那条链路，而没有管 res 出去那条。

基于 Callback 的中间件模型，不可避免的受到回调地狱的影响。

egg的扩展中help.js和app.js哪个更适合扩展工具方法？ ─ @magican

egg 的扩展中 help.js 和 app.js 哪个更适合扩展工具方法？就约定来说适合 help，但是 help 是绑定到上下文的，就内存占用是不是 app 更好？

内存这个不要去过多考虑，基本上按大家的业务量级，不会有什么问题的。在我们的定位里面，helper 是给到模板来做局部的 formatter 的。扩展方法，看你具体的场景，甚至可以放到 ctx.service.xxUtils 上

国内用node做后端的情况还多吗？职业发展要怎么规划？─ @gea

天猪大佬，现在国内用 node 做后端的情况还多吗？职业发展要怎么规划？因为我是一个两年多工作经验 noder，开始工作的时候是做前端，我自己转型做后端，现在做了接近两年的纯 node 后端工作，最近感觉大多数企业把 node 的场景都开始向前偏移了，我个人觉得 node 用来做后端是足够的，性能方面也不是那么大的硬伤，可以通过 k8s 等一系列的架构和方式去消除减弱性能的缺点，但是 node 后端越来越少，要转向前端还是转向其它语言呢？

微服务化其实给 Node 带来的是利好，提供服务即可，不关注后面的语言。目前国内用 Node 的团队，我觉得是两极分化：

阿里这样的大公司，有完善的基建和中间件支撑，因此可以大放异彩。

创业小公司，追求速度和效率，所以也能放手实践。

反而是中间的中小公司，包括一些大公司里面的团队，受限于运维基建和话语权，推起来比较痛苦。

性能其实各大语言发展到今天，对于绝大部分业务场景来说，轮不到拼这个天赋的时候。选择一个技术，更多的是看团队的技术栈 + 运维基建 + 中间件服务支撑程度 + 话语权。

就 Node 发展的话，建议还是进阿里体验一下，在国内阿里的 Node 和其他公司，是完全两个不同的阶段。或者至少了解下阿里 Node 在这个过程中的实践，踩坑经验，未来方向，从而有的放矢。

点评下nest，说说您或者egg团队对他的看法？─ @鲸吃瓜

请问天猪大哥能否简单的点评下nest，说说您或者egg团队对他的看法，以及他的优缺点🙃

nest 是近年来新出的一个框架，比较亮眼的是 TypeScript 和从 Spring 过来的一些概念。

从我们的角度来看，企业级应用有很多要素，包括编程模型约束、扩展点、多进程管理、日志、安全、RPC 等等非常多的方面，TypeScript 静态类型带来的好处，是其中的一小点，但并不是全部。装饰器等特性，目前还在 Stage 阶段，并没有落地到 Node LTS 版本中。在我们看来，静态类型带来的好处，还不如把单元测试覆盖率做上去更实际。

TypeScript 也并不是某个框架独有的，就像蚂蚁凤蝶团队就有在用 TS 开发 Egg 应用（听说他们做了个 tegg 框架，后面也许会放出来）。

顺便重提下框架对比，从我们的角度看来，框架有三层：

基础框架：Express，Koa

框架的框架：Egg

上层业务框架：tegg，chair，sofa-node，ThinkJS，Sails，Loopback，Nest

它们的定位：

微框架专注于底层中间件模型，是 Node HTTP 之上很薄的一层。

上层业务框架，是针对某个领域和业务场景定制的业务框架，针对团队自身的业务场景和技术选型下的组合。（当然也有一些大教堂式的大而全框架）

上层业务框架一般每个团队都会封装一个，就像当年阿里各大 BU 那样，而 Egg 就定位介于前面两者之间，抽象出上层框架的一些共性 -- 一套加载规范，一方面提供插件能力来复用，一方面提供框架定制能力供团队架构师定制自己的上层业务框架。

Node 新人如何成长？─ @L丶q

一直混迹于创业公司，致力于各种业务以及解决问题，有时候特别基础的知识都要去查一下才能确定，个人技能也是层次不齐，感觉迷茫了怎么办

关键还是总结，遇到问题后，多思考，遇到了什么问题，解决了什么问题？同类场景是如何解决这个问题的？他们之间的对比是怎么样的？谁优谁劣？如果他们的方案各自优点结合起来，又会怎么样？

或者这么说，未来你参与面试的时候，面试官希望听到你说「我用过 xx 框架」，还是希望听到你说：「我在做 XX 项目的时候，预研过 XX 和 YY 框架，最终因为 XX 等原因，我选择了 XX 框架。在这过程中，我遇到了 XX 问题，为此我去看了 XX 源码，发现他们是基于 XX 原理的，还有优化的空间，于是自己尝试了 XX，解决后写了 XX 总结文章，甚至尝试给 XX 框架提了一个 PR 解决了这个问题」 -- 这句话好像是小芋头说的。

对话：天猪 & 杨雪晋 & 字字珠玑关于开源、egg.js 社区的看法

杨雪晋：我在公司的技术选型中 Node 一块使用了 Egg，两期下来发现开发没问题但体验很一般。错误提示很不明确，官方文档华而不实，三方模块滥竽充数，框架约束邯郸学步。错误提示方面您可以说是 Nodejs 异步原因不好定位错误，官方文档只是好看但业务开发中我们发现很多地方文档没有详细说明，第三方模块诸如 egg-jwt 典型的 npm copy 过来改改充数的也能被官方推荐使用，egg 的框架约束对比一下 Laravel，目录和模块名作为类，大写后，路由却必须小写！而且关于模块的引入 ES6 提供了两三种方法，官方文档和你们开发的 cnode 社区源码上用的是代码重复量多的那种，关于 Controller 层有个 egg-validate 插件的使用也可以独立出来文件中，也可以放构造函数中，这些官方文档都没有说明，自定义参数检验和定时器这些更不那么重要但是简单的确说明过度了。

天猪：

感谢反馈，社区这块确实有挺大的进步空间。你指的滥竽充数是 awsome-egg 那个吧？那个目前只要是提 PR 就能合并的，目前只作为一个索引，我们并没有精力去逐个分析源码和评价方案，这块如果社区有同学有兴趣，可以考虑参与进来接管。

jwt 那个是社区插件，不是官方维护的。 validate 那个不是内置插件，所以没有写入文档。cnode 那个其实也不是官方重写的，是朴老师之前召集社区重构的，第一期只专注于迁移，并没有优化。

杨雪晋：多谢解释了，抱歉我的态度可能稍微激动了点，实在希望 Node 社区也能有相对完美的 web 框架和生态系统。

天猪：

没事的，我们每个人在社区都是有多重角色的。就像苏千他们也是 Koa 的核心开发者，而 Koa 本身也已经完成了自己的核心目标了。然后上一层的封装，他们是作为 Egg 的核心开发，输出到 Egg 里面的。同样，更上层的业务框架输出，我们是以另一个角色，在其他项目里面输出的，可以关注下蚂蚁最近开源的 sofa-node 。

也可以看看我们这篇专栏《InfoQ 专访死马：为什么说Egg.js是企业级Node框架》https://zhuanlan.zhihu.com/p/36240171

杨雪晋：请你们在公司项目中使用下 egg，碰到问题在 github 提交 issue。确实官方回复很快，基本上是天猪回复的多，而且是回复后即便没解决问题也立刻关闭 issue，即使如此 egg 项目的 issue 依旧存在很多问题为明显的不足之处，我感觉不到官方团队有对 egg 技术创新上做追求

天猪：

如果没有解决可以重新 open 的，这是社区，不要有负担。

老实说，egg 本身的职责基本上已经完成了，它就是一个加载规范，核心已经很稳定了。

剩下的，我们其实跟你们没啥区别，都是社区的一分子的身份，去完善生态。

而日常开发中我们没用到的模块和实践，我们真的没能力也没办法花时间去专门研究，毕竟我们只是一个虚拟团队，我们主要是为了支持各自部门的 Node 演进。

阿里的很多后端和运维基建和社区不一样，(当然我们在尽量拥抱)，故开源的插件都是我们在内部实践成熟后，才有可能作为社区的角色分享出来。

字字珠玑：请问下大佬们这么拥抱社区有基于KPI考核的部分在驱动吗?然后有新的项目直接上node的吗?还是就是用node替换原来成熟的体系?

天猪：

拥抱社区一直都是阿里的传统，我们有阿里开源小组。

我们自己本身就很受益于开源社区，回馈是理所当然的。甚至我们很多人都是从社区招募进来的。

开源其实有好处的，就好像我们现在招人，很多已经具备 egg，ant design 的能力，有效的降低了人员招聘筛选和培养成本。

开源从来都不可能是 KPI。我们的 KPI 之一是各自团队的工程基建，只是为了更好的完成这一目标，我们会考虑协作和建立生态，然后顺便分享出去。

Egg 也从来不是一个实体团队，我们都是分布在不同部门不同城市的，不可能有一样的 KPI。

『替换体系』这事情真的很难，不是说说就可以的，涉及到生态，运维基建，中间件 SDK ，监控，应用治理等等非常多的领域。Node 的目标从来就不是替代 Java，它们的定位是不一样的，是互补的。阿里的 Node.js 也是苏千朴灵等前辈们足足经历了 8 年的开荒，才冲出一条血路，有了今日的开花结果。

皮一下很开心的问题

请问你为什么叫天猪…？ ─ @诺墨

请问你为什么叫天猪……

大学时昵称是阿天，我们那个时代流行加个猪后缀作为昵称，因此。。。

天猪和飞猪有啥关系？ ─ @bearever

天猪和飞猪有啥关系?

他们给我发过一枚飞猪天使用户勋章。

本期 AMA 社区小伙伴提了许多实用问题，感谢天猪认真地为掘金小伙伴解答了不少疑问。浏览更多的问答，可以到天猪的 AMA 进行阅读和讨论。

本周 AMA：《开发者必备的 Docker实践指南》小册作者--有明

本周 AMA 正在进行 时间：2018.11.13 - 2018.11.15，活动传送：👉戳这里

本周 AMA 嘉宾为《没什么难的 Docker》书籍、《开发者必备的 Docker实践指南》小册作者--有明，大家有任何关于 Docker 、虚拟化、容器技术、个人成长、团队管理问题都可以找他交流技术~