V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
luckykelan
V2EX  ›  程序员

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

  •  
  •   luckykelan · 2024-04-19 15:00:51 +08:00 · 5925 次点击
    这是一个创建于 371 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    37 条回复    2024-04-24 21:37:56 +08:00
    lstz
        1
    lstz  
       2024-04-19 15:09:43 +08:00 via Android
    nextjs 最大特色是 ssr ,既然你不打算提供网页内容,为什么一定要用 next.js ?

    一定想上的话,可以是可以,但我想 nextjs 对你要实现的功能来说,那样会有些重

    我目前的开源项目 https://github.com/work7z/LafTools ,有一些后悔上了 Next.js ,主要原因如下:
    - 要自行部署,得配 standalone 那套,感觉这 standalone 不是官方最倾向的,人家想你直接上 vercel
    - 时不时会遇到 abortInComing 错误,从 12.x 到 14.x 都看到有这个错误抛出(官方为此 release 了几次但还是有),这对于稳定性来说实在不太能接受(再怎么样也不能整个应用都 crash 了吧)
    - 想给你的 header 或者所有 http 请求加点逻辑?拦截器或者中间件啥的?可以,写 middleware ,但那玩意是 experienmental feature ,每次用都心惊胆战的

    我再来一次的话,会考虑别的 ssr 框架了。对于你的需求,我建议 express 加 typescript 就 OK 了,可以参考我这个项目的 modules/server2 ,开箱即用
    lstz
        2
    lstz  
       2024-04-19 15:11:39 +08:00 via Android
    关于第二点 abortIncoming ,看了下 issue ,应该也是由 middleware 导致的
    iOCZS
        3
    iOCZS  
       2024-04-19 15:21:05 +08:00   ❤️ 1
    直接 koa 或 express 不就好了
    Ayanokouji
        4
    Ayanokouji  
       2024-04-19 15:21:29 +08:00
    没页面需求,还是用 springboot 吧,找个代码生成器。或者使用 go ,优势内存小,部署简单。
    sjhhjx0122
        5
    sjhhjx0122  
       2024-04-19 15:39:36 +08:00
    纯写接口为什么不试试 nestjs
    tianzx
        6
    tianzx  
       2024-04-19 15:50:51 +08:00
    @lstz #1 你这个用 Next.js 真的是高射炮打蚊子了。好处没用上,复杂度还上去了
    SayHelloHi
        7
    SayHelloHi  
       2024-04-19 15:52:40 +08:00
    可以看看 Elysia.js 或者 Nest.js 😄
    lstz
        8
    lstz  
       2024-04-19 15:52:52 +08:00 via Android
    @tianzx 对我来说好处就是 ssr+server action ,这些还是 OK 的,坏处就是定制型差,而且场景不太匹配就是说...
    tianzx
        9
    tianzx  
       2024-04-19 15:53:11 +08:00
    Node : hono or elysia
    Python : fastpai
    Java: quarkus
    tianzx
        10
    tianzx  
       2024-04-19 15:55:44 +08:00   ❤️ 1
    @lstz #8 他主要是解决 C 端 SEO 、服务端渲染的问题。你这个工具感觉大部分都得 use client 。个人觉得用 svelte kit 那一套可能更合适 。不一定对啊哈哈哈哈
    lstz
        11
    lstz  
       2024-04-19 16:07:39 +08:00 via Android   ❤️ 1
    @tianzx 可以的老哥,感谢建议哈哈哈

    我是为了 seo 考虑和页面直出,所以用了 Next.js ,不过也确实到处都是 use client ,我到时候看看架构要不要调整下
    xmumiffy
        12
    xmumiffy  
       2024-04-19 16:08:56 +08:00 via Android
    hono 或者 koa 就行了
    helloet
        13
    helloet  
       2024-04-19 18:35:37 +08:00
    推荐用 hono
    ebushicao
        14
    ebushicao  
       2024-04-19 18:59:24 +08:00
    nextjs 是个全栈框架,而且时偏前端的,你的需求完全没有网页端,那就根本不合适。
    renkunn
        15
    renkunn  
       2024-04-19 19:02:57 +08:00   ❤️ 1
    Nitro 了解一下
    ColdBird
        16
    ColdBird  
       2024-04-19 19:06:22 +08:00
    nest/koa
    jixiaopeng
        17
    jixiaopeng  
       2024-04-19 19:46:50 +08:00 via iPhone
    我用它做 web 全栈,app ,小程序用的就是 next 接口 api ,对我来说非常好用。
    Amose2024
        18
    Amose2024  
       2024-04-19 20:00:12 +08:00
    @lstz 你没有弄懂 Nextjs ,完全可以做到一键部署的。另外 middleware 也并不是试用特性。
    lstz
        19
    lstz  
       2024-04-19 20:04:44 +08:00 via Android
    @Amose2024 一键部署指的是 vercel 那一套吗?确实是有,但我需要更高层次的定制,nextjs 满足不了(或者说场景不合适)

    middleware 的 edge engine 确实是实验性质
    lstz
        20
    lstz  
       2024-04-19 20:23:38 +08:00
    @Amose2024

    我用 Next.js 有一段时间,不算是大师哈,但踩的坑也不少,相对也懂一些,我在本贴提到的都是 [standalone] 模式的,关于其他默认模式的不在我探讨范围内。

    之前写 middleware 的时候,引入了一些 npm 的库,按理来说是在 Node.js 上跑的应该都能编译,但 Next.js 就是不允许 middleware 上引用一些第三方的库,要不然就报错给你看。经过一些 issues 和官方人员的探讨和相关 workaround ,我才知道如果是 standalone 模式下要用 middleware ,你得配置如:

    export const config = {
    matcher: "/((?!api|static|.*\\..*|_next).*)",
    runtime: "experimental-edge", // for Edge API Routes only
    unstable_allowDynamic: [
    "/node_modules/lodash/**",
    "./node_modules/.pnpm/[email protected]/node_modules/lodash/lodash.js",
    ],
    };


    而这个又正好是实验性特性(正如你每次跑 dev 都会提示你的一样: ⚠ You are using an experimental edge runtime, the API might change.)

    反正我就一个写代码的,懒得翻源码看,就这么先写着先,对于楼主和我的场景来说,Next.js 都不合适 :P
    jchnxu
        21
    jchnxu  
       2024-04-19 21:25:54 +08:00   ❤️ 1
    我觉得可以

    好处:

    - 没有页面需求,打开思路,可以放一个页面当 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
        22
    jchnxu  
       2024-04-19 21:29:44 +08:00   ❤️ 1
    @lstz 不要用 app router ,明显复杂很多,社区的抱怨不是一天两天了

    https://www.reddit.com/r/nextjs/comments/1c7oi1m/why_do_people_dislike_the_app_router/
    cp19890714
        23
    cp19890714  
       2024-04-19 21:32:19 +08:00
    nextjs 所谓的全栈, 是对于前端开发者来说的. 它的后端功能极其薄弱, 主要用来做 BFF.
    用 nextjs 做后端,那是找罪受.
    xiaomingVTEX
        24
    xiaomingVTEX  
       2024-04-19 23:08:33 +08:00
    fastpai+1
    74123gzy
        25
    74123gzy  
       2024-04-19 23:30:39 +08:00
    express 吧
    FEDT
        26
    FEDT  
       2024-04-20 00:21:20 +08:00 via iPhone
    你是不是发错了 nestjs
    foxhatleo
        27
    foxhatleo  
       2024-04-20 04:04:39 +08:00
    没有什么大坑,可以用,我现在就这么写的,但是我的项目是一个前端+“中后端”,就是背后还有一个公司的主 API 连着服务器。
    很复杂的正经大型 API 用 Next 写没什么必要,Next 就不是设计来作为后端用的。如果不想换语言,JS/TS 也有很多的后端 focus 的框架。如果是全栈稍微带点后端那 Next 还是可以胜任的。
    nodesolar
        28
    nodesolar  
       2024-04-20 10:00:43 +08:00
    nestjs 吧
    hugepizza
        29
    hugepizza  
       2024-04-20 10:04:41 +08:00 via iPhone
    supabase firebase 试试 直接在 app 里直连 db 查数据 配置好安全规则 crud 不需要要过后端
    luckykelan
        30
    luckykelan  
    OP
       2024-04-20 14:55:51 +08:00
    非常非常感谢各位,根据各位的回复越搜越迷糊,感觉前端的技术栈现在太强大了。如果移动端采用 react native ,后端有推荐吗?因为这个项目只是目前不考虑网页端,但是客户这里无法确定不会有网页端的想法
    zephyru
        31
    zephyru  
       2024-04-20 17:58:52 +08:00
    @luckykelan
    前端 RN 后端无所谓吧,但 next.js 是不太合适...想用 js 写就 express 或者 koa 吧,想写变种 java 就 nest.js 。
    个人感觉 koa 写着更舒服,轻量,但 express 社区更活跃,插件/教程/问题好解决一些。
    mark2025
        32
    mark2025  
       2024-04-21 18:40:00 +08:00
    可以考虑 nest 或者 midwayjs ( https://https://midwayjs.org/ ). 后者纯 TypeScript ,支持 AOP 、IoC ,写 api 接口挺方便的。
    mark2025
        33
    mark2025  
       2024-04-21 18:50:00 +08:00
    @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
        34
    jchnxu  
       2024-04-24 14:32:24 +08:00
    @mark2025 感谢老哥的回复

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

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

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

    4. 没想到还有这样细心的回复,很开心
    mark2025
        35
    mark2025  
       2024-04-24 17:12:30 +08:00
    @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
        36
    jchnxu  
       2024-04-24 21:26:45 +08:00
    @mark2025 很多新名词,我慢慢看:P
    mark2025
        37
    mark2025  
       2024-04-24 21:37:56 +08:00
    @jchnxu
    AOP ,IoC 这个不用研究名词,用就行了。
    比如 IoC 涉及的是依赖注入: https://midwayjs.org/docs/servicehttps://midwayjs.org/docs/container
    AOP 涉及的是切面拦截: https://midwayjs.org/docs/aspect
    AOP 另外一个功能是写自定义装饰器。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2612 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 05:24 · PVG 13:24 · LAX 22:24 · JFK 01:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.