PostgREST: Proporcionando contenido HTML usando Htmx
Usar PostgREST y htmx para servir HTML directamente desde PostgreSQL promete una pila ultradelgada —solo una base de datos más una pequeña capa HTTP— para apps centradas en CRUD o “ligeras”. Quienes comentan destacan ventajas como no duplicar modelos, una seguridad sólida basada en RLS y menor complejidad del frontend, pero advierten sobre riesgos de XSS, plantillas en SQL enredadas, preocupaciones de rendimiento al servir activos desde la DB y mantenibilidad a largo plazo para sistemas grandes. Muchos lo ven poderoso para herramientas internas o UIs de administración pequeñas o medianas, aunque probablemente insuficiente o difícil de escalar como arquitectura principal para aplicaciones complejas.
Casos de uso y mantenibilidad
- Muchos ven PostgREST + HTMX como ideal para apps centradas en CRUD, “ligeras”, paneles de administración y herramientas internas que en su mayoría envuelven una base de datos.
- Varios advierten que se vuelve difícil de mantener para productos medianos/grandes o de rápida evolución: lógica enterrada en SQL/funciones, plantillas enredadas en la DB, refactors complicados y depuración del rendimiento difícil.
- Se hacen comparaciones con los viejos tiempos de PHP/ASP o patrones de HTML desde la DB de las épocas de Oracle/CouchDB, que a menudo terminaron siendo pesadillas de mantenimiento.
Seguridad, autenticación y permisos
- Se pone mucho énfasis en aislar un esquema
apiy exponer solo vistas; esto se considera esencial para apps no triviales. - PostgREST en sí sigue el “deny by default” de Postgres, pero Supabase cambia los privilegios por defecto a “allow”, lo que alarma a algunos, especialmente en sectores regulados.
- JWT + roles + RLS se ven como el modelo de seguridad principal; algunos encuentran RLS flexible pero delicado, otros prefieren enrutar las escrituras a través de funciones edge separadas.
- La generación de HTML en SQL planteó serias preocupaciones de XSS; la demo inicialmente no saneaba la entrada del usuario, lo que provocó llamadas a motores de plantillas con escape automático.
Papel de HTMX y debates
- A quienes lo apoyan les gusta la complejidad reducida del frontend: sin paso de compilación, dependencias mínimas, lógica centrada en el servidor, “localidad de comportamiento”.
- Quienes lo critican argumentan que HTMX sigue dependiendo de JS, puede ser complicado para cosas como la validación y reintroduce trampas de escape HTML que los frameworks SPA en gran medida evitan.
- Algunos lo ven como otra variante de HTML-over-the-wire; sus defensores lo presentan como “extender/completar los controles de hipermedia de HTML”.
Pros y contras de una arquitectura centrada en la base de datos
- Pros: menos capas, menos código, fuerte alineación con casos de uso CRUD, aprovechamiento de SQL, vistas y procedimientos almacenados; puede ser muy rápido y conceptualmente simple.
- Contras: acoplar la lógica a la DB complica la escalabilidad (la DB como cuello de botella), las pruebas, la depuración y la contratación; la DB debe tratarse como un “recurso precioso”, no como un servidor de activos.
- Muchos recomiendan usar PostgREST como una capa CRUD base, con una API tradicional o funciones para la lógica compleja.
Herramientas, ecosistema y alternativas
- Se mencionan herramientas de migración/versionado (Squitch, Pyrseas), shells de sitios estáticos (Astro) y herramientas alternativas/centradas en SQL (pg_render, plmustache, SQLPage, SmoothDB, Omnigres, jinj.at).
- El sentimiento general: se necesitarían mejores herramientas para hacer este enfoque cómodo para apps medianas o grandes (plantillas, migraciones, depuración).
Financiación y gobernanza del software libre
- PostgREST es ampliamente elogiado, pero su pequeña base de donaciones se ve como sintomática de la mala financiación del OSS.
- Supabase emplea al mantenedor principal y patrocina a contribuyentes; la gobernanza se comparte intencionalmente para evitar el control de un solo proveedor.