docs(nextjs-tech-select): update docs

Author: json-q

app/about/page.tsx

@@ -13,9 +13,9 @@ const headingIntroduce = [
 ];
 
 const workIntroduceContent = [
-  '需求分析、功能设计、技术选型、业务数据表结构设计',
+  '需求分析、功能设计、技术选型、业务数据表结构设计（团队内部讨论）',
   'pnpjs 和 CamlQuery 进行源数据交互，前端功能开发',
-  '负责前端项目整体架构的基础搭建和相关功能开发',
+  '负责前端项目整体架构的基础搭建和相关功能开发（基本由我负责）',
   '参与后端 Java 技术栈开发的部分工作',
 ];
 

post/dev/nextjs-tech-select.md

@@ -0,0 +1,51 @@
+---
+title: 记录一次团队 Nextjs 的项目搭建及技术选型
+date: 2025-03-28
+---
+
+# Nextjs 项目搭建及技术选型
+
+## 背景
+
+内部要做 AI 相关业务，由于 deepseek 的开源，使得相当多的公司都可以进行私有化的 AI 部署，然后需求下来，开发这边就只能研究一下了...
+
+目前采用 RAGFlow 做知识库管理及模型的调优，但是 RGAFlow 本身是不带权限控制的，不适用于公司每个部门的独立知识库，所以需要自己做一套权限控制，且 AI 对话需要和交建通对接，就意味着要兼顾 PC 和移动端
+
+- 独立的权限控制意味着需要一个独立的数据库进行管理
+- 对话等大部分接口调用 RAGFlow 提供的
+- RAGFlow 和 AI 对话之间做一个中间层的权限控制，来防止各部门的知识库混用以及信息泄露
+- 移动端适配
+
+## 技术选型
+
+不管选什么技术，一定要记住，你认为的最优解可能对个人来说是对的，并不一定适合你的团队。因此在选择技术栈时，哪怕对你来说非常合适，也一定要优先考虑团队，当然如果项目只有你一个人负责就无所谓了。
+
+### Nextjs
+
+由于 AI 对话方面就是做一个简单的权限控制，不涉及特别复杂的业务，上 Springboot 的话有点大材小用了（java 也是我们写，我哭死），这种情况下，直接选一个全栈框架是最合适的。
+
+因为内部主 React，选 Next 也是理所应当。
+
+### 组件库 antd
+
+我个人是非常希望使用 shadcn 的，因为很轻量，产物体积小，对于兼容移动端的情况下更适合，但是考虑到团队内部都是常年写后台的，而且对 tailwindcss 并不熟练，只能退而求其次，选择更 “重” 一点的 antd，这也是没办法的
+
+### orm 框架 drizzle
+
+为什么不是 prisma？
+
+其实在 Nextjs 中，prisma 是使用最多的 orm 框架，我也尝试了一下 prisma，但是很遗憾，它并不适合我的团队。因为 prisma 更像一个大而全的 orm，内置了非常多的功能，和对应的上手难度和学习成本。
+
+drizzle 是一个非常轻量级的 ORM，我第一次看文档的时候就觉得这个 orm 非常合适，因为 drizzle 只是对 sql 进行了一次很薄的封装，所有的 API 和 原生 sql 基本保持一致，意思就是只要你会 sql，你就能很轻松的上手 drizzle，学习成本是非常低的
+
+### pnpm workspace
+
+为什么使用 pnpm workspace 呢？
+
+其实当时规划的时候，有考虑到服务端的迁移，因为信创是趋势，一旦使用国产数据库，node 生态是不可能存在支持国产数据库的情况的，到时候只能使用 springboot，所以尽量将 drizzle 构成的服务端代码单独抽离，这样如果真的需要迁移，也能够在不和客户端代码耦合的情况下，减小迁移成本。
+
+其次就是一个聊天对话组件和逻辑了，将这一部分抽离，只专注于聊天组件的封装和逻辑处理
+
+### linter biomejs
+
+说实话，做这么久的项目，已经对 eslint 和 prettier 插件的启动速度、formater、linter 的速度折磨的够呛，更别提在 workspace 下的启动速度了，所以这次索性用 biomejs 来做项目的基础 lint 和 format，只是在 nextjs 中再使用 eslint 来处理一些边界问题