【问题标题】：Should I add a custom backend to my Next.js project? [closed]我应该向我的 Next.js 项目添加自定义后端吗？ [关闭]
【发布时间】：2021-11-27 09:45:39
【问题描述】：
我之前的项目有一个完全运行的 express 后端。 创建了一个新的 Next.js 项目后，现在我必须做出一个关键决定：添加我的 express 后端还是使用 Next.js 的默认服务器。（基于目录的路由）。在阅读了Next.js doc 和其他一些资源后，我比较了每种资源的优缺点（也出现了一些问题）：
A) 如果我添加自定义快递服务器
- ✓ 提供各种包/库
- ✓ 易于使用的中间件（无需定制）
- ✘ 失去“自动静态优化”（我没看懂）
- ✘ SSR / SSG 问题（-？我不确定）
- ✘ 丢失基于目录的路由（没关系）
- ✘ 无法在 vercel 上托管（没关系）
B) 如果我保留默认的 Next.js 服务器
- ✓ 在 vercel 上托管
- ✓ 自动静态优化（我没看懂）
- ✘ 我必须将路由系统转换为基于目录的方法
- ✘ 某些包停止工作或需要更换
- ✘ 需要创建自定义中间件处理程序
我应该做哪一个？我想从尝试两种方式的人那里得到一个解释清楚的答案。提前致谢。
【问题讨论】：
标签：
javascript
express
next.js
【解决方案1】：
假设您现有的 express 应用程序使用某种 API – RESTful、GraphQL 等。
根据我自己的经验，我在 express 应用程序中拥有 API 和整个业务逻辑，包括模型层、数据层等。当然，我有很多依赖项（比如 express 本身、mongo、bcrypt 等）
我注意到 Next.js 会自动将这些依赖项捆绑到提供给前端的包中。
- 它明显增加了包大小
- 但也带来了一些与浏览器环境不兼容的依赖
显然有一个 hack 允许过滤哪些包最终在前端包中，但是，随着项目的发展，自然需要维护它。此外，我们不一定对 API 的基于目录的路由感到兴奋。
在我的项目中，我们决定将 express 应用程序与 Next.js 应用程序分开放在一个 monorepo 中。实际上，Next.js 应用程序只会从 API 中获取一些数据（用于 SSR）并根据需要进行渲染，但 Next.js 除了简单的 fetch 调用之外没有任何 BE 逻辑。
保留两个独立的应用程序也需要一定的维护；在我们的环境中，我们使用 Docker 和强化的 nginx 在 API 和 FE 代码之间路由请求。基本上所有对 /api/ 的调用都被路由到 express 应用程序。