破20k! node.js 值得关注的后端第三大框架 nest.js (附交流群)
发布于 8 个月前 作者 zuohuadong 9205 次浏览 最后一次编辑是 7 个月前 来自 分享

这是今年增长最快的 node.js 后端框架了。

截止目前 已经21k star 了,已经超过 sails 成为第三大框架,直逼 koa 的 27k 。 按目前增长趋势,2020年 可超过 koa 的star 数。

当然也有人说,这么像 spring ,不如直接用 spring ,可是如果考虑开发效率、异步非阻塞的性能、SSR渲染、graphql 生态以及和 angular 搭配…

npm 下载量:

nest.js 每周下载量超过 10w ,是目前egg 50倍, 达到 koa 的 1/3。

image.png

https://www.npmtrends.com/@nestjs/core-vs-egg

star 趋势

image.png 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 微信图片_20190815092450.jpg

微信群: (微信限制,超过100人,需要邀请进群) image.png

22 回复

。。。你这样egg玩家会难过的😂😂😂

@zy445566 egg 也推出类似的框架了—— midwayjs

@zy445566 各有所需,各有所长。

总感觉你老是拿egg来做对比

@shenjianzch 增加了其他框架来对比

不想说话,你要知道cnpm和淘宝源,有多少下载量就不说话了。这样比较意义何在

@i5ting 国内确实用cnpm 和 淘宝源的多,但 egg 在国外呢,还是不增长。

而且 就算用 koa express nest.js 这些 同样也有用淘宝源的。

如果可以的话,也希望 cnpm 和 淘宝源公开这几个框架的数据。 数据累加起来对比,更具有意义。

https://docs.nestjs.cn/ 6.x 二次校对已经全部更新完毕,如有问题,欢迎提交 PR ~

用egg最蛋疼的地方在于其自带的多进程管理,感觉这个特性应该单独抽取出来而不是作为框架本身。 其他地方的话则是各有千秋: egg

  1. egg更容易上手
  2. 集中式路由方便管理
  3. 结构上天然解决循环依赖 …

nestjs:

  1. 不依赖单独的helper,直接对ide友好
  2. 对已有的koa或express基建复用更友好
  3. 按照module的方式做工程规范便于多人的工程协作 …

不过就 starter up 来说 egg 给人的挫折感比较强(多进程引起的繁琐的断点调试,没有helper对于ide来说如同回到了sublime时代) 现在唯一觉得nestjs不爽的地方就是非集中式路由和中间件管理(spring的糟粕处)

现在工作用egg,业余开坑用nestjs

新出的玩意坑多 要稳定还是要 express Loopback,MEAN 、Keystone、 Sails 都是用express做基础搭建

@yakczh egg和nest的话现在都很稳定,写小工程用express还行,但是稍微大点的工程用express就会很痛苦

@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行以下的工程,工程再大一些很多地方就很难受了,具体有:

  1. 依赖关系管理
  2. 工程代码结构治理
  3. 启动时的预加载管理(在egg中有生命周期规范,在nestjs中可以采用ioc配合global module处理,自己写也行但属于重复造不怎么可靠的轮子)
  4. 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了

回到顶部