2024 年了,写后端 API Node.js 生态用哪个框架?

发布于 1周前 作者 h691938207 来自 nodejs/Nestjs

前端 next.js ,但是写后端还是很不足了。


2024 年了,写后端 API Node.js 生态用哪个框架?
93 回复

看你用什么前端框架吧。React 一把梭就 next.js ,Vue 一把梭就 Nuxt.js


nextjs 可以直接写后端接口,也可以用 nestjs 。

我选择 nextjs ,写接口挺方便的。https://github.com/TobeBetterV/Moments

是要比较复杂的那种后端框架吗? nestjs 吧。

我宁愿 Koa 也不用 next ,Java 味太浓,不是 js 的最佳实践

  • Express.js
    - Koa.js
    - Nest.js
    - Next.js (React)
    - Nuxt (Vue)

显然你看岔了 next 和 nest

Hono 或者 Fastify 。Hono 挺时髦的,但是第一支持对象是 Deno ,放在 Node 上运行性能肯定比不上 Fastify

其次还有 hapi ,nitro 可供选择

首先排除这两个, 什么玩意。SSR 绝大部分是伪需求
Next (React)
Nuxt (Vue)

使用基础级框架就选
Express
Koa

使用企业级框架就选
Nest
Egg
Midway (阿里开源的没有 Egg 那么重,和 nest 类似)

那个明明是 PHP 味…

简单才是硬道理。直接从 express/koa 入手,各种业务逻辑和中间件设计得优雅一点,以后迭代得更复杂了随时可以切到 nest/midway

谢谢,确实看错了,23333

tRPC 简单但严谨
https://trpc.io/

写后端咋不足了

nestjs 还可以 用过

喜欢 Java Spring 的可以用 nestjs ,喜欢 PHP Laravel 的可以选择 AdonisJS

喜欢 thinkphp 的,可以试试我的 jj.js

投 Fastify 一票,玩熟了特别爽

2024 ? hono.js

fastify 和 hono.js 写简单的不错
复杂的 NestJS 。

愿意上更可靠的类型安全,推荐捆上 trpc 。

Express / routing-controllers

请教一下,怎么让 nodejs api 里用 swagger 的时候增加一个接口自动出现在 swagger 上,而不是要自己写一个注释文件

2024 我更推荐 astro+你喜欢的( nest+express+koa )

试下 strapi 代码都不用写了

哈哈,我就在用,挺省心的,适合工作前端方面比较重的。后来又看很多人说 Supabase 也不错,后面有机会了打算也试试,看看哪个更好。

#22 搜了一下 https://github.com/fastify/fastify-swagger

python 的 fastapi 已经自带了

fastify 够用了 性能也够

肯定是 Midwayjs 啊,用 TypeScript 写的,入门简单,功能丰富。
Express, Koa 太简单了,功能少。Eggjs 功能多些,但是是用 Javascript 写的。

看着不错,文章|闲聊|关于我还能歪来歪曲跟着鼠标焦点

我用 express+express-graphql 写了个 graphql 的 api ,有个接口 3 秒才返回,而且我还不知道怎么查。无语了(能打印时间戳的地方都打了,都是毫秒级别的)

如果简单的要性能,看看 bun+hono

trpc 不推荐

koa 或者 express , 另外个人建议, 远离阿里 kpi 产物

原生保守点还是 express 和 koa ,ts 就是行 nest.js 好啦

React 一把梭就 next.js ,Vue 一把梭就 Nuxt.js
我就在用 nuxt 写后端.不要 ssr 关闭就行了,能增删改查就行呗

能否说说推荐与不推荐的理由?

一定要 node 吗?用下来感觉 node 写后端就是个笑话。

排除 egg ,不怎么维护了已经

headless 可以试试 directus ,另外 hasura 也很赞,个人使用 midwayjs 多一点

nestjs 复杂 但 强大。
strapi 简单 headless CMS 应用场景窄了点

#38 怎么说?

一两个 API 的话直接用 Node 的原生 API 手写也可以。

API 多了看项目适合哪种架构。

我一般习惯 koa ,比较灵活。

我自己会首先排除 nest.js…😗

koa 或 express + tsoa ,自动生成 OpenAPI 规范的配置和前端请求客户端,前后端都用 TS 的话会很舒服

我前些天也在纠结这个,看了一圈之后决定还是用 egg 了。。。
这楼里居然没有一个提到 egg 的,已经凉了吗

哦看到了,还是有人提的

用的自己基于 koa 封装的。

#41
#44

umm… 就是对比下来感觉 node 框架的提供的特性不够丰富,跟玩具一样。比如 Koa vs Ruby on Rails 。TJ 和 DHH 还在 twitter 上就 orm 的设计 battle 过,也许设计哲学不一样,不过我是站 DHH 的,因为不想自己瞎 jb 折腾拼包,累。

nestjs 很舒服😁

egg 团队都已经解散没人维护了,不推荐。 推荐 midway ,TS 写得很顺滑,各种组件也很丰富,并且也不是 kpi 项目。

egg 团队早已解释,项目已经凉了。并且 egg 一直对 TS 支持很差, 尤其是写插件的时候(多 worker 也导致很不好调试)

没写过的人评价笑话才是笑话

我的个人项目用的 eggjs ,几年下来已经屎山了,不过无所谓,随便写

