Sobre
Turmas
Projetos
Time
Materiais
Artigos
Aulas
PT
EN
Materiais
Materiais
· Backend
2. Modelo Mental de Backend
Visão geral do que significa o 'backend'
33 min de leitura
→
Anterior
1. Introdução
Próximo
2. Fundamentos de Redes para APIs
→
Nesta página
2.1. Cliente–Servidor: responsabilidades e limites
O que é cliente e o que é servidor
Cliente
Servidor
Responsabilidades: o que pertence a cada lado
Responsabilidades do cliente
Responsabilidades do servidor
Limites do modelo cliente–servidor
1) A rede falha
2) O cliente não é confiável
3) Estado não “vem de graça”
4) No fluxo tradicional, o servidor responde a pedidos
Exemplo guiado: inscrição no Trilha
Cenário
Fluxo (passo a passo)
O que fica no cliente (e por quê)
O que fica no servidor (e por quê)
Três resultados comuns (o que o cliente deve mostrar)
(1) Sucesso
(2) Erro de validação
(3) Conflito / duplicidade
Checklist rápido (para você revisar seu próprio entendimento)
Fontes (para leitura)
2.2. Onde o backend roda (processo, porta, host)
O que significa quando o backend está rodando
Processo
Servidor pode significar duas coisas
Host e porta: onde o processo “escuta”
Porta
Host
Como ler host e porta em um endereço
Limites e problemas clássicos (que você vai ver na prática)
1) “Abri no navegador e não carregou”
2) “Porta já está em uso”
3) “Funciona no meu PC, mas não no celular (mesma rede)”
4) “Eu confundi máquina com programa servidor”
Exemplo na prática
Cenário
O que você espera ver quando sobe o backend
Testando no navegador (mesma máquina)
Checklist rápido (para depurar sem sofrer)
Fontes (para leitura)
2.3. Backend como produto: API como contrato
O que significa API ser um contrato
O que um contrato normalmente inclui
Por que isso é importante
Backend como produto
Características de um backend que se comporta como produto
Limites e problemas clássicos (quando o contrato não existe ou não é respeitado)
1) Mudanças quebram clientes
2) Erros viram adivinhação
3) Acoplamento indevido com detalhes internos
4) Falta de estratégia de evolução
Exemplo guiado: API de catálogo de cursos
Cenário
Parte 1: contrato de resposta previsível
Parte 2: contrato de erro consistente
Parte 3: evolução do contrato sem quebrar o cliente
Checklist rápido (para revisar se sua API está sendo tratada como contrato)
Fontes
2.4. Separação entre transporte, regra de negócio e persistência
O que é cada parte na prática
Transporte
Regra de negócio
Persistência
Por que separar melhora o seu backend
1) Você evita duplicar regra
2) Você testa com menos esforço
3) Você reduz acoplamento com o banco
4) Você deixa o código mais legível para iniciantes
Limites e problemas clássicos (quando tudo fica misturado)
1) Rotas viram um bloco gigante
2) Mudanças simples ficam arriscadas
3) Você não consegue reaproveitar lógica
Exemplo: criar uma inscrição para um evento
Visão geral do fluxo
1) Transporte: a rota só traduz HTTP para uma chamada interna
2) Regra de negócio: o service decide o que pode acontecer
3) Persistência: o repository esconde o armazenamento
O que você deve observar neste exemplo
Checklist rápido (para revisar sua separação)
Fontes
2.5. Arquitetura em camadas (visão conceitual)
O que é arquitetura em camadas
O problema que isso resolve
1) Mudança segura
2) Testes mais fáceis
3) Código mais legível para iniciantes e para o time
O erro mais comum: camadas só de pasta
Exemplo: reserva de sala de estudos
Cenário
Visão do fluxo por camadas
Camada 1: transporte (handler)
Camada 2: aplicação (caso de uso)
Camada 3: domínio (regras)
Camada 4: infraestrutura (repositório)
Resultado prático
Checklist rápido
Fontes (para leitura)
2.6. Anti-padrões comuns em backend iniciante
Anti-padrões mais comuns e como evitar
1) Confiar no cliente como se ele fosse sempre correto
2) Colocar regra de negócio dentro da rota HTTP
3) Erros inconsistentes e difíceis de tratar
4) Usar status code como enfeite
5) Expor detalhes internos na resposta
6) Rotas e nomes sem padrão
7) Falta de limites básicos e de comportamento defensivo
Exemplo: criação de usuário com erros previsíveis
Versão ruim: tudo misturado e sem padrão
Versão melhor: separação + contrato de erro estável
1) Formato de erro padronizado
2) Transporte: handler fino, só orquestra HTTP
3) Regra de negócio: decisões centralizadas
4) Persistência: detalhes escondidos
Checklist rápido
Fontes (para leitura)