本周有闲，审了一套解决方案。看文档之前没啥期待，读完之后觉得技术方还是下了功夫的。
之所以一开始觉得枯燥，原因是需求导向过于普遍化：
- 系统解耦，服务端和客户端分开。
- 客户端方面，只提供页面端（无服务端渲染）做托底。其他诸如手机上面的安卓、苹果、鸿蒙，电脑上面的windows、mac、各类信创Linux，乃至各类大屏幕，全由下游合作方决定是否定制或自理。
- 实现语言的取向是优先TS，兼顾国内和湾区两条战线、争取多端语言相近。
- 不绑定特别的基础设施提供方。
- 微服务使用方面自我限缩。
- 负载均衡方面不过高要求（使用场景预设访问量天花板不高）。
- 都上云，方便运维。
可以直接理解为Next那种全栈开发的小团队往上，和K8S部署的fedration往下，中间那个CRUD业务系统生态位。比”传统“的单体应用扩充些，但（主观上）不追求规模。
拿到的方案基本情况如下：
- 服务端采用Bun做运行时、基础框架选择Hono、ORM方面是Drizzle、数据规范工具Zod挑大梁（页面端也是）。
- 页面端用Vite搭建React的脚手架和打包，页面布局和组件用的是Shadcn，路由、表单和状态管理走的是Tanstack一系。
- 服务端和页面端之间通信用Hono专属的RPC，保证整个开发流程类型安全。
- 数据库用的neon和supabase做范例。
- 鉴权方面提供了Kinde和Authjs两种，完全自行处理或部分交由第三方均可。
- 容器部署（不限Vercel CF之类平台），一个docker-compose up命令启动运行。
之所以觉得技术方不是应付了事，理由列出：
- 服务端的主要技术，基本都是这两年才较大规模投入生产应用且口碑不错。在这类规模可预期的系统上用，性能、易用性和风险上能取得（我主观认为的）不错平衡。
- 页面端选择较轻的Vite和React，同样能依托最活跃的生态圈。组件方案都久经考验了，性能虽然谈不上太多追求、开发体验确实是第一流的。
- 数据库也好、基建也罢，不绑定。虽然都是上云，却不绑定具体供应商。
应用场景不大不小，传统的解决方案有很多现成的。但要切近开发团队的语言取向、符合市场偏好、保持技术敏锐度、稳定性有足够下限，全都综合起来并不容易。
