我想用 nextjs 写后端给 app 提供接口，会有什么坑吗？

[luckykelan]

有一个业务比较杂，但普遍是增删改查的 app ，无网页端。 争取到了比较多的开发时间，实在写够 springboot 那一套了，想尝试一下新的。 请问各位可以用 nextjs 写接口给 app 提供服务吗，就是在 nextjs 连接数据库进行增删改查？会遇到什么坑吗

[jchnxu]

我觉得可以

好处：

- 没有页面需求，打开思路，可以放一个页面当 console 玩。没必要用 standalone 。

- 可以尝试用 vercel ，免费而且有 log ，很丝滑

- 生态比较好。什么东西都找得到。比如新东西如 gpt 相关的一大堆。更别提常见的 auth / logging 之类的需求了

- 不要从头写。找个脚手架开始就行。next 脚手架太多了。整体我自己感觉是搭起来比 springboot 要快的。springboot 那一套怎么着我也得半天。next 的大概 1 个小时就差不多了。用点 npx 什么的基本都是命令行一步一步跟着来。java 的脚本做的确实普遍不如 node 好。

- 关于数据库，脚手架里面如果带个 prisma ORM ，我感觉比 JPA 香。更别提 mybatis 了，装了插件我也写的太累了。或者干脆是一个 supabase ，都能图形化操作了。


要注意的，不好的：

- cjs & mjs ，type: module 这个是我自己最烦的。虽然升降一下包版本可以解决。但是就是很烦。

- 如果要跑 typescript 脚本，ts-node & tsx 也很烦。能解决但是很烦。

- 其他小坑。比如 vercel 上 ORM 要 import 一下要不然没法 init 之类的。问题不大都能搜到。

- node 不太好的地方在于，一个线程，逻辑复杂了不好 debug ，而且监控上我感觉还是没有 java 成熟，还是得依赖 PaaS 。node 理论上还是做转接层合适，但俺寻思咱们写的 CRUD 不都是转接吗？瓶颈大部分在持久层。

- 另外如果是 vercel 。要注意的是 vercel edge & serverless 会有时间限制。好像是 10s 来着。原因是 edge & serverless 不推荐做计算和存储逻辑。但看 OP 的需求刚好就是 CRUD ，我觉得还挺合适的。而且这个 edge 我个人感觉还挺有趣的。虽然我没有实际 bench 过，但按道理来说是比中心化的服务器更快的。

[jchnxu]

@lstz 不要用 app router ，明显复杂很多，社区的抱怨不是一天两天了

https://www.reddit.com/r/nextjs/comments/1c7oi1m/why_do_people_dislike_the_app_router/

[cp19890714]

nextjs 所谓的全栈, 是对于前端开发者来说的. 它的后端功能极其薄弱, 主要用来做 BFF.
用 nextjs 做后端,那是找罪受.

[xiaomingVTEX]

fastpai+1

[74123gzy]

express 吧

[FEDT]

你是不是发错了 nestjs

[foxhatleo]

没有什么大坑，可以用，我现在就这么写的，但是我的项目是一个前端+“中后端”，就是背后还有一个公司的主 API 连着服务器。
很复杂的正经大型 API 用 Next 写没什么必要，Next 就不是设计来作为后端用的。如果不想换语言，JS/TS 也有很多的后端 focus 的框架。如果是全栈稍微带点后端那 Next 还是可以胜任的。

[nodesolar]

nestjs 吧

[hugepizza]

supabase firebase 试试 直接在 app 里直连 db 查数据 配置好安全规则 crud 不需要要过后端

[luckykelan]

非常非常感谢各位，根据各位的回复越搜越迷糊，感觉前端的技术栈现在太强大了。如果移动端采用 react native ，后端有推荐吗？因为这个项目只是目前不考虑网页端，但是客户这里无法确定不会有网页端的想法

[zephyru]

@luckykelan
前端 RN 后端无所谓吧，但 next.js 是不太合适...想用 js 写就 express 或者 koa 吧，想写变种 java 就 nest.js 。
个人感觉 koa 写着更舒服，轻量，但 express 社区更活跃，插件/教程/问题好解决一些。

