PostgREST：使用 Htmx 提供 HTML 内容

原文 ↗ Hacker News 讨论 ↗

使用 PostgREST 和 htmx 直接从 PostgreSQL 提供 HTML，承诺的是一个极薄的技术栈——仅需数据库加一个小型 HTTP 层——适合 CRUD 密集型或“轻量”应用。评论者强调了诸如无需重复建模、基于 RLS 的强安全性以及更低的前端复杂度等优点，但也警告了 XSS 风险、基于 SQL 的模板纠缠、从数据库提供资源时的性能担忧，以及在更大型系统中的长期可维护性。许多人认为它非常适合小型到中型的内部工具或管理界面，但作为复杂应用的主要架构，可能不够强大，也难以扩展。

用例与可维护性

  • 许多人认为 PostgREST + HTMX 非常适合 CRUD 密集型、“轻量”应用、管理面板和主要围绕数据库封装的内部工具。
  • 也有不少人警告说，对于中大型或快速演进的产品，它会变得很难维护：逻辑埋在 SQL/函数里、数据库中的模板纠缠不清、重构困难，以及性能排查困难。
  • 有人将其类比为早年的 PHP/ASP 时代，或 Oracle/CouchDB 时代从数据库直接生成 HTML 的模式，这些最终往往变成了维护噩梦。

安全性、认证与权限

  • 强调要隔离一个 api schema，并且只暴露视图；对于非平凡应用来说，这被认为是必需的。
  • PostgREST 本身遵循 Postgres 的“默认拒绝”，但 Supabase 会将默认权限改为“允许”，这让一些人感到警惕，尤其是在受监管行业中。
  • JWT + roles + RLS 被视为主要的安全模型；有些人觉得 RLS 灵活但棘手，另一些人更喜欢通过单独的 edge functions 处理写入路由。
  • 在 SQL 中生成 HTML 引发了严重的 XSS 担忧；演示最初并未对用户输入进行净化，因此有人呼吁使用带自动转义的模板引擎。

HTMX 的角色与争论

  • 支持者喜欢它降低了前端复杂度：无需构建步骤、依赖极少、以服务器为中心的逻辑、“行为局部性”。
  • 批评者认为 HTMX 仍然依赖 JS，对于验证等场景可能很棘手，并且重新引入了 HTML 转义陷阱，而这些问题在 SPA 框架中大多已经被避免。
  • 有人将其视为另一种 HTML-over-the-wire 变体；支持者则将其定位为“扩展/完成 HTML 的超媒体控制”。

以数据库为中心的架构优缺点

  • 优点：层次更少、代码更少、与 CRUD 用例高度契合、充分利用 SQL、视图和存储过程；可以非常快，而且概念上很简单。
  • 缺点：将逻辑与数据库耦合会使扩展变得复杂（数据库成为瓶颈）、测试、调试和招聘都更困难；数据库应被视为“珍贵资源”，而不是应用服务器。
  • 许多人建议将 PostgREST 用作基础 CRUD 层，而对于复杂逻辑则使用传统 API 或函数。

工具、生态与替代方案

  • 人们提到使用迁移/版本控制工具（Squitch、Pyrseas）、静态站点外壳（Astro），以及其他/sql 中心工具（pg_render、plmustache、SQLPage、SmoothDB、Omnigres、jinj.at）。
  • 普遍观点是：要让这种方法在中大型应用中更舒适，还需要更好的工具支持（模板、迁移、调试）。

开源资金与治理

  • PostgREST 广受赞誉，但其很小的捐助基础被视为开源融资不足的症状。
  • Supabase 雇佣了首席维护者，并资助贡献者；治理上刻意采取共享模式，以避免单一供应商控制。