NextJS内置/api服务与自定义Express服务选型问题咨询

你现阶段完全没必要单独搭自定义Express服务器，用NextJS内置的/api路由承载tRPC服务就够，所谓“内置API可扩展性差、架构不合理”是典型的认知误区。

先掰明白你对/api目录的误解 #

很多人觉得用内置API就是把所有服务端代码堆在api文件夹里，这完全是错的：

• /api本质只是NextJS给你留的HTTP请求入口，和Express里的router入口没有任何区别。你完全可以自己在项目根目录建独立的server/文件夹，按业务模块拆分服务层、数据访问层、公共工具逻辑，/api下的文件只做最薄的一层：接请求、调你写好的业务逻辑、返回结果。架构分层想怎么做就怎么做，根本不存在代码堆成一团的问题。
• 搭配tRPC用的时候更方便，你只需要在/api路径下放一个tRPC的动态入口文件就行，所有tRPC的路由定义、上下文逻辑、过程处理、业务代码全可以放在server/目录下按模块拆分，和你在Express里挂载tRPC中间件的开发体验、灵活度没有本质差别。NextJS官方给的tRPC最佳实践本身就是基于内置API路由做的，生态适配、部署兼容性都是最好的。

到底什么时候才需要单独搭自定义Express服务器？ #

只有碰到以下明确场景的时候，你再考虑换自定义服务也不迟：

• 你需要让服务端逻辑脱离NextJS独立对外提供服务，比如要给独立部署的其他应用、第三方回调提供统一入口，不想把NextJS作为整个服务端的流量入口
• 你有特殊的Node.js服务定制需求，比如要兼容某些和NextJS内置server不兼容的老旧中间件、要自定义HTTP/2服务配置、要做极细粒度的请求层性能调优——这类场景90%的开发者整个项目生命周期都碰不到
• 你从项目第一天就确定要走纯前后端分离部署：前端NextJS单独部署做SSR/静态页面，后端服务完全独立迭代、独立扩缩容，这种情况你甚至没必要用Express，选更适配后端场景的Node.js框架效率更高。

关于你担心的“未来做大型项目、拆微服务”的问题 #

完全没必要为了这种不确定的未来需求提前过度设计：

• 微服务拆分的核心是业务逻辑的解耦，和你一开始把入口放在NextJS的/api还是独立Express里没有半毛钱关系。只要你一开始做好代码分层，不把业务逻辑和框架入口强绑定，后续要拆微服务的时候，直接把对应业务模块的代码抽出去做成独立服务就行，tRPC本身也天然支持跨服务调用，迁移成本极低。
• 你现在是入门阶段，上来就折腾自定义Express，反而要多处理一堆和业务无关的配置：tRPC和Express的适配、开发环境NextJS和Express的服务联动、部署配置改造，平白增加学习成本，反而分散你学NextJS和tRPC核心用法的精力。

给你现在阶段的实操参考 #

你现在要做身份认证+CRUD，直接按下面的目录结构搭就行，这个结构哪怕做到几十万行代码的单体项目都不会乱：

project-root/
├── pages/
│   ├── api/
│   │   └── trpc/[trpc].ts # 仅放tRPC请求入口的转发代码，不写业务逻辑
│   └── # 其他前端页面路由
├── server/
│   ├── trpc.ts # tRPC实例初始化、上下文定义、公共过程封装
│   ├── auth/ # 所有认证相关逻辑：session校验、登录注册、权限判断
│   └── modules/
│       └── # 按业务模块放CRUD逻辑、对应tRPC子路由，比如user、post这类
└── # 其他公共配置、组件文件

等你真的碰到内置API路由满足不了的需求，再迁移到自定义服务器也花不了半天时间，完全没必要提前为了没发生的场景增加复杂度。

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