最近想用node.js重构公司后端。egg.js和nest.js改选择哪一个作为系统框架呢，大神们给点意见？
egg.js <br><br>来自<a href=“https://lzxb.github.io/react-cnode/” target="_blank">react-cnode手机版</a>
@zhhb
@zhhb
确实如此
来自✨[react-cnode](https://github.com/MMGong/react-cnode)✨
来自✨[react-cnode](https://github.com/MMGong/react-cnode)✨
@wxs77577 adonisjs 凉凉了～ 之前看这俩框架的时候 nest 3k star adonis 4k 现在 adonis 4k多 , nest 已经 8k 多了 而且对 ts 不支持
@entrehuihui 不是趋势，所有后端框架的最终之路都是像 spring ，请看： php 里的laravel ruby 的 rails 现在 node.js 的 nest.js 在走这条路。
@konglover 项目小的话无所谓，如果项目大而复杂的话，建议了解下这个： https://cnodejs.org/topic/5b9a0164f1e8bc7579c78581
之前回复过这类问题，这边复制粘贴回复一下~
技术选型这件事，可以说是 仁者见仁智者见智，但也有一些考量在里面。我一般会考虑下面几个点：
功能
功能是什么？简单说，就是能否满足业务需求，不论 Node 框架 Express / Koa, Python 框架 Django / Tornado / Flask，又或者是 Java 框架 JFinal，都是为了满足业务需求而生。
所以呢，谈选型是要考虑场景的：
- 静态服务器，
http-server一键启动就够了不是~ - 接口服务器，业务不复杂的，Flask 其实要比 Tornado / Django 更简单、方便？
- 运营后台类，主操作
CURD，如果尝试过，会发现 Django 也很方便，定义一下model基本就完事了~ - 再复杂一些，逻辑不定，关系不一，需要独立开发，且很可能后续调整频繁，这时候就需要自行实现了
说了这么多，总结起来还是我常说的那句话，脱离场景谈选型，都是耍流氓。
生态
周边生态这件事就很好理解了，就拿常用过的一些东东来说，
- aliyun oss
- wechat api
- elasticsearch
- socket.io
- redis / mysql / mongodb
- 模板渲染 / 认证 / 权限管理
业务相关的东西很多的，如果有已经完善的工具，开发可以做到事半功倍，越来越多的公司选择上云，对阿里云的依赖变多，有阿里系的产品支持，很多东西不用自己开发，又或者简单封装即可使用。
社区
fb 的项目和个人项目选择哪个？不用说，一定是倾向于知名团队的或者企业的，阿里在 Node 社区的贡献度，有目共睹（社区活跃的大佬也是成把抓，没事了私信一下说不定还能勾搭一下？）
阿里前端业务大多是基于 Egg.js 开发（可以去问 cnode / cnpmjs 的大佬），这方面，持续的投入是看得到的，至少不用担心改天不维护了~
issue 那边也经常看到 Egg 核心开发者大半夜还在讨论问题，帮忙查找问题的情况用到的同学应该比我更清楚~
Egg.js 为企业级框架和应用而生，我们希望由 Egg.js 孕育出更多上层框架，帮助开发团队和开发人员降低开发和维护成本。
综上，在需要自行开发的项目（我主导或者负责）里，从 1.x 开始，不论是个人还是公司项目，我 全部 使用了选择了 Egg。 目前来说依然觉得用的很开心，也很庆幸，并没有因为 KPI 问题而项目暂停？（笑），后续还是看场景，第一选择仍然是 Egg。
1.插件不更新问题，建议作者转移到这个社区维护的 ORG 里由大家一起维护吧~
2.小项目无所谓 这个说法很不认同，双十一中运行的 Egg 项目很小喽？拿一个出来对比一下生产中运行的复杂度和需要应对的流量吗？
答案是：无意义。
- 讨论项目大小，Office 那种才是真的大项目，然并卵，整个前端也没几个，如果有，欢迎拿出来大家膜拜一下~
- 讨论应对流量，不好意思，拿架构图出来吧，真正的瓶颈从来都是 Database / Proxy / Cache / SLB，需要在框架层面讨论这个的，怕是没法大了。
@atian25 BAT 真的用什么都成，node.js 原生也好，甚至直接C++ 开撸也罢。 腾讯互娱事业部，还有一堆 C++98 呢。 当然，社区也并不是非你即我，提个建议： egg 的 issues … 没 nest.js 回复及时。 另外 egg 第三方插件对 ts 支持确实不够友好。 大公司是可以不管不顾，说一句: 我们xx业务就在用 egg ，能吸引很多粉丝。但生态，对小公司来说，是命～ 能在这里问的肯定不是 BAT 等上百亿的互联网公司，那么——小公司，请给我一打 AOP ～
看你想要什么了：
- 要稳定选egg，底层的 connect、koa 由 egg 团队成员维护。几十个基于 egg 的稳定运行的上层框架，不管是几千 pv 或者 几十亿 pv 的流量都能支撑。
- 要生态选egg，几百个 egg 插件，基于覆盖所有的应用场景。不管是微服务方案、传统方案、同构方案、GraphQL 等等都覆盖了。
- 要维护选egg，由于是底层框架的缘故，一般业务上一些能力都会反哺回来，形成良性循环。有问题也会及时回复，每天都有大量更新可看。
- 要star选 egg，目前准备破万，对于国内的 node 开源项目来说非常不容易。
- 要运维选egg，完整的日志方案，完善的生命周期，完善监控方案，上 Alinode、Docker 等等都行
- 要折腾选egg， typescript - https://github.com/midwayjs/midway aop - https://github.com/eggjs/egg-aop swagger - https://github.com/okoala/egg-swagger-doc2 graphql - https://github.com/eggjs/egg-graphql 同构 - https://github.com/alibaba/beidou 移动端 - https://github.com/eggjs/examples/tree/master/assets-with-umi 中后台 - https://github.com/eggjs/egg-ant-design-pro 等等还有许多官方插件正在开放中
- 要聊天选egg，各大钉钉、微信群，有问题在里面提问基本都能及时回复，国外的库问题基本是异步，而且有时差。
当然上面都是建议~
@zlnvsheng 在我看来，node.js 下一个强有力的竞争对手应该是 golang 。 node.js 值得吐槽的地方： express koa 更像是前端框架，而不适合做大后端。 nest.js 改变了这种局面，只可惜没普及。 现在区块链和微服务带火了 golang ，nest.js 如果能趁此机会拿下 php/swoole 和部分java 的市场份额，还是有一定机会的。 当然，语言只是工具，我们喜欢的，是 js 通吃的能力。
@author-hao node.js 本来设计不烂， 一是 前端 js 的强势。（浏览器只认 js） 二是 node.js 的库 既有C++ 实现，又有 js 实现十分灵活。 三是 大企业强有力的支持。
推荐egg.js,
- egg奉行约定优于配置,功能强大，又十分优雅
- 有什么问题，在github issue或者官方钉钉群都可以很快得到回复
- 接入alinode性能平台也十分简单
- typescript的话，官方也提供了typescript支持，也可以用midwayjs（基于egg）
新手用egg，可以快速上手 高手用egg，可以深入把玩
团队用Typescript，可以规范代码，但代码没有原生Javascript优雅 egg+测试驱动，使用Javascript一样可以写出高质量的大型项目
用egg其实也是离不开ts，采用loader的机制如果直接使用js的话，对IDE就太不友好了，随着项目进展有些在插件或自定义的启动中加载的东西越来越多，没有类型声明的帮助写起来真的是顾前不顾后
@xpplee egg issues 问题回复不如 nest 。
nest 现在发布一年就把 egg 打脸了，start 和 下载量都超越。 不过也可以关注下 midway， 吸取了nest 的很多优点。
@wujohns egg 官方对于用 TS 重写的呼声是 没有计划。看来类型检查，IDE提示这些痛点对于阿里来说不敏感 。不过我在调试 egg 时比较头疼，不知道参数哪儿会被修改。 https://github.com/eggjs/egg-cluster/pull/75
去年对 TS 呼声还不屑一顾的尤雨溪也食言了：
@waitingsong 最近用eggjs做了下生产项目，同时也用nestjs做了下业余项目：
- 其实eggjs和nestjs都是为了解决同一个问题，就是依赖管理
- 但是eggjs其实更适合工程化，nestjs在路由管理（非集中式）和中间件管理（和controller以及path的书写位置分离）做的很糟糕（有点为了炫技而炫技的嫌疑，脱离了工程需求）。
- 如果是技术选型的话个人觉得还是eggjs比较合适
但是也有以下吐槽：
- nestjs的ioc模式用起来真的很舒服，少了很多需要自己补类型的情况
- eggjs的cluster管理很令人吐槽，长期强势不接受单进程模式，直到被近期运维生态倒逼才做了出来
- eggjs的插件需要自己单独对社区已有的做封装（基于koa插件），而用到eggjs的地方一般是公司内部场景，写完这些插件后也会较少开源，大概这也是eggjs插件生态的问题吧（nestjs倒是直接基于express/koa/fastify做了adapter有很多中间件可以直接复用）
另外是关于依赖管理的一些思考（私货，捂脸逃）： https://github.com/wujohns/ioc-note
@wujohns 单进程可以打开了吗? 调试的时候多进程真的是烦, 启动慢, 还会有两个core中不知道哪个文件断点会停两次, 本地应该是默认两个子进程. “直到被近期运维生态倒逼才做了出来”, 这个真的是, 以后不管是哪个语言, 安安静静单纯写业务就好.
最后, 感谢写egg的大佬们, 真香.
@zuohuadong 按照nestjs现在的特性下载量为egg的十倍之多我也不会在生产中去用，非集中的路由/中间件策略在稍微上一点规模的工程上维护起来只能用惨不忍睹来形容（明明是spring的糟粕的地方也沿用了下来），这块的💩我算是吃够了
@wujohns 各自想法有所不同，但有一点是 nest.js 出的比 egg 晚，现在已经超过egg了。midway 一些包还是 js 写的，并且在midway 上没看到这种增速。 现在框架主要区别在生态了~ nest 依赖注入这块确实不如angular ，但考虑用的人多，后续需要排坑少，就只能吃下去了~
@waitingsong Angular 确实不好招，得去群里找。 nest 你直接这样招 java 转 node 就行了，人太多了~ https://www.zhipin.com/job_detail/dbc69dc9fbf0b5581HNz3di5EVU~.html?ka=search_list_2
@zuohuadong 跟您交流过，我还是用旧一点点的技术、简单技术比较稳、成本面也比较便宜。
新技术对我来说，赚不到钱，简单技术、系统快速开发出来，赚到钱才是王道。
客户、主管根本也不管我用什麽技术，对我来说，只要简单的框架技术，能跟 「复杂或新框架技术」 做到一样的效果，就ok了！
我的心思比较放在business上面。
例如我接 一个 太阳能电站的发电监控 、 逆变器组态设定互动、感测器收值分散运算、自动清扫机器人active等等的综合型管理系统，
还有接一个酒店小姐上臺下臺管理系统，rfid或nfc或qr code，管理小姐上下臺，又要轻量、伺服器就是一支安卓手机，用了google drive，同一个帐，登入2部手机，资料面做到了HA，系统面做到了容错(当然不到A/A或A/S等级)active/active ，active/standby
我很满意耶！新技术 相对於 创造收益 的 c/p值，性价比，实在太低了。
上述讨论已经脱离技术层面了，sorry，进入到「技术变现」层面。确实不应被列入考量…sorry again
等这些技术已经成为 大宗使用 、或是王者、唯一首选的时候，我在来投入，应该还ok啦
我只想用javascript，typescript我一点都不想用。java我讨厌它、php “全世界最好的语言…笑”、.net我不玩…
@Solomonqoo 旧技术，简单，平稳和成本之间没必然关系。 成本需要同时考虑 开发成本、维护成本、硬件成本。
有些潮流不可逆，不如早点拥抱，省的后面重构。 比如 ts ，现在 vue3 要拿 ts 重写了，angular 本身 ts 不用说， facebook 的 yarn 也不用自家 flow 了，转用 ts 了 。 这种趋势下，还坚持js ，实在是不可理喻了。
程序员搞新技术对自身是有益的，免得被时代淘汰。，
@DuJiming 受益者吧，把我们之前laravel 的项目全部用 nest.js 重构了，我们自己又开发了很多新的工具。 nest.js 代码复用率很高，结构清晰，团队维护也简单。
新技术对我来说，赚不到钱，简单技术、系统快速开发出来，赚到钱才是王道。
我的看法，就TS来说，学习成本不高，曲线不陡峭，静态类型带来的好处是可以直接 降低成本 这也是钱。
另，好像你的业务挺广的嘛。。
@zuohuadong 不不不，学习技术对我来说，是帮助我赚钱，并不是 让我烦心、伤神。
“有些潮流不可逆，不如早点拥抱，省的后面重构”，潮流，是对是错，这还两说！
坚持js不会不可理喻，您言重了，js可进可退，真没啥不好。说不定用潮流技术，有更大的机率、风险面临重构。
ts 3~4年内不碰的，说不定是明智之举，之後应该会出xs、ys、zs，等所有浏览器原生支援TS，
确定它是取代js，而且是完全的霸主，在来学也不晚。
其实呀，有些东西就像蟑螂一样，永远都不会消威，压宝我也压蟑螂，生命力超强！它生命超强，
我的学羽力却是越来越不行，这两种配在一起才对！才是王道、正解！
或许年纪吧，我还是比你们务实的！你们可能都太年轻了，是热情的技术追求者。
觉得自已写的有点多了，还是删一些好了。 有朋友在这里说了，学了半天，不知道未来在哪？转眼就35了
潮流？主流？对我而言，哪个可以像是蟑螂一样，生命力超强？ 所投入的精力、金钱、时间在某项专业技术上，尽量的能最大化 、最长化的创造高薪资、好机会，意思是说，专精的学一整套， 能让我吃的长长久久，我比较爱挑这种的。
前面十年投入infra，2个字：专精！但是…总是要有接棒的专业 ，所以接著也投入ERP(tiptop)/PLM(windchill)解决方案… 但有点力不从心，因为还有管理工作要做，但也继续吃到现在 (windchill专精，其他的不熟；tiptop半熟，sap会一些，其他的 不熟)，这样一玩 ，又7年了。 (windchill算是PLM第一品牌；tiptop是erp的倒数品牌)
居安思危，3年前又转入纯web开发。在过去面临这麽多次的专业 技能选择难题，虽没有100%，但也有95%的胜率。
所以…有鑑於此，前端、後端都可以用一种语言完成 ，这一点更吸引我。
追求技术这个问题，相较之下我会更务实。如此这般，似乎显得 我放肆了，请海涵~
@Solomonqoo 你这些技能我都没听过说， 只会js和sql的说，告辞。。。。
ERP感觉过于复杂，并且在国内有点水土不服。在国内的成功案例不多（不是大企业也不会想着上这东西）。 讨生活，没一技傍身是不行的，知识面太窄也是不行的。功夫在诗外。
@Solomonqoo
ts 维护成本更低，更利于团队开发。 而且 我们搞一些大型项目非常适合。 烦心伤神，说句不好听的，太菜而已。
国外也有相关调查， ts 受欢迎程度仅次于 Rust 和 kotlin 。
潮流对错，这个你不是大佬，但你看大佬怎么做啊， 连 node.js 官方的库都开始用ts 了，三大框架也都支持ts ，并且还有两个是ts 写的。
将来再搞，重构成本不低。
跟年轻没关系，我觉得你们缺一个有能力的架构师。
我的新书 Dart 快速实践，3分钟前刚校审第一遍，Dart 其实也是啥都可以写，哈哈，这本书里面包含了前端，后端、移动端的内容。实现了一个 类似于React 的前端框架，实现了类似于 Koa 的后端框架，还有用 Dart 制作了一个手机App，使用Dart 写FFI ，使用 Dart 调用 C 语言，以及Dart 与 IOS，Android平台相互调用等等。诚意满满。
Dart 除了用的人不多，其他的啥都好。
关于 TS 的书，我还没开始写，这个写完我就回去完成 TS 那本。
@zuohuadong 生态不同。太钻"技术是否先行"的牛角了，追新、守旧都有考量， 我们还是回归到纯粹交流开发上遇到的问题即可。 现在专注js，这个过程ts也会更成熟了，届时再来看ts一点也不迟。 技术的改朝换代总是在上演，这个议题也就别占用版面了 电子消费产品市场有一句话：早买早享受、晚买享折扣！用在IT技术上颇有异曲同工之妙
@Solomonqoo
等到想换的时候就后悔没早点用了，我们当时也是这样。
IT 技术“晚买” 迁移成本更高，这个本质问题你都没理解清楚。
没啥好谈的，还是那句话：你们缺个有经验的架构师。
@zhangshichuan 当提供的接口较多时，你会发现 路径-中间件-controller 的信息时分散开来的，当前端给出一个bug需要排查时，你会较难的找到路径（别笑，这个真的可以把人逼疯，亲身经历），同时中间件也是apply到指定规则的controller上，为了找到这个contoller用到的中间件，我又得再找一遍。 这块怎么说呢，nestjs 在 contoller 层也用修饰器的方式进行处理的确比较cool，比较炫技，但是对于工程管理上来说负面作用作用居多。。。也就是拿着锤子不找个钉子锤锤就不痛快，但实际这个钉子根本就不是实际开发需要的东西
个人两个都比较过 曾经墙头草了很久 后来硬啃了 nestjs 学会了自己 ts 在 egg.js 中写装饰器
nestjs 太重太复杂，有这个心啃了用起来，直接上 SpringBoot 也差不多了
@wujohns 这个看个人喜好，我想表达的是在框架层面的体验是一致的，不管是 ts 还是 js 写 egg，剩下的是应用代码层看个人喜好。
至于 egg 本身是不是 TS 写的，只跟框架的维护者有关，只需要有 d.ts 即可，对于应用开发者是无感知的（除了心理优越性外）。即使是那些用 TS 写的框架，最终发布到 npm 还是会编译为 JS。
@zhangshichuan 不过在nestjs可以考虑使用专门维护一个常量文件存放路由表（然后path使用这里定义的常量），以及每条路由对应的中间件，这样可以解决上述的非集中问题
