这是今年增长最快的 node.js 后端框架了。
截止目前 已经21k star 了，已经超过 sails 成为第三大框架，直逼 koa 的 27k 。 按目前增长趋势，2020年 可超过 koa 的star 数。
当然也有人说，这么像 spring ，不如直接用 spring ，可是如果考虑开发效率、异步非阻塞的性能、SSR渲染、graphql 生态以及和 angular 搭配…
npm 下载量：
nest.js 每周下载量超过 10w ，是目前egg 50倍， 达到 koa 的 1/3。
https://www.npmtrends.com/@nestjs/core-vs-egg
star 趋势
https://star-history.t9t.io/#nestjs/nest&eggjs/egg&koajs/koa&balderdashy/sails
js 一时爽，重构火葬场，后端应用，可以说 typescript 是必备的，而一些纯 ts 框架对 typescript 的支持更好，并且，nest.js 和 midwayjs 这些都沿用了后端的 AOP 思想，更好地降低了耦合。 我们目前也使用 k8s+istio 做微服务，nest.js 作为主体框架，使用 typeorm、graphql、grpc 等技术。
中文文档： https://docs.nestjs.cn/ 相关技术资料：https://docs.nestjs.cn/6/awesome/ github: https://github.com/nestjs/nest/
(相关资料更新中)
也欢迎一起交流，包括node.js 其他框架：
QQ群： 277386223
微信群：
（微信限制，超过100人，需要邀请进群）
@i5ting 国内确实用cnpm 和 淘宝源的多，但 egg 在国外呢，还是不增长。
而且 就算用 koa express nest.js 这些 同样也有用淘宝源的。
如果可以的话，也希望 cnpm 和 淘宝源公开这几个框架的数据。 数据累加起来对比，更具有意义。
用egg最蛋疼的地方在于其自带的多进程管理，感觉这个特性应该单独抽取出来而不是作为框架本身。 其他地方的话则是各有千秋： egg
- egg更容易上手
- 集中式路由方便管理
- 结构上天然解决循环依赖 …
nestjs：
- 不依赖单独的helper，直接对ide友好
- 对已有的koa或express基建复用更友好
- 按照module的方式做工程规范便于多人的工程协作 …
不过就 starter up 来说 egg 给人的挫折感比较强（多进程引起的繁琐的断点调试，没有helper对于ide来说如同回到了sublime时代） 现在唯一觉得nestjs不爽的地方就是非集中式路由和中间件管理（spring的糟粕处）
@wujohns 大部分公司的nodejs项目都是小工程 ，12306的项目不会用nodejs 搞不定大工程的公司已经开始用微服务，在docker里弄一堆express 互相调用 微服务 pk 大而全 明显微服务更灵活，维护性更好
@yakczh 微服务跟框架的大小并不冲突。 我们就是 k8s + istio + nest.js (grpc/graphql) 框架其实决定了可维护性和生态。
微服务的拆分并不是把一个人 拆成 左胳膊，右胳膊，头… 这样的。 而是拆分成，防御层，消化层，能量层，中枢层… 要求的是低耦合，可拓展，好维护，比如 在java 里是 springboot 这样的，而不是 其他更轻量级框架。
node.js 在2015年左右，很多人在说统一大后端，却看到 express koa 这样的框架不可置否，压根做不了后端，热潮褪去。
如果当时是 nest.js 呢？ 可能 node.js 份额趁着这股热劲拿到更多市场。
@yakczh 这里的小工程是指单人维护，代码量在10k行以下的工程，工程再大一些很多地方就很难受了，具体有：
- 依赖关系管理
- 工程代码结构治理
- 启动时的预加载管理（在egg中有生命周期规范，在nestjs中可以采用ioc配合global module处理，自己写也行但属于重复造不怎么可靠的轮子）
- web中常用的安全策略 等等…
(话说微服务也不是你说的那种用法啊。。。
@wujohns 微服务怎么用法，你可以开个培训班，趁着现在微服务火的热劲肯定拿更多市场，就看多少人能报名，说不定就象马云说的万一梦想实现了就发了，从此不用996收福报了
@zuohuadong 1用你的原话 “ 微服务跟框架的大小并不冲突。 “ 所以微服务器跟框架可大可小，并没有钦定用什么框架 微服务的定义中并不绑定nest.js 2 微服务的拆分并没有规定必须垂直拆分,怎么拆分依赖于需求场景，其实垂直的拆分已经在web容器的时代就已经拆成N层了很普遍了，只是原来在web容器的结构下不能独自布署，是栈式调用的 随着虚拟机和docker的兴起只是把原来已经拆分的N层用容器包装起来了，更加独立了，从栈式变成组合式，从一条线串起来的单一结构变成网状结构 另外springboot只是微服务的一种实现，你用netty做个容器，只要能接入springclound统一管理 一样是微服务 一种方案有N多实现工具 方案和工具并没有绑定 3 nodejs的本质决定了nodejs只是事件流程处理中的一个补充方案，而且是边缘化的方案，比如象现在前端build工具链的位置，所有想统一大后端，趁着什么热劲拿更多市场的，终将会收到市场的教育
@yakczh 先说一下立场吧： nestjs/egg/koa/express/spring 无论在工作中还是业余挖坑中我都在用，这里我这边只是指出相比于express选用nest或者egg的优势与原因（即使在微服务这种单个工程的工程大小可控的情况下） 另外就是 @zuohuadong 在宣传 nest 上的确比较激进，其实有一说一，没有必要通过贬低其他框架的方式抬高nest，这个很容易让人反感
“在docker里弄一堆express 互相调用 微服务” 这个说法很容让人误解（就像我这边没有在一开始明确小工程具体是有多小），比如多个微服务在公用同样的数据源时，该怎么保证这里的使用不会混乱，一般的做法是不会让每个微服务直接调用数据源，而是会通过统一的一个微服务调用，诸如此类的在整个微服务集群的治理上，实际是会有垂直拆分的需要的。
我在一开始入坑 egg/nest/spring 的时候也是感觉很不舒服，因为如果能用express/koa简单完成工程何必还会需要那么繁琐的用法呢，但后来的工程推进中，发现对基于express/koa的工程治理中实际添加了很多在 egg/nest 中很多公用的特性，也就是再造轮子。这些也都是实际做过对应的工程才会有的感触。
另外就是对于完全的新人不建议从 egg/nest 入坑，推荐从 express/koa 开始，先了解基础并有一定的工程经验，这个时候再入坑 egg/nest/spring 的时候就会有恍然大悟的感觉（如果时间较多的话可以了解下其他的各个框架，扩宽下视野，毕竟每个框架都有不同的核心目标，相关的设计都可以作为学习）
最后就是讨论这个，就事论事，没必要这么阴阳怪气。
@yakczh 这个问题上并没有什么本质不本质的事情，C++或者汇编 的本质就什么都能干… 说白了，只要生态好，其他的问题都是小事。 案例一： java vs .net core 案例二： node.js vs PHP 案例三： quickjs vs lua 生态好，就有人不断填坑，如果没生态，就没案例2和3。
如果 2015年， node.js 有类似 spring 这样的框架，进而出现一系列大型项目的解决方案，生态如 java ，然后又反向推动 node.js 的更新迭代，那结果未可知。 语言就是不断吸收其他语言的特性，没有什么一成不变的。
js 的 callback 现在也演变成 async/await了