Solução 04 - Documentação e Mocks 📝
Navegação
← Exercício 04 | Próxima Solução →
🟢 Respostas Fáceis
1. OpenAPI vs Swagger - Conceptuação
Resposta 1
OpenAPI vs Swagger:
- **OpenAPI**: É a **especificação/padrão** para documentar APIs REST (formato YAML/JSON)
- **Swagger**: É o **conjunto de ferramentas** que implementa OpenAPI
**🔄 Analogia:**
- **OpenAPI** = "Manual de instruções" (especificação)
- **Swagger** = "Kit de ferramentas" para ler/criar manuais
**🛠️ Ferramentas Swagger:**
- **Swagger Editor**: Escrever especificações
- **Swagger UI**: Visualizar documentação interativa
- **Swagger Codegen**: Gerar código automaticamente
**📚 Evolução Histórica:**
```mermaid
timeline
title Evolução OpenAPI/Swagger
2011 : Swagger nasce
: Especificação proprietária
2015 : Swagger 2.0
: Ganha popularidade
2017 : OpenAPI 3.0
: Swagger doa especificação para Linux Foundation
: Vira padrão aberto
2024 : OpenAPI 3.1
: Padrão consolidado na indústria
```
2. Mock Server - Necessidade do Frontend
Resposta 2
Por que Frontend usa Mock Server:
**🎯 Independência de Desenvolvimento:**
- **Não espera** o Backend ficar pronto
- **Simula respostas** das APIs futuras
- **Testa diferentes cenários** (sucesso, erro, loading)
**🧪 Cenários de Teste:**
- **Resposta lenta** (simular loading)
- **Erro 500** (simular falha do servidor)
- **Dados vazios** (simular lista vazia)
- **Token expirado** (simular logout forçado)
**📈 Benefícios:**
- **Produtividade**: Desenvolve sem esperar Backend
- **Qualidade**: Testa edge cases
- **Demos**: Apresenta para clientes/stakeholders
🟡 Respostas Médias
3. Análise YAML OpenAPI
Resposta 3
Análise do trecho OpenAPI: yaml /usuarios/{id}: # ← ENDPOINT: /usuarios/{id} get: # ← VERBO: GET summary: Busca usuário por ID responses: '200': # ← RETORNO: Status 200 description: Usuário encontrado
**📋 Respostas:**
- **Endpoint**: `/usuarios/{id}` (onde `{id}` é path parameter)
- **Verbo HTTP**: `GET`
- **Retorno no sucesso**: Status **200** com descrição "Usuário encontrado"
**⚠️ Problema**: Falta definir **o que** retorna (schema, exemplo)
4. Developer Experience (DX) - Documentação Ruim
Resposta 4
Por que "POST /login - Envie os dados do usuário" é documentação ruim:
**🔍 Problemas de DX:**
| ❌ O que falta | 🤔 Perguntas que surgem |
|---------------|------------------------|
| **Formato dos dados** | JSON? XML? FormData? |
| **Campos obrigatórios** | Quais campos enviar? |
| **Validações** | CPF? E-mail? Tamanho mín/máx? |
| **Respostas possíveis** | Status codes? Formato retorno? |
| **Autenticação** | Como usar o token recebido? |
| **Erros** | Códigos de erro e mensagens? |
**📝 Documentação Ideal:**
```yaml
/login:
post:
summary: Autentica usuário no sistema
requestBody:
content:
application/json:
schema:
properties:
email: { type: string, format: email }
senha: { type: string, minLength: 6 }
required: [email, senha]
example:
email: "joao@example.com"
senha: "minhasenha123"
responses:
'200':
description: Login realizado com sucesso
content:
application/json:
schema:
properties:
token: { type: string }
expires_in: { type: integer }
'401':
description: Credenciais inválidas
```
🔴 Resposta Desafio
5. Cenário de Desenvolvimento com Mocks
Resposta 5
🏗️ Organização do Trabalho:
**Semana 1-3: Desenvolvimento Paralelo**
```mermaid
gantt
title Cronograma Desenvolvimento com Mocks
dateFormat X
axisFormat %s
section Frontend
Setup Mock Server :0, 1
Telas + Integração Mock :1, 7
Refinamento UX :7, 14
Testes E2E :14, 21
section Backend
Modelagem Banco :0, 7
APIs + Business Logic :7, 14
Testes + Deploy :14, 21
section Integração
Troca Mock→Real :21, 22
Testes Integração :22, 23
```
**📋 Estratégia Detalhada:**
**1️⃣ Definição do Contrato (Dia 1):**
- **OpenAPI Spec** completa definida em conjunto
- **Exemplos** de requests/responses documentados
- **Cenários de erro** mapeados
**2️⃣ Setup do Mock (Dia 1):**
- Mock Server reproduz **exatamente** a especificação
- **URLs idênticas** ao ambiente real
- **Latência simulada** para realismo
**3️⃣ Desenvolvimento Frontend (Semanas 1-3):**
```javascript
// Frontend aponta para Mock inicialmente
const API_BASE = process.env.NODE_ENV === 'development'
? 'http://localhost:3001' // Mock Server
: 'https://api.producao.com'; // Backend Real
// Código permanece idêntico independente do servidor
const login = async (email, senha) => {
const response = await fetch(`${API_BASE}/login`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ email, senha })
});
return response.json();
};
```
**4️⃣ Transição Seamless (Semana 4):**
**✅ Zero Mudanças no Código:**
```bash
# Apenas mudança na variável de ambiente
NODE_ENV=production npm start
```
**🧪 Validação do Contrato:**
```javascript
// Testes garantem compatibilidade
describe('API Contract', () => {
it('Login retorna token e expires_in', async () => {
const response = await login('test@email.com', 'senha123');
expect(response).toHaveProperty('token');
expect(response).toHaveProperty('expires_in');
expect(typeof response.token).toBe('string');
});
});
```
**🛠️ Ferramentas Recomendadas:**
**1. json-server** - **Mais Simples**:
```bash
npm install -g json-server
json-server --watch db.json --port 3001
```
```json
{
"usuarios": [
{"id": 1, "nome": "João", "email": "joao@email.com"}
]
}
```
**2. MSW (Mock Service Worker)** - **Mais Profissional**:
```javascript
import { rest } from 'msw';
const handlers = [
rest.post('/login', (req, res, ctx) => {
const { email, senha } = req.body;
if (email === 'admin@teste.com' && senha === 'admin123') {
return res(
ctx.status(200),
ctx.json({
token: 'fake-jwt-token-12345',
expires_in: 3600
})
);
}
return res(
ctx.status(401),
ctx.json({ erro: 'Credenciais inválidas' })
);
})
];
```
**3. Prism** - **OpenAPI Nativo**:
```bash
npm install -g @stoplight/prism-cli
prism mock api-spec.yaml
```
**📊 Benefícios da Abordagem:**
```mermaid
graph TD
A[Definição Contrato OpenAPI] --> B[Mock Server]
A --> C[Backend Real]
B --> D[Desenvolvimento Frontend]
C --> D
D --> E[Código Único]
E --> F[Zero Refactor na Integração]
B --> G[Testes de Cenários]
G --> H[Maior Qualidade]
style A fill:#e1f5fe
style E fill:#c8e6c9
style F fill:#c8e6c9
```
Script de Automação Completa
```bash
!/bin/bash # setup-mock-environment.sh
echo "🚀 Configurando ambiente Mock..."
# 1. Instalar dependências
npm install -g json-server @stoplight/prism-cli
# 2. Criar estrutura de arquivos
mkdir -p mock/{data,specs}
# 3. Gerar dados fake a partir da OpenAPI
prism mock api-spec.yaml --port 3001 &
# 4. Configurar Frontend para ambiente dev
echo "REACT_APP_API_URL=http://localhost:3001" > .env.development
echo "✅ Mock Server rodando em http://localhost:3001"
echo "✅ Frontend configurado para usar Mock"
echo "🎯 Desenvolvimento pode começar!"
```
!!! tip "Dicas para Próximos Estudos" - Pratique criando OpenAPI specs com Swagger Editor - Configure Contract Testing com Pact ou similares - Implemente versionamento semântico em suas APIs - Use Schema validation no Backend para manter contratos
Navegação