[mark2025]

可以考虑 nest 或者 midwayjs ( https://https://midwayjs.org/ ). 后者纯 TypeScript ，支持 AOP 、IoC ，写 api 接口挺方便的。

[mark2025]

@jchnxu
[quote]cjs & mjs ，type: module 这个是我自己最烦的。虽然升降一下包版本可以解决。但是就是很烦[/quote]
我现在的 npm 包都输出纯 ESM ，项目也是 ESM ，没发现有啥不方便的。配置好模板就行

[quote]如果要跑 typescript 脚本，ts-node & tsx 也很烦。能解决但是很烦。[/quote]
我现在的（运维）脚本全是用 TypeScript 编写，然后用 tsx 执行。配合 zx 执行系统命令。不但效率比 bash 高很多，也比 python 脚本多了类型保护，维护很方便。

[quote]node 不太好的地方在于，一个线程，逻辑复杂了不好 debug ，而且监控上我感觉还是没有 java 成熟[/quote]
单进程的 nodejs 不是比多线程的更好 debug 么。 之前用阿里的 eggjs ，多进程模式( 1 master + N worker)，本地调试很麻烦。后来转到蚂蚁的 midwayjs ，单进程模式，vscode 调试很方便。
至于监控，prometheus + OTEL , 能满足绝大部分需求了吧。

[jchnxu]

@mark2025 感谢老哥的回复

1. 主要是假设碰到有一些包没有 esm 或者没有 cjs ，一搭配起来就头疼了。确实如果都是最新的 esm 就还行

2. 哈哈挺好的。感觉 zx 是我能用上的。今天又学到了

3. 有点刻板印象了。就是比如稍微有点计算逻辑，或者写了 bug 让内存崩了之类的，你总是要去 trace 是哪个 callback 里面，感觉调试起来没有 blocking io 的手动管理线程自然。prometheus 的 node preset 感觉比 jvm preset 弱很多

4. 没想到还有这样细心的回复，很开心

[mark2025]

@jchnxu 不客气，交流经验方便大家

1. npm 库趋势是在向着 ESM （甚至纯 ESM ）方向发展。如果项目是 CJS ，那么遇到 纯 ESM 包是不能直接使用的，而如果项目是 ESM ，那么无论包是 纯 CJS 或者 纯 ESM 都可以兼容。 所以我现在的所有轮子/项目都是 ESM 格式。

2. google 开发的 zx 真是效率工具。之前写 bash 脚本遇到要处理字符串（替换、变化）或者数组的时候很头痛，现在全部用 js/nodejs 来处理，把变量数据处理完毕后一股脑丢给 zx 的 `$` 去执行，也不用考虑手动转义。真是非常方便。

3. 我现在基本不会使用回调，或者直接返回 Promise 对象，对于异步调用，全部 `await` ，这样配上 sourcemap 以及日志, 异常堆栈非常精确。
另外，我把异常日志也上报给 otel ，可以获得非常精确的异常信息， 包括（不限于）：pid ，时间戳，内存占用、堆栈占用，被调用的类名、方法名/函数名，调用参数，异常堆栈，以及整个请求追踪链。

4. 如果你在使用 eggjs ， 我建议转换到 Midway.js ，后者原生 TS 开发，支持 AOP, IoC 功能，并且有丰富的中间件沐足绝大部分项目基建需求。 并且官方开发很友好，需求/bug 相应也非常快。
我在 2017 年左右就给 eggjs 官方提建议升级到 TypeScript ，结果对方爱理不理，最后直到这团队解散也没完成…… 而 eggjs 的插件开发以及项目调试很麻烦，于是转到了 midwayjs ，一切都变好了。

[jchnxu]

@mark2025 很多新名词，我慢慢看:P

[mark2025]

@jchnxu
AOP ，IoC 这个不用研究名词，用就行了。
比如 IoC 涉及的是依赖注入： https://midwayjs.org/docs/service ，https://midwayjs.org/docs/container
AOP 涉及的是切面拦截： https://midwayjs.org/docs/aspect
AOP 另外一个功能是写自定义装饰器。