PostgREST Deleta 80% do Código do Seu Backend

BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00E se o seu banco de dados Postgres fosse a API e você não tivesse que escrever nenhum código de backend?
00:00:05Toda vez que você constrói uma API, escreve o mesmo código de backend repetidamente. Rotas, controladores, validação, autenticação, tudo isso só para falar com o seu
00:00:14banco de dados. Então você muda uma coluna e tudo quebra. Sem código de backend customizado. Sem controladores. Sem camada de ORM.
00:00:21É isso que o PostgREST faz. É o motor por trás do Supabase. Ele lida com tráfego de produção sério e em apenas alguns minutos
00:00:29eu vou te mostrar como.
00:00:31Agora, se você constrói APIs, esta ferramenta ataca os pontos problemáticos mais irritantes de toda a stack.
00:00:40Lógica duplicada. Você define os dados no banco de dados.
00:00:44Depois define regras de acesso, código de backend e validação em outro lugar.
00:00:49Depois fazemos o mesmo para o tratamento de respostas em outro lugar. Mesmo sistema, múltiplas camadas, múltiplas chances de as coisas quebrarem.
00:00:56O PostgREST resolve tudo isso. Ele tem mais de 26.000 estrelas no GitHub e é usado pelo Supabase em escala de produção.
00:01:03Ele transforma seu schema em uma API REST pronta para produção em minutos. Não há ORM, nem controladores.
00:01:10A segurança vive no banco de dados, o que significa menos duplicação, menos manutenção e muito menos tempo gasto conectando todas aquelas coisas chatas.
00:01:19Deixe-me mostrar. Se você gosta de ferramentas de codificação que aceleram seu workflow, não esqueça de se inscrever.
00:01:24Temos vídeos saindo o tempo todo.
00:01:26Tudo bem. Agora vamos realmente construir isso. Certo, aqui está a configuração. Três containers.
00:01:32Só isso. Postgres, PostgREST e Swagger UI para a documentação.
00:01:38Aqui está o arquivo Docker Compose. Não tem muita coisa acontecendo aqui. Apenas três serviços que eu conectei.
00:01:45Eu o inicio com nosso comando infalível Docker Compose. Ele vai começar a rodar e pronto.
00:01:51Não precisa instalar dependências. Nem configurar um servidor. Agora, vamos olhar o banco de dados.
00:01:55Vou rodar este comando docker aqui e pronto. Uma tabela de tarefas super simples. ID, título, concluído, criado, todas as coisas básicas.
00:02:04É sério, é só isso que está acontecendo aqui. Mas esta, esta é a parte onde se torna útil.
00:02:09Segurança em nível de linha (RLS). Definimos quem pode acessar o quê diretamente no SQL dentro do banco de dados.
00:02:17Nenhuma lógica de autenticação de backend sentada em outro lugar do nosso sistema. Aqui está a política.
00:02:22Eu tenho acesso total anônimo usando true com check true. Então, por enquanto, tudo é permitido. Agora veja isto.
00:02:29Vou chamar o get todos com este comando curl e pronto. JSON completo direto do Postgres.
00:02:35Sem código de API. Agora, aproveitando isso, deixe-me filtrar agora. Funciona imediatamente.
00:02:41Se eu ordenar, bum, aí está. Agora vamos criar outra linha, enviar um post request com um corpo JSON e terminamos.
00:02:50E já está no banco de dados. Não há camada de ORM tentando acompanhar o ritmo aqui.
00:02:56E aqui está a parte que realmente impressiona as pessoas. Documentação Open API, Swagger UI gerado automaticamente. Já está aqui.
00:03:04Eu o abro e temos uma API interativa completa. Você pode explorar tudo, testar endpoints, ver schemas.
00:03:11Então, do zero, você agora tem CRUD completo, filtragem, ordenação, paginação. Você tem autenticação básica via RLS e docs em pouco menos de um minuto.
00:03:21Então, por que as pessoas usam isso? Bem, se isso não fosse suficiente, porque o trabalho tradicional de backend tem um custo.
00:03:26E a maior parte desse custo não é trabalho de produto. Na verdade, o que estamos fazendo é todo esse trabalho de manutenção, certo?
00:03:33Se você pensar na stack normal, talvez seja Express, Prisma, controladores, serviços, validação em um só lugar.
00:03:40Depois temos a autenticação em outro lugar. A lógica do seu banco de dados está em outro lugar inteiramente diferente.
00:03:45Agora compare isso com o PostgREST. Seu schema define a API. Sua segurança é RLS.
00:03:52Seus relacionamentos já existem no banco de dados. Então, em vez de construir uma camada de tradução em torno dos seus dados, apenas os expomos corretamente.
00:04:02Isso é muito diferente. Agora compare com um backend customizado. Você tem que escrever tudo sozinho.
00:04:07Isso te dá flexibilidade. Sim, claro. Mas também te dá muito mais código para manter.
00:04:13O PostgREST permanece mais simples. REST mais Postgres. A segurança está no banco de dados. Não está espalhada por middlewares ou manipuladores de rota.
00:04:23Sua manutenção continua baixa porque sua API acompanha seu schema. É por isso que as pessoas gostam.
00:04:28Agora, para ser justo, é aqui que as pessoas se metem em problemas, porque quando algo começa a parecer limpo assim, as pessoas agem como se resolvesse tudo.
00:04:34Isso não resolve tudo, certo? Ainda há coisas que precisamos observar.
00:04:38Haverá trade-offs e você deve saber o que vigiar antes mesmo de tocar nisso.
00:04:43O que as pessoas amam aqui é, bem, meio óbvio. É rápido de construir. Você pode ir da ideia para uma API funcional muito rápido.
00:04:51E escala muito bem também. Além disso, o Supabase meio que prova isso.
00:04:55Eles estão usando isso. Mas os pontos negativos aqui são coisas como: o uso pesado de RLS vai aumentar a carga do banco de dados.
00:05:02Então você precisa pensar cuidadosamente em como projetar isso. Lógica complexa pode te empurrar para muitas funções SQL ou views.
00:05:10E algumas pessoas amam isso e outras vão odiar. Então, você deve usar isso ou pelo menos tentar?
00:05:15Sim, para os projetos certos. Se você está construindo protótipos, MVPs ou qualquer coisa centrada em Postgres, então claro, por que não tentar, certo?
00:05:23Você vai se mover mais rápido. Vai escrever menos código e terá padrões de segurança mais fortes ao levar as regras para dentro do banco de dados.
00:05:32Agora, se seu app tem lógica muito complexa, você ainda pode querer uma camada fina de backend por cima, algo pequeno, uma camada BFF para casos extremos.
00:05:40Mas mesmo assim, o Postgres pode fazer a maior parte do trabalho pesado por baixo. Então a grande lição é esta: o Postgres permite que você entregue mais rápido, com mais segurança e menos manutenção.
00:05:50Seu banco de dados se torna a fonte real de dados, e sua API surge disso em vez de se tornar seu próprio sistema separado.
00:05:58Se você gosta de ferramentas de codificação e dicas como esta, não esqueça de se inscrever no canal Better Stack. Nos vemos em outro vídeo.

