在NextJS中发起API请求是否常规？两种后端对接方案长期哪种更优？

1. Next.js 中编写数据库交互逻辑是否是常规做法 #

是非常普遍的常规做法。
Next.js 官方设计的 Route Handlers、Server Actions 以及服务端组件，本身就支持直接在 Next.js 服务侧编写服务端逻辑，包括直接连接数据库做增删改查，中小团队开发独立产品、内部工具、B端系统时，这种全栈开发模式是标准玩法之一，能大幅提升开发效率。

2. 两种方案的长期适用性对比 #

方案1：Next.js 直接调用现有 Express API #

适用场景

• 现有 Express 服务已经迭代成熟，除了当前 Web 端外，还有小程序、App、第三方接口等其他调用方
• 团队有明确的前后端分工，后端团队独立维护核心业务逻辑
• 未来有微服务拆分、多服务统一收口的规划

优势

• 前后端逻辑完全解耦，两端迭代互不干扰，Express 侧的逻辑可以全端复用
• 权责清晰，不会出现前端修改到核心业务逻辑的问题
• 迁移成本极低，仅需调整前端侧的接口请求配置，不需要修改原有后端逻辑

劣势

• SSR/ISR 场景下多了一层 Next.js 到 Express 的内部网络请求，比直接连数据库多几十毫秒的耗时，对首屏性能要求极高的场景会有影响
• 简单的接口调整也需要跨团队沟通，迭代效率较低

方案2：迁移后端逻辑到 Next.js 直接与数据库交互 #

适用场景

• 现有 Express 服务仅为当前 Web 端提供服务，没有其他调用方
• 团队为全栈团队，同一批人员维护前后端逻辑，没有严格的前后端分工
• 项目为中小规模，业务逻辑复杂度低，没有复杂的分布式事务、跨服务调用需求

优势

• 性能更优，SSR/ISR 场景下直接在服务侧读取数据库，省去了内部网络请求耗时，首屏加载速度更快
• 迭代效率高，单个全栈开发可以覆盖从页面到数据库的全流程开发，不需要跨团队沟通
• 运维成本低，少了一套需要部署、监控、扩容的后端服务

劣势

• 前后端逻辑高度耦合，后续如果新增其他端需求，需要额外抽取后端逻辑，迁移成本高
• 业务复杂度提升后，Next.js 项目会逐渐臃肿，后期维护难度变大
• 团队有明确前后端分工的情况下，容易出现权责不清的问题

最终选型建议 #

没有绝对的最优方案，按需选择即可：

• 如果业务长期规划有多端需求，团队规模会扩张到有独立后端团队，选方案1，长期扩展性更强
• 如果业务仅面向 Web 端，团队为小型全栈团队，未来1-2年业务规模不会出现爆发式增长，选方案2，开发和维护效率更高

内容的提问来源于stack exchange，提问作者Bhushan