概述
这里主要记录我在全栈应用开发中关于技术架构选型的思路，以及实际实践总结，作为长期维护的全栈项目参考。
本文没有繁琐的代码示例，有问题可以直接看项目
👉 项目地址： nestjs-boilerplate
项目定位
在正式选型之前，首先要明确这次要做的是什么。
平时开发中，我经常会接一些小型项目，大多时候随便找个框架就能迅速搭建起来，但总是免不了各种繁琐的配置和工具链的集成。因为项目体量小，决策时间有限，技术选型以及集成开发体验的工具链常常处于被动，属于「用谁是谁」，开发过程中也缺少积累和沉淀，反而消耗了大量无意义的时间。
为了改善这种情况，我希望能提前准备好一套完整的全栈技术栈，既能快速搭建项目，也方便我在现有基础上深入理解项目的垂直结构和实现细节，而不是每次都停留在「横向选型」上耗费时间。这样不仅能提升开发效率，也能为后续项目积累可复用的经验和实践方案。
所以，我的定位是：
- 全栈应用，涵盖前端、后端、工具库、组件库等
- 适合个人独立开发，前后端均由个人完成
- 满足 MVP 快速原型
- 同时兼具易维护、易拓展的特性
技术栈选择标准
JavaScript 的生态足够庞大，通常会面临很多选择，在选择技术栈时，我主要考虑以下几个方面：
- Github Start 数量
首选高 Star 且活跃维护的项目。高 Star 但长期无人维护的不考虑。 - NPM 下载量
下载量高 → 社区热度高，说明生态活跃、问题容易被解决 - 支持 TypeScript
完整支持 TypeScript，保证类型安全，有比较好的开发体验 - 架构适配性
灵活适配不同项目规模和部署环境
Monorepo 管理方案
考虑到项目有前端、后端、UI 组件库、工具库等，为了方便管理，我选择了 Monorepo 管理方案。这样可以：
- 集中管理所有模块，统一依赖版本，避免版本冲突
- 将通用模块（如 ORM、UI 组件、TS 配置、工具链）抽离成独立包，方便拓展，是业务代码部分更加聚焦
- 简化包之间的联调开发，无需发布即可本地引用
- 优化 CI/CD 流程，提高构建效率
方案确定：
- 依赖管理：
pnpm workspace - 构建与任务编排：
Turborepo
pnpm 使用 workspace 功能来管理依赖，它可以很方便地管理 Monorepo 中的多个包
Turborepo 轻量且灵活，刚好用来弥补 pnpm 在 Monorepo 中的不足，专注于配置管理构建流程，支持增量构建和缓存，两者相互搭配。它由 Vercel 公司支持，足够活跃也值得信赖。
其他备选方案：
Lerna: 早期的 Monorepo 工具，从 2020 被爆出无人维护到 2022 正式被 Nx 团队接手（准确的说是它背后的公司 Nrwl），现在融入 Nx 生态，但它已经没有那么活跃了，基本不会考虑。Nx: 功能更加强大，专为企业级大型 Monorepo 项目设计，可以不需要 pnpm workspace 来管理依赖，它有自己更加严格的依赖管理。目前官网也添加AI-first描述，非常看好，但是学习曲线略高，暂时不考虑。
后端技术选择
方案确定
- 框架：
Nestjs - ORM:
Drizzle ORM
NestJS 它的底层可以选择 Express 或 Fastify 作为 HTTP 服务框架，默认使用的是 Express，也能无缝使用 Express 的第三方中间件，生态兼容性很好。
简单的理解，可以认为 Nestjs 是 Express 的瑞士军刀，自带了很多工具；当然这也有可能是它的缺点，有可能它自带的很多工具用不到，并且不得不接受它那一套依赖注入的设计思想。
但是 Express 实在是在庞杂了，借助 Nestjs 集成的各种工具和功能可以减少寻找和制定集成最佳实践的决策时间，架构方面，NestJS 结合了面向对象编程（OOP）、函数式编程（FP）和响应式编程（FRP）的设计理念，扩展性强、结构清晰。
Drizzle ORM 轻量级、灵活性刚好介于 TypoORM 和 Prisma 之间，而且它由于可以在 Serverless 中运行，是最近非常流行的 ORM
其他备选
Express是经典的 Node.js 框架，灵活度高，生态成熟，很多人应该或多或少都接触过。从头搭建一个偏向于自己技术栈风格的 NodeJs web 框架也是不错的选择，但是精力有限，放弃～Next.js API Routes作为前端的后端，它围绕 Nextjs 的前端，做 Serverless 是个不错的选择。但那是另一种开发方式，相信以后会使用，当前这里的还是偏向于略微传统的架构选择，保持通用型。TypeORM老牌的 ORM 框架，灵活度高，但是需要自定义 Entity、封装数据库访问、事务控制和数据库迁移等功能。它的配置繁琐，开发体验偏向底层。适合对数据库操作有较高定制化需求（适合手撕 SQL），在数据库操作过程中，可以自己根据实际项目的需要实现各种 Sql 优化策略。Prisma是当前最流行的 TypeScript ORM，类型安全极佳，API 简洁易用，社区非常活跃，适合中小型项目或表结构稳定、变动较少的项目，踩过几次数据库迁移的坑，是成熟且字段变动少项目的优选，它手撕 SQL 体验比较差
前端技术选择
方案确定
- 框架：
React - 样式：
Tailwind+ShadCN/UI
这次的前端技术选择尝试 AI-first 思路，围绕 Vibe Coding 开发流程，适配当下流行的 AI 辅助编码工具
在技术选择上像大名鼎鼎的 V0.dev 就是围绕 React 生态展开，几乎成为 V0.dev 的标配方案
另外 Cline 技术栈推荐也是这个组合。
对于 Admin 系统，使用更加轻量级的 Vite + React-Router 的构建方案来搭建，不需要考虑 SSR 相对简单， Vite 构建速度快，开发体验更友好。在有 SSR 需求的场景下 Next.js 依然是首选。
项目结构架构
├── apps/
│ ├── admin/ # 前端 (React 19 + Vite)
│ └── api/ # 基于 NestJS 的后端服务
├── packages/ # 共享包
│ ├── db/ # Drizzle ORM schemas 和迁移等脚本
│ ├── ui/ # 基于 ShadCN 的 UI 组件库
│ ├── lint-config/ # 共享的 tsconfig 配置
│ └── ts-config/ # 共享的 Eslint 配置
├── .husky/
├── pnpm-workspace.yaml # pnpm 的工作空间
├── turbo.json # Turborepo 构建配置
└── README.md
包含一个简单的 admin 系统 -> 预览如头图所示 -> 或者clone nestjs-boilerplate -> 运行预览
