Frontend, backend e API: entenda como um sistema web funciona

Um clique no navegador pode atravessar interface, rede, regras de negócio, banco de dados e integrações antes de retornar uma resposta.

O que acontece depois que alguém clica em “Confirmar pedido” Para entender frontend, backend, API e banco de dados, acompanhe uma única ação. Uma pessoa revisa um carrinho e seleciona Confirmar pedido . Em poucos instantes, a tela exibe: Pedido criado com sucesso. Entre o clique e a mensagem, várias partes cooperaram. Essas partes podem estar no mesmo projeto, em processos separados ou distribuídas por vários serviços. Os nomes descrevem responsabilidades, não produtos específicos. Frontend: a parte executada na interface Frontend é a camada com a qual a pessoa interage diretamente. Na Web, ela normalmente envolve: HTML para estrutura; CSS para apresentação; JavaScript para comportamento; imagens, fontes e outros recursos; código executado pelo navegador. O frontend apresenta dados, recebe entradas e comunica estados. No exemplo do pedido, ele pode: 1. exibir itens; 2. calcular uma estimativa visual; 3. validar campos básicos; 4. desabilitar o botão durante o envio; 5. enviar a solicitação; 6. mostrar sucesso ou erro. Um frontend não precisa ser uma aplicação JavaScript complexa. Páginas renderizadas no servidor também possuem frontend: o HTML e o CSS que chegam ao navegador continuam formando a interface. O frontend não deve ser a autoridade final O navegador está sob controle do usuário. Requisições podem ser alteradas e scripts podem ser contornados. Por isso, o frontend pode informar que a quantidade mínima é um, mas o backend precisa validar novamente. Pode esconder um botão de administrador, mas o servidor deve bloquear a ação para usuários sem permissão. Ocultar não é autorizar. HTTP: a conversa entre cliente e servidor A MDN descreve HTTP como o protocolo de aplicação usado para buscar recursos e trocar mensagens em um modelo cliente servidor. As solicitações são iniciadas pelo cliente, geralmente o navegador, e recebem respostas. Uma requisição simplificada poderia ser: O servidor poderia responder: A RFC 9110 define a semântica de métodos, campos, códigos de status e outros elementos compartilhados pelas versões de HTTP. Alguns métodos comuns: Método Intenção típica GET Obter uma representação POST Processar dados ou criar um recurso PUT Criar ou substituir uma representação PATCH Alterar parcialmente DELETE Solicitar remoção Os nomes não garantem comportamento correto. A aplicação precisa implementar a semântica adequadamente. API: o contrato de comunicação API significa Application Programming Interface , ou interface de programação de aplicações. Em um sistema web, a API define como clientes podem pedir dados ou ações ao servidor. Ela especifica, por exemplo: URLs; métodos; autenticação; campos aceitos; formatos; regras; códigos de status; mensagens de erro; paginação; limites; versionamento. A API não é necessariamente um servidor separado. Pode ser uma parte do backend. Também não é sinônimo de REST. Existem APIs baseadas em REST, GraphQL, RPC, eventos, mensagens e outros modelos. Um contrato útil precisa prever falhas Pedido válido: Pedido inválido: Uma resposta de erro compreensível poderia ser: O artigo sobre API REST bem desenhada aprofunda contratos, paginação, autorização e evolução. Backend: as regras que não podem depender da tela Backend é o código executado no lado do servidor. No pedido, ele pode: 1. identificar o usuário; 2. verificar autorização; 3. validar o endereço; 4. buscar os produtos; 5. consultar estoque; 6. recalcular preços; 7. aplicar descontos permitidos; 8. registrar o pedido; 9. reservar itens; 10. iniciar pagamento; 11. emitir eventos; 12. retornar uma resposta. Observe que o backend recalcula o total. O valor apresentado pelo frontend não deve ser aceito como verdade. Uma requisição maliciosa poderia enviar: O backend deve ignorar o preço enviado pelo cliente e consultar a fonte autorizada. Banco de dados: persistência e consistência O banco armazena informações que precisam continuar existindo depois que a requisição termina. Exemplos: usuários; produtos; pedidos; pagamentos; permissões; sessões; logs de negócio. Ele não deveria ser acessado diretamente pelo navegador em uma arquitetura tradicional. O backend controla consultas e aplica regras. Transações evitam estados parciais Criar um pedido pode exigir várias alterações: 1. inserir o pedido; 2. inserir itens; 3. reservar estoque; 4. registrar histórico. Se a terceira etapa falhar, não é desejável manter metade da operação. A documentação de transações do PostgreSQL explica que uma transação agrupa múltiplas etapas em uma operação de tudo ou nada: ou todas são confirmadas, ou nenhuma produz efeito persistente. Exemplo simplificado: O exemplo é didático. Um sistema real precisa verificar se o UPDATE afetou a quantidade esperada, tratar concorrência e definir isolamento apropriado. Autenticação e autorização atravessam o fluxo Considere um token enviado pelo frontend. O backend precisa verificar: assinatura ou validade; expiração; emissor; público; revogação quando aplicável; permissões; relação entre identidade e recurso. Uma pessoa pode estar autenticada e ainda assim não ter permissão para consultar o pedido de outra. A proteção em várias camadas é tratada no artigo sobre segurança de site. Serviços externos: o sistema não termina no próprio servidor O backend pode depender de: gateway de pagamento; serviço de e mail; transportadora; estoque; CRM; antifraude; armazenamento; autenticação externa. Esses serviços introduzem latência e falhas. Se a criação do pedido depende de um e mail e o provedor estiver indisponível, o pedido deveria falhar? Normalmente não. O sistema pode registrar o pedido e enfileirar a notificação para nova tentativa. Esse desenho desacopla tarefas, mas acrescenta componentes, monitoramento e tratamento de duplicidade. Não use filas apenas porque parecem uma arquitetura avançada. A arquitetura web sem complexidade desnecessária deve acompanhar escala, risco e capacidade da equipe. O que a pessoa vê quando algo falha Uma interface precisa traduzir falhas técnicas em estados compreensíveis. Erro de validação Selecione um endereço antes de continuar. Sessão expirada Sua sessão expirou. Entre novamente para concluir o pedido. Estoque alterado Um item não possui mais a quantidade solicitada. Revise o carrinho. Serviço temporariamente indisponível Não foi possível concluir agora. Nenhuma cobrança foi realizada. Tente novamente. Não exponha: stack trace; consulta SQL; caminho de arquivo; token; endereço interno; nome de serviço; segredo; detalhes que facilitem exploração. O servidor deve registrar contexto técnico suficiente para investigação, com cuidado para não gravar dados sensíveis desnecessários. O percurso da resposta Quando tudo funciona: O tempo percebido pela pessoa inclui várias parcelas: O artigo sobre performance web mostra como medir em vez de supor onde está a lentidão. Quem testa o quê Camada Exemplos de teste Frontend componentes, estados, teclado, comportamento responsivo API contrato, autenticação, validação, status e compatibilidade Backend regras de negócio, autorização, erros e idempotência Banco consultas, constraints, transações e migrações Integrações timeout, falhas, repetição e respostas inesperadas Fluxo completo criação real de pedido do início ao fim Uma estratégia equilibrada é detalhada em testes web orientados por risco. Cinco confusões frequentes “Frontend é só aparência” Frontend também gerencia interação, estado, acessibilidade, carregamento e comunicação. Ele não deve, porém, concentrar regras que precisam ser protegidas. “Backend é o banco” Backend usa o banco, mas também aplica regras, autentica, autoriza, integra serviços e produz respostas. “API é qualquer URL” Uma API é um contrato. Uma URL sem semântica, documentação e tratamento consistente produz acoplamento e erros. “JavaScript é obrigatório para todo site” Sites estáticos, páginas renderizadas no servidor e formulários tradicionais continuam válidos. A tecnologia deve acompanhar a interação necessária. “Separar tudo melhora a arquitetura” Separação cria fronteiras, chamadas de rede, observabilidade e operação adicionais. Um sistema modular no mesmo processo pode ser melhor do que vários serviços prematuros. A definição mais curta Frontend apresenta e recebe interação. API define como sistemas conversam. Backend aplica regras e coordena operações. Banco de dados mantém estado persistente. Um sistema web funciona quando essas partes possuem responsabilidades claras, contratos verificáveis e tratamento explícito para falhas.