关于 monorepo 的实践问题

最近看到关于 monorepo 的讨论，我想分享我现在手头上项目的架构，顺便问几个问题。

我现在的项目分为前端和后端各一个 repo ，前端是 Vue3 + Nuxt 4 ，后端是 Rust （分为 3 个 crates 和 1 个 binary ，binary 打包成 GHCR image ），目前日常维护这两个 repo 就够了。

这种模式给我带来很大方便，我现在的开发流基本上是：前端有需求 → 研究前后端各要改什么 → 前端写 spec + 给后端发 issue → 写后端 → 部署后端（后端的部署配置文件放前端 repo 里）→ 让前端对接后端。

感觉这样的架构挺顺手的，写前端的 agent 对后端实现或 schema 有什么不懂的就直接翻后端 repo 的 PR 纪录，再不懂就去看后端代码；管理起来也方便，不会因为各组件都分散而需要同步多个 repo ，也不会让整个项目变成一个混杂的大仓库。

非 monorepo 的方法我也干过，以前我把后端算法和后端实现（当时用的还是 python ）分两个 repo ，把后端算法作为 git submodule 引入后端实现的 repo 中，结果同步麻烦得要死，就改成现在这样了。

问题：前端和后端各一个 monorepo 还算 monorepo 吗？业界这种做法流行吗？为什么只听过单一混合仓和多个分散仓的争執，是不是我见得太少？