00:00:00如果你的 Postgres 数据库本身就是 API，而且你完全不需要编写任何后端代码，会怎么样？
00:00:05每次构建 API 时，你都在一遍又一遍地编写相同的后端代码：路由、控制器、验证、认证，这一切只是为了与你的
00:00:14数据库通信。然后你更改了一个列，所有东西都崩了。不需要自定义后端代码，不需要控制器，不需要 ORM 层。
00:00:21这就是 PostgREST 的作用。它是 Supabase 背后的引擎。它能处理繁重的生产流量，而且只需几分钟
00:00:29我就能向你展示如何实现。
00:00:31现在，如果你正在构建 API，这个工具直击整个技术栈中最让人恼火的痛点。
00:00:40逻辑重复。你在数据库中定义了数据，
00:00:44然后你又在其他地方定义访问规则、后端代码和验证。
00:00:49接着我们又在别处做同样的响应处理。同一个系统，多层架构，多重出错的机会。
00:00:56PostgREST 解决了这一切。它在 GitHub 上拥有超过 26,000 颗星，并被 Supabase 用于生产规模。
00:01:03它能在几分钟内将你的模式（Schema）转换为生产就绪的 REST API。没有 ORM，没有控制器。
00:01:10安全机制存在于数据库中，这意味着更少的重复、更少的维护，以及更少的时间花在那些无聊的衔接工作上。
00:01:19让我展示给你看。如果你喜欢能加速工作流的代码工具，请务必订阅。
00:01:24我们经常会发布新视频。
00:01:26好了。现在让我们实际动手构建。好的，这是配置：三个容器。
00:01:32就这样：Postgres、PostgREST 和用于文档的 Swagger UI。
00:01:38这是 Docker Compose 文件。这里没什么复杂的，只是我连接在一起的三个服务。
00:01:45我用万无一失的命令 Docker Compose 启动它。它运行起来了，我也就完工了。
00:01:51不需要安装依赖，不需要设置服务器。现在，让我们看看数据库。
00:01:55我要运行这个 Docker 命令，搞定。一个超级简单的 todos 表：ID、标题、是否完成、创建时间，所有基础字段。
00:02:04这就是全部内容。但接下来的部分才是它真正有用的地方。
00:02:09行级安全性（RLS）。我们直接在数据库内部用 SQL 定义谁可以访问什么。
00:02:17不需要在系统的其他地方编写后端认证逻辑。这是策略内容：
00:02:22我对匿名用户开放了完整权限，设置 using 为 true。所以目前，所有操作都是允许的。现在看好了。
00:02:29我要用这个 curl 命令访问 get todos，搞定。完整的 JSON 数据直接来自 Postgres。
00:02:35没有 API 代码。在此基础上，让我现在过滤一下数据。立即生效。
00:02:41如果我排序，瞧，搞定了。现在让我们创建另一行，发送一个带有 JSON 主体的 POST 请求，这就完成了。
00:02:50数据已经在数据库里了。这里没有 ORM 层在试图追赶进度。
00:02:56这是最让人们惊叹的部分：Open API 文档，自动生成的 Swagger UI。它就在这里。
00:03:04我打开它，我们就得到了一个完整的交互式 API。你可以探索所有内容，测试端点，查看模式。
00:03:11所以从零开始，你在不到一分钟的时间内就拥有了完整的 CRUD、过滤、排序、分页，以及通过 RLS 实现的基础认证和文档。
00:03:21那么，为什么人们会用它呢？好吧，如果这些还不够，那是因为传统的后端工作是有“税收”的。
00:03:26而大部分税收并不是真正的产品开发。实际上我们做的是所有的维护工作，对吧？
00:03:33想想标准的技术栈，也许是 Express、Prisma、控制器、服务、验证都在一个地方。
00:03:40然后认证在另一个地方。你的数据库逻辑又完全在另一个地方。
00:03:45现在对比一下 Postgres。你的模式定义了 API，你的安全性就是 RLS。
00:03:52你的关系已经存在于数据库中了。所以我们不是围绕数据构建翻译层，而是直接正确地暴露数据。
00:04:02这是非常不同的。再对比一下自定义后端，你必须自己编写一切。
00:04:07这确实给了你灵活性，当然，但也给了你更多需要维护的代码。
00:04:13PostgREST 保持简单：REST 加上 Postgres。安全性在数据库中，而不是分散在中间件或路由处理器中。
00:04:23你的维护成本保持在低位，因为你的 API 会跟随你的模式同步。这就是人们喜欢它的原因。
00:04:28坦白说，这也是人们容易陷入麻烦的地方，因为一旦某样东西感觉如此简洁，人们就会表现得像它能解决一切。
00:04:34它并不能解决所有问题，对吧？仍然有一些事情我们需要注意。
00:04:38会有权衡，在动它之前，你应该知道要注意什么。
00:04:43人们喜欢它的原因，嗯，很明显：构建速度快。你可以非常快速地将想法转化为可用的 API。
00:04:51而且它的扩展性也非常好。此外，对吧，Supabase 已经证明了这一点。
00:04:55他们正在使用它。但缺点在于，大量使用行级安全性会增加数据库的负载。
00:05:02所以你需要仔细考虑如何设计。复杂的逻辑可能会迫使你使用大量的 SQL 函数或视图。
00:05:10有些人会喜欢那样，而有些人会讨厌。那么，你应该使用或者甚至尝试它吗？
00:05:15是的，对于合适的项目。如果你在构建原型、MVP 或任何以 Postgres 为中心的东西，那么当然值得一试，对吧？
00:05:23你会开发得更快，写更少的代码，并且通过将规则下沉到数据库中获得更强的安全性默认设置。
00:05:32现在，如果你的应用逻辑非常复杂，你可能仍需要一个薄薄的后端层，比如一个处理边缘情况的小型 BFF 层。
00:05:40但即便如此，Postgres 也可以承担底层的绝大部分重活。所以核心结论是：Postgres 让你发布更快、安全更好、维护更少。
00:05:50你的数据库成为了真实数据的源头，而你的 API 是从中自然衍生出来的，而不是变成一个独立的系统。
00:05:58如果你喜欢这类编程工具和技巧，请务必订阅 Better Stack 频道。我们下个视频见。