我把我的项目构建了四次，这就是我学到的

Source: Dev.to

Requirements

• 一个能够简要说明协会内容的着陆页
• 一个用于登记人员并在活动中签到的 web 应用

Initial Stack (2022)

• React 18
• PHP 8.1
• MySQL

运行良好且响应迅速。代码库简单且天真。

Switching to a More Powerful Stack

Next.js

想要原始的 SSR 能力、前端层的服务器端逻辑以及 SEO 优化。

Go

需要为未来的移动应用和成千上万的用户提供 API 可扩展性。

PostgreSQL

开始为托管的 PostgreSQL 服务付费，认为它比 MySQL 更有必要。

第一版在一个月内发布。

Price

第一个问题是成本。使用 render.com，每个服务每月 $7。前端、后端和数据库合计大约 $21 / month，对一个小协会来说负担不小。

Scalability

一个重大错误是把可扩展性和复杂性混为一谈。
系统充斥着抽象和层级，虽然组织良好，却难以快速修改。这种设置适合拥有众多开发者的大公司，但对小项目来说，每当需要微调功能时都成了负担。

Version 3

在意识到需要更便宜的方案后，我们在保留 SEO 好处的前提下切换了技术栈。

• Next.js – 用于 SEO
• Directus – 后台管理
• PostgreSQL

Next.js 直接调用 Directus API，在本地体验极佳。部署使用 fly.io 以获得低成本和自动机器扩展。

缺点： Directus 启动需要 5–10 秒，前端再需 2–3 秒，总计 7–13 秒才能加载着陆页。
好处： 没有月费。

Version 4

后来我们发现很多 Directus 可编辑的区块并非必要。重构后可编辑的部分仅剩三个区块。

• Next.js（完整静态站点）
• PostgreSQL 与 Prisma 作为 ORM
• NextAuth 用于快速登录系统
• 简单的仪表盘管理这三个可编辑区块

结果：在近四年工作后，仅用一周就完成了网站。

What I Have Learned

• 复杂的方案是很好的话题，却不一定适合生产代码。
• 成本和基础设施决策应在绘制 UML 图之前就确定。
• 该项目让我把产品视为整体系统的组成部分，与协会需求保持一致。
• 可扩展性是相对的，取决于你的实际需求。
• “越少考虑产品的未来，越好。” 构建简单的东西并留出成长空间——少即是多。