PostgREST: Fornecendo Conteúdo HTML Usando Htmx
Usar PostgREST e htmx para servir HTML diretamente do PostgreSQL promete uma stack ultrafina — apenas um banco de dados mais uma pequena camada HTTP — para apps com muito CRUD ou “leves”. Os comentários destacam benefícios como ausência de modelos duplicados, forte segurança baseada em RLS e menor complexidade no frontend, mas alertam para riscos de XSS, templates em SQL emaranhados, preocupações de performance ao servir assets a partir do banco e dificuldades de manutenibilidade a longo prazo em sistemas maiores. Muitos veem isso como poderoso para pequenas e médias ferramentas internas ou UIs de administração, mas provavelmente insuficiente ou difícil de escalar como arquitetura principal para aplicações complexas.
Casos de Uso e Manutenibilidade
- Muitos veem PostgREST + HTMX como ideal para apps com muito CRUD, apps “leves”, painéis de administração e ferramentas internas que basicamente encapsulam um banco de dados.
- Vários alertam que isso fica difícil de manter em produtos médios/grandes ou que evoluem rapidamente: lógica enterrada em SQL/funções, templates emaranhados no banco de dados, refatorações difíceis e depuração de performance complicada.
- São feitas comparações com a antiga época de PHP/ASP ou com padrões de HTML-a-partir-do-banco da era Oracle/CouchDB, que muitas vezes viravam pesadelos de manutenção.
Segurança, Autenticação e Permissões
- Há forte ênfase em isolar um schema
apie expor apenas views; isso é considerado essencial para apps não triviais. - O próprio PostgREST segue o “deny by default” do Postgres, mas o Supabase altera os privilégios padrão para “allow”, o que preocupa alguns, especialmente em setores regulados.
- JWT + roles + RLS são vistos como o principal modelo de segurança; alguns acham a RLS flexível, mas difícil, enquanto outros preferem encaminhar gravações por funções separadas na edge.
- A geração de HTML em SQL levantou sérias preocupações de XSS; a demo inicialmente não sanitizava a entrada do usuário, o que levou a pedidos por engines de template com escaping automático.
Papel do HTMX e Debates
- Os defensores gostam da redução da complexidade no frontend: sem etapa de build, poucas dependências, lógica centrada no servidor, “locality of behavior”.
- Os críticos argumentam que o HTMX ainda depende de JS, pode ser complicado para coisas como validação e reintroduz armadilhas de escaping de HTML que frameworks SPA evitam em grande parte.
- Alguns o veem como outra variante de HTML-over-the-wire; os defensores o apresentam como “estendendo/completando os controles de hipermídia do HTML”.
Prós e Contras da Arquitetura Centrada no Banco
- Prós: menos camadas, menos código, forte alinhamento com casos de uso CRUD, aproveitamento de SQL, views e stored procedures; pode ser muito rápido e conceitualmente simples.
- Contras: acoplar a lógica ao banco complica a escalabilidade (o banco como gargalo), testes, depuração e contratação; o banco deve ser tratado como um “recurso precioso”, não como um servidor de assets.
- Muitos recomendam usar PostgREST como uma camada CRUD base, com uma API tradicional ou funções para lógica complexa.
Ferramentas, Ecossistema e Alternativas
- As pessoas mencionam o uso de ferramentas de migração/versionamento (Squitch, Pyrseas), shells de site estático (Astro) e ferramentas alternativas/centradas em SQL (pg_render, plmustache, SQLPage, SmoothDB, Omnigres, jinj.at).
- O sentimento geral: seriam necessárias ferramentas melhores para tornar essa abordagem confortável para apps de médio a grande porte (template, migrações, depuração).
Financiamento e Governança de Open Source
- PostgREST é amplamente elogiado, mas sua pequena base de doações é vista como sintomática de um financiamento fraco de OSS.
- O Supabase emprega o mantenedor principal e patrocina contribuidores; a governança é intencionalmente compartilhada para evitar controle por um único fornecedor.