Como uma requisição flui

Agora vamos amarrar tudo. Vamos acompanhar nosso usuário clicando em "Salvar perfil" através de cada peça que você acabou de conhecer. Este é o modelo mental mais útil de todo o livro; se você internalizar apenas um diagrama, que seja este.

1. USER clicks "Save profile"
        │
        ▼
2. FRONTEND (HTML form, JavaScript reads the values)
        │   sends an HTTP request:  "POST /profile  { name: 'Ada' }"
        ▼
3. HOSTING routes the request to your running BACKEND
        │
        ▼
4. BACKEND
     ├─ is this user logged in?        (no  → respond 401, stop)
     ├─ is the data valid?             (no  → respond 400, stop)
     └─ all good → save to the DATABASE
        │
        ▼
5. DATABASE writes the row, confirms back to the BACKEND
        │
        ▼
6. BACKEND responds:  "200 OK  { saved: true }"
        │
        ▼
7. FRONTEND receives the response, updates the DOM
        │   ("Profile saved ✓") — the user sees it
        ▼
   DONE

Percorra o que cada camada fez: o frontend coletou a entrada e a enviou; a hospedagem levou a requisição até o lugar certo; o backend aplicou as regras (login, validação) e decidiu; o banco de dados tornou tudo permanente; e a resposta fluiu de volta até que o frontend pudesse atualizar a tela. Todo app é uma variação desse ciclo, executado milhares de vezes por segundo.

Repare que todas as verificações acontecem no backend, nunca no frontend — a regra da primeira seção, em ação: o frontend é para o usuário, o backend é para a verdade. Quando você sabe onde cada etapa acontece, você consegue descrever uma funcionalidade com precisão ("valide o e-mail no backend antes de salvar") em vez de vagamente ("faça o formulário funcionar") — e precisão é o jogo inteiro.