Frontend, backend, banco de dados, hospedagem
Vamos descer mais um nível, usando nosso exemplo: um usuário clica em "Salvar perfil."
. O app visível, rodando em um navegador web ou como um aplicativo de celular. Ele desenha o formulário, percebe o clique e coleta o que o usuário digitou. Por design, ele é não confiável: qualquer pessoa pode abri-lo, inspecioná-lo e alterá-lo. Então o trabalho dele é parecer bom e responder rápido, não aplicar nada que realmente importe.
. Quando o botão é clicado, o frontend envia os dados para o backend — código rodando em um servidor. O backend verifica se o usuário está logado, valida os dados ("isso é realmente um endereço de e-mail?"), aplica as regras de negócio e só então salva. É aqui que a confiança mora, porque os usuários não conseguem interferir nisso.
Banco de dados. O backend entrega os dados ao banco de dados para armazená-los. Não é uma caixa mágica — pense nele como um conjunto de planilhas muito rígidas (chamadas tabelas) que podem ser pesquisadas instantaneamente e nunca esquecem nada. Amanhã, o backend lê o perfil de volta do banco para exibi-lo novamente.
Hospedagem. Em produção, nada disso roda no seu notebook. Roda em computadores alugados de um provedor de hospedagem como Cloudflare, Vercel, ou uma plataforma de nuvem. Hospedagem é o que torna seu app acessível em um endereço real na web, em vez de existir apenas na sua própria máquina.
Um instinto útil: quando algo quebra, pergunte em qual camada. "O botão não faz nada" é frontend. "Ele salva a coisa errada" geralmente é backend. "Ele esqueceu meus dados" aponta para o banco de dados. Nomear a camada é metade do caminho para consertar o bug — e metade do caminho para escrever um sobre o qual a IA consiga agir.