有 nextjs 不用的话 正儿八经的后端 nestjs 脚本级的接口 koa

#51
midway 类似 java 的写法让我很难受

#59 啥叫类似 java 的写法? 认识这么局限吗,局限的都不能描述出来?

#59
「 Midway (阿里开源的没有 Egg 那么重,和 nest 类似)」

#53 很久没有用 egg 了,没太关注。我看了下今年也有在发小版本,应该还是有人在维护,只是不加新功能了。

#62 这两框架很像啊,midway 作者都说借鉴了 nest ,说类似没什么问题。
"类似 java 的写法"确实不知道指啥。

Nestjs 嵌入 Fastify 挺好用的

nestjs 撸过一个项目(边缘产品,核心的还是不敢用它),虽然没出过问题,但是用起来还是心慌慌

经常写 crud 的管理面板,目前习惯是 nestjs 写接口,然后 ant design pro 做面板,搭楼问一下,nestjs 使用 mikro-orm 定义的实体,生成的类型文件,怎么能方便的导入到 ant design pro 里,这样就不用两边都写类型文件了。

看具体业务场景

如果是相对重的后端,首选 nestjs ,在复杂业务中使用过,没有出过问题

全栈直接 Next.js 一把梭,server actions 很好用,入参出参直接按普通函数写 TypeScript 定义就行了,完爆 TRPC 。
其次 Nest.js 大而全,Koa 小而美

Hono 和 koa 一样简单明了 开箱即用的 middleware 比 koa 多 也有很多类型相关的支持 甚至直接 rpc
没必要搭 bun 用 node 完全没问题
如果只是很轻量的后端 可以直接上 cf worker 部署也很简单不过 node 的一些 api 用不了







看各位都推荐用 Koa ,我只简单写过一点点,想请教一下在实际工程中 Koa 对比 Express 的优势在哪里?特别是 Express 5 也支持异步中间件了。

除了 trpc 还有 tsrpc😆
https://tsrpc.cn/

2024 年 Hono 就够用了,虽然 Nest 好,但是每次感觉都是捏着鼻子写。

#22 nest 有 swagger 的插件,在每个接口上写注解就好了

#72 其实差别很小,因为作者都是同一个人,只是 koa 在早期设计实现了一个思维试验,即把原有 Express 的中间件顺序执行模式改为了“洋葱模型”,发展至今应该是两者的主要区别,看你的业务特点是使用顺序执行模型还是使用洋葱模型比较合适。

另一方面就是 Express 自带了一些基本的中间件;而 koa 仅提供最基础的框架,需要自己选择各个中间件来组合使用。我做的项目一开始是用 Express ,后来发现随着需求越来越具体,Express 自带的中间件无法很好的满足需求,于是就自己写中间件,以至于后来几乎大部分自带中间件都没有在用了,所以后来换了 Koa 。

其实各种框架都学一学也花不了多少时间,后端更多的是研究系统架构、数据库、中间件(消息队列、KV 、搜索引擎等)、服务治理、分布式事务等等,语言和框架就是冰山一角。

哈?不知道 nextjs 可以自定义后端框架么, 我一般是 nextjs + koa

#73 我写的也不多,可能过时了,做个参考:koa 给我的感觉是非常简洁,只需要记住洋葱模型,绝大多数时间都不需要查 API 。express 则没有这种舒适感

别 koa express 了, 只写 API 没有前端页面就 hono 和 fastify

我刚好也有这方面需求,前阵子技术选型我最后选了 nestjs

nestjs 吧,用起来比较规范

hono 都 1.0 了还内存泄漏着呢,怎么上生产

哦?我写没写过有必要告诉你?你最好抱着 node 写到死

赞同,我觉得用起来太难受了,尤其是那个 next 的中间件。

nodejs 代码写的不多,最近写了个小项目(已上线有几千用户那种),选了最经典的 express ,感觉生态比较完善

我自己个人接的一些小活用的是 express ,前端纯 html/js/less 。感觉这样可能开始开发效率低点,有足够的积累后,开发效率也不差。但都是个人能完成的小玩意,没搞过大的。

好像 api level 一些东西难复用,比如你的 rate limit 我看到复制了好几遍, 也需要每个 api try catch ,简单是简单,但是感觉缺失很多正常的支持

在2024年,Node.js生态中用于写后端API的框架有多个优秀选择,以下推荐几个主流框架:

Express

Express是一个快速、简约、灵活的Node.js web应用程序框架,适用于创建API和web应用程序。它以其速度和效率而闻名,是高性能API的绝佳选择。以下是一个简单的Express示例:

const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Welcome to the homepage!');
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

NestJS

NestJS是Node.js生态中最成熟、功能最丰富的Web框架之一,它使用TypeScript开发,底层基于Express。NestJS适合用于构建大型项目,并支持微服务、WebSocket等服务。其模块化设计使得代码易于维护。

Koa

Koa是一个轻量级且富有表现力的Node.js web应用程序框架,由Express背后的团队开发。它允许开发人员用最少的样板代码创建API和web应用程序,并支持async/await。

Fastify

Fastify是一个专注于性能的Node.js框架,以其速度和低开销著称。它可以通过插件架构来扩展框架的能力,并支持现代web标准如HTTP/2和WebSockets。

总之,选择哪个框架取决于项目的具体需求、团队的技术栈以及个人偏好。每个框架都有其独特的优点和适用场景。

回到顶部