Key Takeaway

O PostgREST elimina 80% do desenvolvimento de backend ao transformar o esquema do banco de dados Postgres em uma API REST funcional com segurança RLS integrada e documentação Swagger automática.

Highlights

O PostgREST transforma o esquema do banco de dados Postgres diretamente em uma API REST pronta para produção em poucos minutos.

A ferramenta elimina a necessidade de escrever rotas, controladores e camadas de ORM customizadas, reduzindo o código de backend em até 80%.

A segurança é gerenciada dentro do banco de dados através de Row Level Security (RLS), centralizando as regras de acesso no SQL.

A documentação interativa via Swagger UI e a especificação Open API são geradas automaticamente a partir do esquema do banco de dados.

O sistema suporta filtragem, ordenação e paginação nativamente via comandos curl e requisições JSON.

O PostgREST é o motor principal por trás do Supabase e gerencia tráfego de escala de produção com alta performance.

Timeline

A eliminação da redundância no desenvolvimento de backend

  • O desenvolvimento tradicional de APIs exige a repetição constante de códigos para rotas, controladores e validação.
  • Mudanças simples em colunas do banco de dados frequentemente quebram camadas externas de código e ORMs.
  • O PostgREST resolve a duplicação de lógica mantendo as definições de dados e regras de acesso em um único lugar.

O trabalho recorrente de conectar o banco de dados a uma camada de backend separada cria múltiplas chances de falhas no sistema. O uso do PostgREST permite que o esquema do banco de dados dite a estrutura da API, removendo a necessidade de sincronizar manualmente as mudanças entre o SQL e o código da aplicação. Esta abordagem é validada pelo seu uso em larga escala pelo Supabase e pela comunidade no GitHub.

Configuração técnica e implementação prática

  • A infraestrutura completa requer apenas três containers Docker: Postgres, PostgREST e Swagger UI.
  • As políticas de segurança Row Level Security (RLS) definem o acesso aos dados diretamente no nível da tabela SQL.
  • O sistema gera respostas JSON completas para operações CRUD sem a necessidade de um servidor de aplicação tradicional.

A montagem do ambiente é feita via Docker Compose, dispensando a instalação manual de dependências ou configurações complexas de servidor. Uma tabela de tarefas simples com ID e título torna-se instantaneamente acessível via comandos curl assim que a política RLS é definida como verdadeira para acesso anônimo. Além dos dados, a interface do Swagger UI surge automaticamente, permitindo testar endpoints e visualizar esquemas sem esforço adicional de codificação.

Comparação de arquitetura e trade-offs de desempenho

  • A manutenção de backends customizados como Express ou Prisma consome tempo que poderia ser dedicado ao produto.
  • O uso intensivo de RLS transfere o processamento de segurança para o banco de dados, aumentando sua carga de trabalho.
  • Lógicas de negócio extremamente complexas podem exigir o uso de funções SQL, views ou uma camada fina de Backend-for-Frontend (BFF).

Ao contrário da stack normal onde a lógica está espalhada por middlewares e manipuladores de rota, o PostgREST mantém a segurança e os relacionamentos dentro do Postgres. Embora essa centralização acelere o desenvolvimento de protótipos e MVPs, o aumento da carga no banco de dados exige um design cuidadoso do esquema. A ferramenta é ideal para projetos centrados em dados, permitindo que a API seja uma extensão natural da fonte da verdade em vez de um sistema isolado.

Community Posts

View all posts