我的后端栈只有 TypeScript + Postgres。为什么这就够了

大多数人过早地过度思考后端。你开始构建一个新产品，突然间就开始研究 Kafka、Redis、后台工作器、消息队列、分析管道、缓存层和五个微服务。但说实话，你可能并不需要其中的大部分。

对于大量 SaaS 产品，尤其是处于早期阶段的产品，一个简单的技术栈就能让你走得更远、更快。我的整个后端技术栈就只有 TypeScript 和 Postgres——这已经足够了。

以下是我在这个堆栈上构建UserJot 的方法以及我坚持使用它的原因。

TypeScript：一种统治堆栈的语言

在所有情况下使用 TypeScript 意味着更少的上下文切换。我不需要在一个服务上使用 Python，在另一个服务上使用 Go，以及在前端使用 JavaScript 之间来回切换。一种语言就能处理所有事情——从编写 API 逻辑到验证数据，再到在整个应用程序中塑造类型。

在后端，TypeScript 的表现出奇地好。借助tRPC和等工具Zod，您可以构建快速、完全类型安全的 API，甚至无需编写单独的架构或 REST 契约。您只需验证一次输入，即可在整个应用程序中推断类型，并保持所有内容同步。

新贡献者的加入也更加容易。如果他们已经了解前端的 TypeScript，就能很快掌握后端。你不需要教他们三种不同语言或框架的来龙去脉。

人们喜欢让自己的数据堆栈变得复杂。但说实话，Postgres 简直就是一头猛兽。它存储关系型数据的能力无与伦比，如果你需要灵活性，它还能处理 JSON，支持全文搜索，并且对索引和约束的支持也十分出色。

需要后台作业？您可以使用LISTEN/NOTIFY、计划触发器，甚至在单独的工作进程中轮询表。想要存储应用事件、审计日志或分析数据？Postgres 也能做到。

现代硬件使其更加强大。在当今的云基础架构上，单个垂直扩展的 Postgres 实例可以拥有 64 个以上的 vCPU 和 256 GB 以上的 RAM。这对于大多数 SaaS 产品来说已经绰绰有余——而且远远不够。实际上，99% 的应用程序永远不会让这样的机器达到饱和状态。

关键在于：月活跃用户数并非并发用户数。如果你有 10 万月活跃用户，并不意味着你同时处理 10 万个请求。大多数用户每天登录的时间只有几分钟，有些甚至更少。你的并发量只是月活跃用户数的一小部分。你需要数百万活跃用户才能开始突破一个优化良好的 Postgres 实例的极限。

如果你到了那个地步，那问题就大了——而且你有足够的资源和时间来妥善解决它。过早扩张不仅没有必要，而且通常会导致更糟糕的决策和更脆弱的系统。

引入的工具越少，需要维护的东西就越少。每项新服务都会增加一些接口：配置文件、部署、边缘情况、监控、故障恢复。如果出现问题，你肯定想知道该去哪里查找。当你的堆栈只有两部分时，调试起来就容易多了。

这也意味着您的本地开发环境非常简单。您不需要运行 12 个容器的 Docker Compose。您不需要为后台作业、缓存或服务间通信单独设置服务。只需启动您的 Node 服务器和一个 Postgres 容器即可开始使用。

我之前构建过一些复杂的系统——Kafka 集群、ClickHouse 分析管道、Redis 支持的作业队列。它们都有各自的用途，但也需要成本。而且在产品早期，它们几乎总是不必要的。

这听起来可能违反直觉，但你的技术栈越简单，在真正需要扩展时就越容易。大多数人认为他们需要尽早优化，以免日后达到扩展极限——但通常情况恰恰相反。过早优化会让你陷入难以挽回的决策。它会产生复杂性，减慢你的速度，并使扩展变得更加困难，而不是更容易。

扩展一个基于 Postgres 和 TypeScript 构建的简单应用程序，比尝试扩展那些“以防万一”添加的庞大服务要容易得多。为增长做好准备的最佳方法是保持系统整洁，直到你知道真正需要扩展什么为止。

大多数应用不需要扩展。它们只需要存活足够长的时间就能获得用户。你很容易说服自己，你正在构建一个面向规模的应用，但你经常做的是浪费时间解决你并不存在的问题。

Postgres 每秒可处理数千次写入。它可以轻松存储数百万行数据。垂直扩展带来意想不到的提升——一台强大的 Postgres 系统足以满足您早期的扩展需求。一旦遇到真正的瓶颈，您就会清楚地知道需要改进的地方。

过早优化是一种拖延。你可以发布新功能，也可以花两周时间为一个没人访问的主页编写完美的 Redis 缓存层。我两种方法都试过。前者更胜一筹。

简单堆栈的最大优点在于它能让你快速迁移。你无需花时间将服务粘合在一起，也无需阅读长达 20 页的文档来学习一个你几乎不懂的工具。你只需构建即可。

CI/CD 变得更简单。测试变得更快。你需要更新的库更少了。当生产环境中出现问题时，需要查找的地方更少了。所有这些都意味着你可以投入更多时间去实际改进产品。

对于独立开发者或小型团队来说，这意义重大。您可以用更少的代码、更少的 Bug 和更少的上下文切换完成更多工作。您无需浪费精力管理复杂性，而是在构建用户真正关心的功能。

总会有一些极端情况，这时你可能需要更复杂的工具。但即便如此，TypeScript 和 Postgres 通常也能让你惊喜地走得更远。

后台任务？设置一个 cron 工作器，检查表中的任务并将其标记为完成。需要响应事件？LISTEN/NOTIFY在后端使用轻量级事件调度器。

缓存？当然，您可以为特定端点添加简单的内存缓存，甚至可以使用 HTTP 级别的缓存。对于大多数 SaaS 应用来说，这就足够了。

分析？将事件记录到 Postgres 表中，按计划汇总，然后显示在仪表板上。除非您要推送大量实时数据，否则这已经足够了。

事实是，您以后总是可以添加更多内容 - 但是一旦它们融入到您的架构中，就很难将其删除。

我基于这个技术栈构建了UserJot，一个用户反馈工具：仅使用 TypeScript 和 Postgres。它可以处理注册、反馈提交、全文搜索、API 请求、定时任务、后台工作器、速率限制等等——所有这些都无需引入任何其他服务。

如果你正在构建 SaaS 或内部工具，别想太多。技术栈不必华丽，只需要可靠且快速即可构建。TypeScript 和 Postgres 会让你走得比大多数人想象的更远。

保持简单，行动更快。当最终需要扩展时，您会庆幸自己从简洁开始。