Supabase Auth no vibe coding: não use o user como modelo

Não use o user do Supabase Auth como modelo do produto. Separe a identidade externa no dia 1 e desenhe o adapter, mesmo sem trocar de provedor. Colar o user do Auth no domínio trava a troca desde o dia 1.

gbrl808 chegou nessa conversa no meio da live de 99 min em que desenha o bookm, um gestor de favoritos (site mais extensão) desacoplado do browser. Ele trabalha local e precisa de uma base de dados. O assunto da cena é desenho: ele pergunta a mais de 1 IA como organizar o backend sem se prender.

discutindo aqui com as IAS como organizar esse backend aí.

Eu gosto sempre de perguntar a várias, então perguntei portei por perplexidade aqui. Estou a usar antigravity aqui também.

A preocupação correta no desenho do bookm

A pergunta dele é se a arquitetura unida agora limita o crescimento. O agente confirma o recorte:

Mas e se a arquitetura unida agora limitar o crescimento? Esse é que é o ponto. Essa é a preocupação correta.

A preocupação é lock-in de modelo: o user do Auth virar o objeto que o produto conhece. O dono do favorito passa a depender de um tipo que o provedor define. No dia em que você quiser sair, a troca deixa de ser de login e vira reescrita do domínio.

Ele está fazendo local e precisa de uma central de favoritos na web, desacoplada do browser. A transcrição da fala sobre o produto sai torta, mas a necessidade está clara: uma base única, sem favorito preso ao browser. Se essa base tratar o usuário do Auth como o usuário do bookm, o favorito fica amarrado ao provedor. Isso aparece também em vibe coding para extensao chrome capturar titulo de pagina spa.

Supabase Auth no vibe coding trava no user

No vibe coding, o caminho mais curto é o que o agente oferece primeiro: login pronto e consulta do frontend direto na base, com a regra de negócio numa função paga. O login fica pronto cedo, e a consulta direta já mistura o user do Auth com a regra do produto. Vale ver como isso terminou em overpromise.

O Auth do Supabase usa o Postgres do projeto por baixo. A transcrição diz isso de um jeito esburacado ("o AT utiliza o post SQL do projeto por baixo"), e o detalhe importa sem virar diagrama. O user que você recebe no login mora no mesmo banco em que você vai gravar favorito. Sem um recorte no prompt, o desenho nasce colado. Vale ver como isso terminou em vibe coding para nao deixar agente mudar migracao no redesign.

Consulta direta do frontend mais lógica de negócio na função paga gera lock desde o dia 1. O produto importa o user do Auth e o resto do código passa a depender dele. Isso aparece também em vibe coding para nao trocar supabase por postgres na vps.

Este post não é sobre RLS no Supabase. RLS é tabela a tabela. Aqui o recorte é outro: não usar o user do Auth como modelo. Foi o mesmo caminho de pricing page. O mesmo problema apareceu em supabase pricing.

A stack do bookm já tinha sido decidida no dia anterior pelo reuso entre extensão e site. A conversa de React Native vs Flutter fechou essa stack. Esta conversa fecha o recorte de identidade. Isso aparece também em vibe coding para landing page do app na play store.

A imigração cria adapters, segundo a transcrição

A saída que o agente lê é desenhar o adapter, com o Auth ainda no lugar:

A imigração cria adapters. Separe utilizador de identidade externa. Não uso directamente user como seu modelo.

"Imigração" é o que a legenda gravou. Fora das aspas, o sentido é migração. Dentro, fica o que ele ouviu. A frase separa o usuário do produto da identidade que um provedor devolve.

Separar no dia 1 é recusar o atalho. O modelo do bookm conhece um usuário seu. A identidade externa, o user do Supabase Auth, chega por um adapter. Se o provedor mudar, o adapter absorve a diferença. Sem adapter, a migração reescreve favorito e regra. Foi o mesmo caminho de recut.

Ele não implementa o adapter nesta live. O resto da sessão vai para outro assunto. O que fica gravado é o desenho e a recusa de usar o user diretamente como modelo. Vale ver como isso terminou em supabase edge functions.

O mesmo gesto de cruzar modelos que ele usou para juntar product.md e implementation plan no Antigravity volta no backend: ele pergunta a várias, e o recorte de identidade entra na conversa.

O que desenhar amanhã, sem implementar

No ritmo do vibe coding, o login que o agente monta entra no código se você não escrever o recorte antes. Amanhã, antes de aceitar esse login, escreva no prompt 2 recortes. O usuário do produto fica separado do user do Auth. A identidade externa entra por adapter, mesmo que você não escreva o adapter hoje. Isso aparece também em vibe coding para enviar app para revisao na play store.

Peça ao agente para apontar onde o frontend consulta a base direto e onde a regra de negócio foi parar numa função paga. Esses 2 pontos são o lock do dia 1. Se os 2 existirem e o user do Auth for o tipo que o resto do código importa, o lock já está feito.

Fique no Supabase Auth se quiser. Desenhe o usuário do produto à parte do user que o Auth devolve. A live de 99 min registra a conversa inteira; dá para assistir à live no trecho em que ele discute o backend com as IAs e o agente confirma que a preocupação de crescimento é a correta.