吐槽一下 Nest.js 太复杂了

我是前端出身，最近的两个大型项目后端都是用 NestJS 写了，符合工程化的选型，基础业务框架写好了，后面再写各种模块方便。就是互相依赖这个处理起来有点不爽。

我看成了 next.js

@easychen 这个框架真的不错，我试了 egg,express,koa 等等，最终选择了这个

为什么不用 express ？
https://github.com/alchem-x/chives-watch/blob/main/server/routers/sql.js#L26

Nestjs 封装是有点过度了，既然是 TypeScript 这种语言加上 Node 的 runtime ，很多东西是可以做减法的。
我用的时候就做了很多减法，比如：
service 全部用 static 函数，就不需要注入了，要 mock 直接 class.method = function(){}，要是非 static 的就 class.prototype.method 重新赋值来覆盖；
Providers 直接不用，官方案例简直是神经病连 HttpClient 都封装一层，它以为自己在用.NET 上吗，还不如开个文件在里面定义个常量然后导出，不也是全局唯一的吗；
Guards 也放弃，哪来那么多策略，直接在 Middleware 里简单鉴权就行了，复杂的我宁愿单独写一个 api 网关；
Modules 只拿来做业务模块区分，里面只引入控制器；

现在，我直接换 hono 了，搞个 module 文件夹自己分层就好了

nest 确实有点过度封装

但是按照 IoC 思想的，似乎也只有它？

不喜欢 spring boot 的人同样不会喜欢 nest.
我自己 node.js 项目不会太复杂, 复杂项目会直接用 rust 来写, 为啥要用 node.js 写复杂后端项目啊.
逻辑是一样的, 我从来没用过 DI 这种东西. 现在的趋势(以及我个人一直的偏好)是简单化, 就像做 agent 开发, 不用 langchain, 直接用最简单的抽象, 基于 api 进行调用.
另外, 后端新手上来就用 nest 绝对不好, 绝对会让他觉得后端很难的印象. 其实很多抽象, 概念都没必要. 直接根据业务写代码即可. 我之前用 hono + bun 写了一个服务, 可以参考 https://github.com/Akagi201/hono-template

你就说新不新吧

next nest 之后，下一个 hono?

试试 midway 吧，和 Nest.js 定位一样，国产的，还是喜欢国人的审美，简单优雅，就像 vue 之与 react 一样。

Bun + Elysia ，写着挺爽的

bun+hono+zod+drizzle,一套从 model 定义到前端 api 调用都能完全类型提示。活的太累了，就需要 hono 这类工具来解放自己。

写小项目就用 epxress.js 或者新的 hono.js 一把梭。

写大项目后端别用 js 了

这么写为啥用 js 呢…回去 java 不好吗

我有幸参加过三个月左右的 nestjs+angular 的项目，然后润了

评价为若至技术栈，又臭又长，纯骗经费用的

我也用不习惯 nestjs ，最后选了小巧的 fastify

所以我用了轻量版的 routing-controllers ，一样的 declarator-based 语法，但没有了那些用不上的概念。

之前就听说 nestjs 的大名,折腾了下想丢到生产环境用用,配 docker,配数据库,配日志等等,用空余时间花了一个多星期,
对于前端来讲真的学习成本太高了,还有一堆规则,有这时间多摸下鱼不香吗😏
后面自己的项目果断 express,配合 serverless,直接写业务逻辑

后端入门时第一个接触的就是 nestjs ，以至于日后用 Asp.net core 都觉得框架太简陋，没 nestjs 做得那么细

@kenberkeley declarator-based ？ decorator-based ？

讨厌 Java ，理解 Java ，成为 Spring