Next.js Monorepo 选型：多子域名独立应用还是单应用架构？

当前迁移进展 #

目前正基于nx.dev将原有单应用仓库迁移为monorepo架构，已落地的迁移节点包括：

• 上线独立的基础静态文档站点，部署在docs.company.com子域名下
• 原有主应用仍部署在根域名company.com，应用内部逻辑上可拆分为app1、app2、admin三类完全独立的业务模块

本身认可NX搭配Vercel的monorepo能力，将所有模块整合为单应用部署的便捷性，但在主应用拆分方案选型上有两个待评估的方向：

• 跨子域拆分：将主应用拆分为多个独立部署的应用，分别绑定admin.company.com、app1.company.com、app2.company.com等子域名
• 同域拆分：不使用子域名，借助Next.js的multi zones能力，在同一域名下通过路由规则划分实现多应用独立访问

现有系统的技术约束 #

待拆分的主应用为非公开站点，全链路需鉴权访问，当前技术栈有固定特征：

• 渲染模式为完全客户端渲染，无服务端渲染逻辑
• 数据层统一通过Apollo Client对接GraphQL API
• 鉴权逻辑由服务端下发带有http-only属性的JWT Cookie实现，前端脚本无法直接读取Cookie内容
• 当前登录态完全依赖Overmind.js全局状态管理维护，无内置的跨上下文全局状态持久化机制

已确认的基础配置特性：可以通过调整Cookie的Domain属性，让JWT Cookie在所有*.company.com子域名下自动随请求携带，但受http-only属性限制，前端在不同子域名下加载应用时，无法读取Cookie值重建全局状态。如果直接将应用拆分到跨子域部署，现有全局状态的持久化同步会带来极高的改造成本，因此暂未明确是否要推进应用拆分。

待明确的核心问题 #

• 跨子域名部署独立应用的优劣势分别是什么
• 同域名下基于Next.js multi zones实现多应用架构的方案，是否更适配当前的技术栈现状
• 如果最终选择切换为多子域多应用模式，应该通过什么方案解决跨子域的鉴权兼容、全局状态管理的问题

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