Realtime, Storage e o resto do Supabase
Fecha o Módulo 3 olhando além do banco. Supabase é, no fim, uma caixa de ferramentas — e além de Postgres, Auth e API automática, ele entrega peças que evitam a gente reinventar infraestrutura. Este post faz o tour e mostra a mentalidade pra usá-las bem com vibe coding.
O que mais vem na caixa
- Realtime — escutar mudanças no banco e refletir na UI sem ficar dando refresh. Útil pra tela que precisa "viver" (um painel que atualiza sozinho).
- Storage — guardar arquivos (imagens, anexos) com controle de acesso. Ex.: a capa de um post (
cover_image_url) ou anexos de atendimento. - Edge Functions / API automática — endpoints sobre os dados sem montar servidor.
A regra de ouro continua valendo
Toda peça nova do Supabase passa pelo mesmo crivo:
- Segurança primeiro. Storage também tem política de acesso — bucket aberto é o "RLS esquecido" da camada de arquivos. Realtime respeita RLS: você só recebe evento do que pode ver. Configure isso conscientemente.
- Cheque antes de criar. Bucket, canal, função — veja o que já existe antes de duplicar.
- Não é porque existe que a gente usa. A pergunta é sempre "isso resolve uma etapa real?", não "que legal, vamos usar Realtime".
Como vibe coding entra aqui
A IA é ótima pra plugar essas peças (configurar um subscribe de Realtime, um upload pro Storage) seguindo o padrão. O que continua seu:
- Decidir se vale a pena (Realtime tem custo de complexidade; nem toda tela precisa).
- Garantir a política de acesso de cada peça.
- Não cair na tentação de usar feature por novidade.
A escolha "antes de construir, veja se já existe"
Vale uma menção ao ecossistema mais amplo: hoje muita coisa que a gente construiria à mão já existe como produto gerenciado (no Supabase, na Vercel, em terceiros). Vibe coding maduro é também saber não construir o que já vem pronto e seguro — e gastar a energia no que é realmente do ClubPetro.
Fechando o módulo de dados
Você viu a espinha dorsal (#18), a modelagem tipada (#19), a segurança inegociável (#20), a verdade das migrations (#21), o auth (#22) e agora o resto da caixa. Com dados sob controle, o próximo passo é fazer o trabalho rodar sozinho.
⚠️ Armadilha #23: abrir um bucket de Storage "público só pra testar" e esquecer aberto. É o mesmo vazamento do RLS esquecido, só que com arquivos. Toda peça do Supabase nasce com acesso definido.
Fim do Módulo 3 — Supabase. Próximo: Módulo 4 (#24) — Automação com Trigger.dev.