[Vibe coder #1] Anatomia do app criado por IA: frontend, backend e DB

Cada vez mais pessoas criam apps dando instruções para a IA. Ao pedir “crie um serviço assim” a ferramentas como Cursor, Claude Code ou v0, você obtém um app funcional. Mas surge um obstáculo comum: não saber o que a IA realmente construiu. Quando ocorre um erro, você não sabe onde olhar nem o que perguntar à IA.

O primeiro passo para superar esse obstáculo não é saber ler código. É entender de quais peças seu app é formado e o que cada uma faz: ter um mapa da estrutura. São as três peças que os desenvolvedores chamam de frontend, backend e DB. Neste artigo, explicamos as três por completo para não desenvolvedores. Com esse mapa, API keys, Git, deploy e custos dos próximos artigos se encaixam no lugar certo.

Um app tem a mesma estrutura de um restaurante

Seja web ou mobile, a maioria dos serviços que recebem usuários é formada por três partes. A comparação com um restaurante é perfeita.

Salão (frontend) é o espaço onde os clientes se sentam: cardápio, mesas e decoração. Tudo o que eles veem e tocam diretamente. No app, botões, campos de entrada e transições de tela ficam aqui.

Cozinha (backend) é o espaço que os clientes não veem. É onde o pedido vira comida, e onde ficam segredos comerciais como receitas e controle de ingredientes. No app, processa login, pagamentos e verificação de permissões.

Depósito (banco de dados, DB) é onde os ingredientes ficam guardados. Mesmo que a cozinha pegue fogo e feche, os ingredientes do depósito continuam lá. No app, é onde ficam armazenados os dados de usuários, posts e pedidos.

Quando o cliente (usuário) faz um pedido pelo cardápio (frontend), o pedido chega à cozinha (backend), que pega ingredientes no depósito, cozinha (consulta o DB) e envia para o salão. Essa ida e volta acontece toda vez que você atualiza o Instagram.

O frontend é executado no dispositivo do usuário

A característica mais importante do frontend é onde ele é executado. O código frontend é executado no navegador (ou celular) do usuário, não no seu servidor. Ao acessar um site, o código é enviado ao dispositivo, que o executa e desenha a tela.

Aqui está uma conclusão essencial para quem faz vibe coding: qualquer pessoa pode abrir e ver o código frontend. No navegador, clique com o botão direito e selecione “Inspecionar” para ver o código frontend do site atual. Não há exceções, nem Naver nem Toss. Ele foi projetado assim, e não há como impedir.

Por isso, não se pode guardar segredos no frontend. Colocar ali uma API key, a senha de administrador ou a lógica de validação de pagamentos equivale a torná-los públicos no mundo todo. Ao pedir código à IA, ela pode inserir esses valores no frontend por conveniência. Se você fizer deploy sem perceber, sua API key pode ser roubada e gerar uma conta enorme. Trataremos disso em detalhes na parte 2.

O backend é executado no meu servidor

O backend, por outro lado, é executado no servidor que eu gerencio. O usuário não pode ver seu código; só pode enviar “requisições” e receber “respostas”. É como um cliente que não entra na cozinha e apenas entrega o pedido.

Por isso, tudo o que é importante deve ser feito no backend.

• Armazenar segredos: API keys e dados de acesso ao DB devem ficar apenas no backend.
• Verificar permissões: a pergunta “este usuário tem permissão para excluir este post?” deve ser respondida no backend. Esconder o botão de excluir no frontend é apenas decoração: qualquer pessoa pode enviar a requisição mesmo sem ver o botão.
• Pagamentos e cálculos: se o preço for calculado no frontend e você confiar no resultado, o usuário poderá manipular a requisição e pagar 1 won.

Em resumo: o frontend mostra; o backend decide. As verificações no frontend orientam o usuário, mas a segurança e as decisões reais são responsabilidade do backend.

O DB é onde os dados realmente vivem

Se você já pensou “apaguei e fiz deploy do app de novo, mas os usuários continuam aqui”, é porque os dados vivem no DB, não no app. O app (frontend + backend) é a equipe; o DB é o cofre. Mesmo trocando toda a equipe, o conteúdo do cofre permanece.

Supabase e Firebase, muito usados em vibe coding, são serviços que administram esse DB para você. Daí surgem estas diferenças:

• Mesmo alterando o código e fazendo deploy novamente → os dados estão seguros.
• Se você resetar o DB → mesmo com o código intacto, todos os dados desaparecem.

É por isso que reverter o código e recuperar os dados são problemas totalmente diferentes quando você quer “desfazer algo”. O código volta com Git (veremos na parte 3), e os dados voltam com um backup do DB. Reverter um não reverte o outro.

O que é cada coisa no meu projeto

Agora vamos aplicar os conceitos à pasta do projeto. Ao abrir um projeto criado pela IA, há muitas pastas, mas os nomes permitem distingui-las aproximadamente. Em um projeto Next.js, o caso mais comum no vibe coding, funciona assim:

• app/ ou pages/, components/ → é o frontend que desenha as telas. Se quiser mudar o texto de um botão, procure aqui.
• A pasta app/api/ ou um arquivo que tenha "use server" no topo → é o backend. Ele está no mesmo projeto, mas é executado no servidor.
• O arquivo .env → é o cofre de segredos usado pelo backend. API keys e dados de acesso ao DB ficam aqui.
• O DB normalmente não fica dentro da pasta do projeto. É um espaço separado, visível ao fazer login no site ou dashboard do Supabase ou Firebase.

Há um ponto importante: ferramentas modernas como Next.js misturam frontend e backend em uma única pasta de projeto. Uma pasta só não significa que tudo é executado no mesmo lugar. Alguns arquivos são enviados ao navegador do usuário; outros permanecem apenas no servidor. Se isso confundir, pergunte à IA: “este arquivo é executado no navegador do usuário ou no servidor?”. Essa pergunta define onde os segredos devem ficar.

O que muda quando você tem esse mapa

Entender a estrutura muda três coisas imediatamente.

Primeiro, você sabe onde olhar quando surgir um erro. Se a tela estiver estranha, veja o console das ferramentas de desenvolvedor do navegador (o grito do frontend); se algo não salvar ou o login falhar, veja os logs do servidor (o grito do backend). Ao perguntar à IA, “este erro aparece no console do navegador” e “este erro aparece nos logs do servidor” são pistas completamente diferentes. Só essa distinção já melhora muito o diagnóstico da IA.

Segundo, você evita metade dos incidentes de segurança. Segredos no backend e permissões verificadas no backend. Seguir apenas esse princípio evita boa parte dos incidentes de segurança causados por vibe coding.

Terceiro, suas instruções para a IA ficam mais precisas. “Dá erro quando clico no botão Salvar” é muito menos útil que “parece que a chamada à API do backend falha quando clico no botão; verifique o código do servidor”. Quem tem o mapa faz perguntas diferentes.

Resumo

• Um app é um restaurante formado por salão (frontend), cozinha (backend) e depósito (DB).
• O frontend é executado no dispositivo do usuário e qualquer pessoa pode ver seu código, portanto não se deve guardar segredos ali.
• O backend é executado no meu servidor, e decisões como guardar segredos, verificar permissões e processar pagamentos são tomadas todas ali.
• O DB é separado do app: os dados permanecem mesmo que você troque todo o código, mas desaparecem se apagar o DB.
• Se ficar em dúvida, pergunte à IA: “este código é executado no navegador ou no servidor?”.

Na próxima parte, trataremos do tema que mais causa incidentes nessa estrutura: APIs e API keys. Vamos explicar por que todos dizem para escondê-las, o que realmente acontece quando são expostas e como verificar se a key do seu projeto está segura.