Plataforma Formação Continuada
Software para rede pública onde a decisão que definiu tudo foi onde colocar a regra: no banco, não no cliente — porque o cliente é a internet de uma escola pública.
Função
Frontend & Database Architect
Período
2023 - 2024
Cliente / Contexto
Secretaria de Educação
Links
Tecnologias
Professores atendidos
200+Regra no banco, não no cliente
14 RLSEmissão de certificado
3sO problema
Dois problemas chegaram juntos: folha de presença assinada à mão, que fraudava, e certificado emitido à mão, que demorava meses. O que restringia a solução não era nenhum dos dois — era o ambiente. O sistema precisava abrir na internet de escola pública, no aparelho que a escola já tem. Isso descarta de saída o caminho confortável de resolver a regra de negócio no frontend, porque cada regra no cliente é peso no pacote que viaja pela rede e é uma regra que alguém pode contornar pelo console do navegador.
A decisão
A decisão foi empurrar toda a lógica que importa para dentro do banco. Validação de presença e geração de certificado viraram funções em PL/pgSQL expostas por RPC do Supabase; o isolamento dos dados de cada professor virou 14 políticas de Row-Level Security no próprio Postgres. O frontend em React + Vite ficou deliberadamente magro — ele desenha e envia, não decide. O ganho é duplo, e foi o argumento apresentado ao cliente: o pacote que viaja pela rede da escola encolhe, e a regra passa a ser inviolável pelo cliente por construção, não por disciplina de quem escreve a tela.
O resultado
O software foi entregue e homologado, com mais de 200 professores fazendo check-in digital e certificado autenticado saindo em menos de 3 segundos — o passivo de digitação da secretaria acabou. O limite honesto desta entrega: regra de negócio dentro do banco é ótima para integridade e ruim para quem chega depois. PL/pgSQL não aparece no code review de um time de frontend, e a manutenção fica dependente de quem conhece o schema.