Desenvolvimento de APIs e Microsserviços 💻

Domine a criação de arquiteturas modernas de backend com Microsserviços, modelagem RESTful, segurança com JWT e o desenvolvimento de interfaces SPA modernas.

Foco do Curso

Metodologia: Aprendizado prático focado na construção de ecossistemas Fullstack, integrando serviços backend robustos com frontends de alta performance.

🎯 O Que Você Vai Aprender

Microsserviços --- Aprenda a decompor monólitos, gerenciar comunicação entre serviços e utilizar API Gateways para escalabilidade. Ir para Módulo 1
Modelagem RESTful --- Domine endpoints, status codes, documentação com Swagger/OpenAPI e padrões de projeto para APIs profissionais. Ver Modelagem
Autenticação JWT --- Implemente segurança de ponta a ponta com JSON Web Tokens, proteção de rotas e controle de acesso RBAC. Ver Segurança
Frontends SPA --- Integre seu backend com Single Page Applications modernas, explorando componentes, estados e roteamento dinâmico. Ver Projetos

📚 Jornada de Aprendizado (16 Aulas)

O curso é estruturado em quatro trilhas de especialização.

Plano de Ensino 📅

Curso: Desenvolvimento de APIs e Microsserviços (Backend & Frontend SPA)

Ementa

Módulo 1: Serviços e Microsserviços: Conceitos, arquitetura distribuída, modelagem REST e documentação (OpenAPI).
Módulo 2: Manipulação de Dados: Implementação backend, CRUD, persistência com ORM e testes unitários/integrados.
Módulo 3: Autenticação e Autorização: Estratégias Web, JWT, proteção de rotas e segurança RBAC.
Módulo 4: Aplicações Web SPA: Conceito de SPA, componentização, gerenciamento de estado, roteamento e integração final.

Cronograma (16 Aulas)

Módulo 1: Serviços e Microsserviços

Aula 01: Introdução a Serviços e Microsserviços
Aula 02: Arquitetura de Microsserviços e API Gateway
Aula 03: Modelagem de APIs RESTful
Aula 04: Documentação (Swagger) e Mock de APIs

Módulo 2: Manipulação de Dados via APIs REST

Aula 05: Implementação de APIs (Controllers/Services/Rep)
Aula 06: Persistência e Integração com Banco de Dados
Aula 07: Testes Unitários com Mocks
Aula 08: Testes Integrados e Build da Aplicação

Módulo 3: Autenticação e Autorização

Aula 09: Estratégias Web (Sessions, Cookies, Tokens)
Aula 10: Autenticação para APIs com JWT
Aula 11: Autorização e Controle de Acesso (RBAC)

Módulo 4: Aplicações Web SPA

Aula 12: Conceito de SPA e Estrutura de Projeto
Aula 13: Componentes e Templates
Aula 14: Gerenciamento de Estados e Eventos
Aula 15: Roteamento e Navegação Dinâmica
Aula 16: Formulários, Integração e Projeto Final

Avaliação

Exercícios: 16 listas de exercícios teóricos e práticos.
Projetos: 16 mini-projetos práticos de fixação.
Quizzes: 16 testes de conhecimento imediato.
Projeto Integrador: Desenvolvimento de uma aplicação Fullstack (API + SPA) para portfólio.

Aulas

Aula 01 - Introdução a Serviços e Microsserviços 🌐

Objetivo

Objetivo: Compreender a evolução das arquiteturas de software, diferenciar Monólitos de Microsserviços e entender o papel das APIs no ecossistema moderno de desenvolvimento.

1. O que são Serviços e Microsserviços? 🧩

No desenvolvimento moderno, um serviço é uma unidade funcional que entrega um valor específico (ex: processar um pagamento, enviar um e-mail).

🏛️ O Monólito

Historicamente, sistemas eram construídos como Monólitos: um único bloco de código onde tudo (interface, lógica, banco de dados) está fortemente acoplado.

Vantagens: Simples de desenvolver inicialmente, fácil de testar localmente.
Desvantagens: Difícil de escalar, uma falha em um módulo pode derrubar o sistema todo, barreira tecnológica (difícil mudar a linguagem após o início).

🏗️ Os Microsserviços

A arquitetura de Microsserviços decompõe a aplicação em serviços pequenos, independentes e focados em uma única responsabilidade (Single Responsibility Principle).

Vantagens: Escalabilidade granular, resiliência (isolamento de falhas), liberdade tecnológica (cada serviço pode usar uma linguagem diferente).
Desvantagens: Complexidade operacional, dificuldade em manter a consistência de dados, latência de rede.

2. Comparativo: Monólito vs Microsserviços ⚖️

Característica	🏛️ Monólito	🏗️ Microsserviços
Escalabilidade	Vertical (Aumenta servidor)	Horizontal (Mais instâncias do serviço)
Deploy	Tudo ou nada	Independente por serviço
Falhas	Propagam-se facilmente	Isoladas ao serviço
Tecnologia	Única (Stack fixa)	Poliglota (Mix de linguagens)
Complexidade	Baixa no início, alta no final	Alta desde o início

Visualização de Arquitetura (Mermaid)

graph TD
    subgraph "Arquitetura de Microsserviços"
        Client[Cliente/Web/App] --> AGW[API Gateway]
        AGW --> S1[Serviço de Usuários]
        AGW --> S2[Serviço de Pedidos]
        AGW --> S3[Serviço de Pagamentos]
        S1 --> DB1[(DB Usuários)]
        S2 --> DB2[(DB Pedidos)]
        S3 --> DB3[(DB Pagamentos)]
    end

3. A Economia das APIs 📡

API (Application Programming Interface) é a "ponte" que permite a comunicação entre esses serviços ou entre sistemas diferentes.

REST: O padrão de mercado baseado no protocolo HTTP.
Endpoints: URLs específicas que expõem funcionalidades (ex: GET /produtos).
Contratos: Acordos sobre como os dados devem ser enviados e recebidos (geralmente via JSON).

4. Ferramentas Essenciais 🛠️

Para trabalhar com backend e APIs, você precisará de um "cinto de utilidades" moderno:

Client HTTP (Postman/Insomnia): Para testar endpoints sem precisar de um frontend.
Docker: Para "empacotar" seus serviços e garantir que rodem em qualquer máquina.
Git/GitHub: Para versionamento e colaboração.
Runtime: Node.js, Java (JDK) ou Python (dependendo do projeto).

5. Estrutura de um Projeto Moderno 📂

Diferente de um app mobile, um ecossistema de microsserviços geralmente é organizado em Mono-repos ou Multi-repos.

Visão de Pastas (Padrão Backend)

$ ls -R backend-master
auth-service/ (Nodejs)
├── src/
├── package.json
└── Dockerfile

catalog-service/ (Java/Spring)
├── src/
├── pom.xml
└── Dockerfile

api-gateway/ (Go)
└── main.go

6. Mini-Projeto: Configurando o Cinto de Utilidades 🚀

Sua missão é preparar o ambiente para o desenvolvimento backend:

Instalar o Visual Studio Code (ou IntelliJ CE).
Instalar o Postman ou a extensão Thunder Client no VS Code.
Instalar o Docker Desktop.
Garantir que o Git esteja configurado no seu terminal.

Veja o passo a passo detalhado na seção Configuração > Setup Backend.

7. Exercício de Fixação 🧠

Responda em seu caderno/arquivo de notas:

Explique o conceito de "Escalabilidade Horizontal" no contexto de microsserviços.
Qual a função de um API Gateway em um sistema distribuído?
Por que a consistência de dados é um desafio maior em microsserviços do que em monólitos?

Próxima Aula: Vamos mergulhar na Arquitetura de Microsserviços e API Gateway! 🏗️

Aula 02 - Arquitetura de Microsserviços e API Gateway 🏗️

Objetivo

Objetivo: Entender como múltiplos serviços independentes conversam entre si, o papel vital do API Gateway como porta de entrada e as estratégias de comunicação síncrona e assíncrona.

1. Comunicação entre Serviços 💬

Em um sistema distribuído, os serviços precisam trocar informações. Existem dois modelos principais:

🔄 Comunicação Síncrona (Sync)

O serviço chamador envia uma requisição e espera pela resposta imediata. * Protocolo: Geralmente HTTP/REST ou gRPC. * Exemplo: O serviço de Pedidos chama o serviço de Pagamentos e aguarda a confirmação para finalizar o carrinho. * Pró: Simples de entender e implementar. * Contra: Se o serviço destino estiver lento, todo o sistema fica lento (cascateamento).

📬 Comunicação Assíncrona (Async)

O serviço envia uma mensagem e não espera pela resposta. Ele continua seu trabalho. * Protocolo: Mensageria (RabbitMQ, Kafka, SQS). * Exemplo: O serviço de Pedidos envia um evento "Pedido Criado" para uma fila. O serviço de Logística lê essa fila quando puder. * Pró: Maior resiliência e desacoplamento. * Contra: Complexidade maior (consistência eventual).

2. O Papel do API Gateway 🚪

Em vez de expor todos os microsserviços diretamente para a internet, usamos um API Gateway. Ele atua como uma única porta de entrada para os clientes.

Responsabilidades do Gateway:

Roteamento: Encaminha a requisição para o serviço correto (ex: /users vai para User-Service).
Autenticação: Verifica se o usuário está logado antes de passar a bola para os serviços internos.
Rate Limiting: Impede que um cliente faça requisições demais e derrube o sistema.
Agregação: Pode combinar dados de vários serviços em uma única resposta para o frontend.

3. Service Discovery e Load Balancing 🔍⚖️

Como o Gateway sabe o endereço de cada serviço se eles mudam de IP o tempo todo em containers?

🔎 Service Discovery

É uma agenda dinâmica (ex: Consul, Eureka) onde cada serviço se "registra" ao subir. O Gateway consulta essa agenda para achar o serviço.

⚖️ Load Balancing (Balanceamento de Carga)

Distribui as requisições entre várias instâncias do mesmo serviço para evitar sobrecarga.

graph TD
    Client[Cliente/Mobile] --> Gateway[API Gateway]
    Gateway --> SD{Service Discovery}
    Gateway --> S1[Instância 1 - Pagamento]
    Gateway --> S2[Instância 2 - Pagamento]
    Gateway --> S3[Instância 3 - Pagamento]
    style SD fill:#f9f,stroke:#333,stroke-width:4px

4. Padrões de Resiliência: Circuit Breaker 🔌

Se um serviço está falhando, não adianta continuar mandando requisições para ele. O Circuit Breaker (Disjuntor) "abre o circuito" e retorna um erro imediato ou um dado em cache, evitando que o erro se espalhe.

5. Mini-Projeto: Simulando um Gateway 🚀

Vamos simular o comportamento de um Gateway usando o Postman:

Crie uma Collection chamada "API Gateway Simulation".
Configure variáveis de ambiente para base_url.
Crie rotas que "apontam" para diferentes APIs públicas (ex: JSONPlaceholder para posts e ReqRes para usuários).
Teste como se fosse um único sistema centralizado.

Veja os detalhes práticos em Exercícios > Ex 02.

6. Exercício de Fixação 🧠

Qual a diferença entre um API Gateway e um Load Balancer?
Explique o problema do "Cascateamento de Falhas" em comunicações síncronas.
Em que situação você usaria Kafka ao invés de HTTP para comunicar dois serviços?

Próxima Aula: Vamos colocar a mão na massa com a Modelagem de APIs RESTful! 📡

Aula 03 - Modelagem de APIs RESTful 📡

Objetivo

Objetivo: Dominar os princípios do design REST, aprender a usar corretamente os métodos HTTP, interpretar códigos de status e criar contratos de API profissionais e intuitivos.

1. O que é REST? 🧊

REST (Representational State Transfer) não é uma linguagem nem um framework, mas um estilo arquitetural para sistemas distribuídos.

Princípios Fundamentais:

Client-Server: Separação clara entre quem pede (frontend/mobile) e quem atende (backend).
Stateless: Cada requisição deve conter toda a informação necessária. O servidor não "lembra" do cliente entre chamadas.
Cacheable: As respostas podem (e devem) ser cacheadas para melhorar a performance.
Interface Uniforme: Uso padronizado de recursos, métodos e identificadores (URIs).

2. Recursos e URIs 📍

No REST, tudo é um recurso. Um recurso é qualquer dado que possa ser nomeado (um usuário, um produto, um pedido).

Identificação: Usamos URIs (Uniform Resource Identifiers).
Boas Práticas de Nomeação:
- Use substantivos no plural, nunca verbos.
- GET /produtos ✅ (Bom)
- GET /getTodosProdutos ❌ (Ruim)
- Use hierarquia: GET /clientes/123/pedidos (Pedidos do cliente 123).

3. Verbos (Métodos) HTTP 🛠️

Os verbos dizem ao servidor o que fazer com o recurso:

Verbo	Ação	Idempotente?
GET	Recupera um recurso ou lista.	Sim
POST	Cria um novo recurso.	Não
PUT	Atualiza um recurso inteiro (substituição).	Sim
PATCH	Atualiza apenas parte de um recurso.	Não
DELETE	Remove um recurso.	Sim

O que é Idempotência? Significa que fazer a mesma requisição várias vezes tem o mesmo efeito que fazer uma única vez.

4. Códigos de Status (HTTP Status Codes) 🚦

A resposta do servidor deve vir com um código que indique o que aconteceu:

2xx (Sucesso):
- 200 OK: Deu tudo certo.
- 201 Created: Recurso criado com sucesso (usado no POST).
- 204 No Content: Sucesso, mas não há nada para retornar (usado no DELETE).
4xx (Erro do Cliente):
- 400 Bad Request: Requisição inválida (falta de dados).
- 401 Unauthorized: Falta de autenticação.
- 403 Forbidden: Autenticado, mas sem permissão.
- 404 Not Found: Recurso não existe.
5xx (Erro do Servidor):
- 500 Internal Server Error: O servidor "quebrou".

5. O Formato JSON 🏗️

O JSON (JavaScript Object Notation) é o padrão de facto para troca de dados em APIs REST por ser leve e fácil de ler (por humanos e máquinas).

{
  "id": 123,
  "nome": "Smartphone X",
  "preco": 1500.00,
  "disponivel": true,
  "categorias": ["Eletrônicos", "Ofertas"]
}

6. Mini-Projeto: Desenhando um Contrato ✍️

Imagine que você está criando uma API para uma Biblioteca.

Defina a URI para listar todos os livros.
Defina a URI e o Verbo para cadastrar um novo livro.
Qual Status Code você retornaria se alguém tentasse deletar um livro que não existe?
Desenhe o JSON de um objeto "Livro" com pelo menos 5 campos.

7. Exercício de Fixação 🧠

Diferencie PUT de PATCH com um exemplo prático.
Por que não devemos usar verbos nas URIs (ex: /deletarUsuario/123)?
O que significa uma API ser "Stateless"?

Próxima Aula: Vamos aprender a documentar essas APIs com Swagger e criar Mocks! 📝

Aula 04 - Documentação (Swagger) e Mock de APIs 📝

Objetivo

Objetivo: Compreender a importância da documentação para a Developer Experience (DX), aprender a usar o Swagger/OpenAPI para documentar contratos e entender como os Mocks permitem o desenvolvimento paralelo entre frontend e backend.

1. Por que documentar APIs? 🧐

Uma API sem documentação é como um labirinto no escuro. Se outros desenvolvedores (ou você mesmo no futuro) não souberem como chamar os endpoints, a API é inútil.

Benefícios:

Developer Experience (DX): Facilita o consumo da API por terceiros.
Single Source of Truth: O contrato documentado é a verdade absoluta do sistema.
Redução de Erros: Menos ambiguidades sobre tipos de dados e status codes.
Automação: Permite gerar clientes e testes automaticamente.

2. OpenAPI e Swagger 🛠️

O OpenAPI (antigamente chamado de Swagger) é o padrão mundial para descrever APIs RESTful.

Arquivo YAML/JSON: Um arquivo que descreve rotas, parâmetros, modelos de dados e respostas.
Swagger UI: Uma ferramenta visual que transforma esse arquivo em uma página interativa onde você pode testar a API.

# Exemplo simplificado de OpenAPI
paths:
  /produtos:
    get:
      summary: Lista todos os produtos
      responses:
        '200':
          description: Sucesso

3. O Poder dos Mocks 🎭

O que fazer quando o Frontend precisa de uma API que o Backend ainda não terminou de codificar? Usamos um Mock.

O que é um Mock?

É um servidor "fake" que simula o comportamento da API real. Ele recebe a requisição e retorna um dado estático pré-definido, conforme o contrato.

Ferramentas de Mock:

Swagger Hub: Cria mocks automáticos a partir da documentação.
Mockoon / Prism: Servidores locais para rodar mocks.
Postman Mock Servers: Transforma uma collection em um servidor online.

4. Developer Experience (DX) 🚀

DX é o equivalente ao UX (User Experience), mas focado no programador. Uma API com boa DX possui: * Nomes intuitivos. * Documentação sempre atualizada. * Exemplos de código em várias linguagens. * Mensagens de erro claras (ex: "O campo 'email' é obrigatório" em vez de apenas 400 Bad Request).

5. Estrutura de Documentação Profissional 📂

Uma boa documentação de endpoint deve conter: 1. Título e Descrição: O que o endpoint faz? 2. Parâmetros: Quais dados enviar na URL (Path) ou no Filtro (Query)? 3. Corpo (Body): Qual o esquema do JSON de entrada? 4. Respostas: Quais Status Codes ele retorna e qual o JSON de saída para cada um?

6. Mini-Projeto: Criando Documentação no Swagger 🚀

Vamos criar um pequeno contrato para uma Loja de Games:

Acesse o Editor do Swagger.
Crie um endpoint GET /games que retorna uma lista de objetos.
Adicione um parâmetro de filtro chamado categoria.
Crie o modelo de dados para um Game (id, titulo, plataforma, preco).

7. Exercício de Fixação 🧠

Qual a diferença entre a Especificação OpenAPI e a Ferramenta Swagger?
Como o uso de Mocks pode acelerar o cronograma de um projeto de software?
Por que retornar apenas o Status Code (ex: 400) sem uma mensagem explicativa é considerado uma má prática de DX?

Próxima Aula: Fim do Módulo 1! No Módulo 2, iniciaremos a Implementação de APIs (Controllers/Services/Rep)! 💻

Aula 05 - Implementação de APIs (Controllers e Rotas) ⚙️

Objetivo

Objetivo: Entender a camada de entrada de uma aplicação backend, aprender a mapear rotas para funções específicas e capturar parâmetros de entrada enviados pelo cliente.

1. A Camada de Controller 🎮

O Controller é o "maestro" de uma rota. Sua única responsabilidade é: 1. Receber a requisição HTTP. 2. Validar se os dados básicos estão ali. 3. Chamar a lógica de negócio (que veremos na próxima aula). 4. Retornar a resposta correta (Status Code + JSON).

Analogie: O Controller é o garçom de um restaurante. Ele anota o pedido, leva para a cozinha e traz o prato pronto. Ele não cozinha!

2. Anatomia de uma Rota 📍

Uma rota no backend é composta por: * Endpoint (Path): O caminho (ex: /produtos). * Verbo: A ação (ex: POST). * Handler: A função que será executada quando a rota for chamada.

Exemplo (Conceitual):

// Quando receber um GET em /usuarios, execute a função listarUuarios
router.get('/usuarios', (req, res) => {
    const lista = [{ id: 1, nome: 'Ricardo' }];
    return res.status(200).json(lista);
});

3. Capturando Dados do Cliente 📥

Existem três formas principais de o cliente enviar dados:

Tipo	Onde fica?	Exemplo	Uso Comum
Path Params	Na URL (como parte do caminho)	`/usuarios/123`	Identificar um recurso específico.
Query Params	Na URL (após o `?`)	`/produtos?categoria=games`	Filtros, ordenação e paginação.
Request Body	No "corpo" da mensagem	`{ "nome": "Novo Item" }`	Criação ou atualização (POST/PUT).

4. O Objeto de Resposta (Response) 📤

Não basta retornar os dados, precisamos seguir o contrato REST. O Controller deve garantir: * Status Code Errado: Jamais retorne 200 OK se ocorreu um erro. * Corpo Padronizado: Envie as mensagens de erro dentro de um JSON para facilitar o trabalho do frontend.

5. Injeção de Dependência (Introdutório) 💉

Para que o Controller não tenha que "criar" outras classes, ele as recebe prontas. Isso facilita testes e troca de tecnologias.

6. Mini-Projeto: Dashboard de Usuários 👥

Crie uma rota GET /usuarios.
Crie uma rota POST /usuarios.
Crie uma rota DELETE /usuarios/:id.
Use o Postman para testar se os dados estão sendo recebidos e enviados corretamente.

7. Mini-Projeto: Criando seu primeiro Controller ⌨️

Imagine que você está criando o Controller de um Carrinho de Compras.

Defina a rota para adicionar um item (POST).
Como você capturaria o id do produto vindo no Body?
Crie a rota para remover um item específico (DELETE via Path Param).
Qual o Status Code ideal se o usuário tentar remover um item que não está no carrinho?

7. Exercício de Fixação 🧠

Por que o Controller não deve conter regras de negócio (ex: cálculo de desconto)?
Qual a diferença prática entre usar um Query Param e um Path Param?
O que acontece se um Controller tentar acessar req.body mas o cliente não enviou o header Content-Type: application/json?

Próxima Aula: Vamos tirar a lógica do Controller e levar para o lugar certo: Services e Regras de Negócio 🧠

Aula 06 - Services e Regras de Negócio 🧠

Objetivo

Objetivo: Entender a importância de separar a lógica de negócio da camada de transporte (HTTP), aprender a criar Services reutilizáveis e tratar erros de forma elegante.

1. Por que usar Services? 🏗️

Na aula anterior, aprendemos que o Controller é como um garçom. Ele não deve "cozinhar" (fazer cálculos ou validar regras complexas).

Se você colocar toda a lógica no Controller: 1. Código Duplicado: Se precisar da mesma lógica em outra rota, terá que copiar o código. 2. Difícil de Testar: Testar lógica misturada com HTTP é muito mais complexo. 3. Bagunça: O arquivo do Controller fica gigante e impossível de ler.

2. A Responsabilidade do Service ⚖️

O Service contém a Regra de Negócio. É aqui que o "cérebro" da aplicação reside.

O que o Service faz: * Valida se um usuário pode realizar uma ação (ex: "tem saldo suficiente?"). * Realiza cálculos (ex: "qual o valor do desconto progressivo?"). * Transforma dados antes de salvar (ex: "criptografar a senha"). * Lança erros claros quando algo dá errado.

3. O Fluxo de Execução 🌊

Cliente faz o REQUEST.
Controller captura os dados e chama o Service.
Service processa a lógica e retorna o resultado (ou erro).
Controller recebe o retorno e envia o RESPONSE para o cliente.

4. Tratamento de Erros Profissional ⚠️

Services não devem se preocupar com Status Codes (isso é coisa do Controller). O Service deve apenas avisar que algo falhou.

// Exemplo no Service
if (usuarioExiste) {
    throw new Error("E-mail já cadastrado"); // Lança uma exceção
}

O Controller, então, captura esse erro e "traduz" para o HTTP:

// No Controller
try {
    await service.cadastrar(dados);
} catch (erro) {
    return res.status(400).json({ mensagem: erro.message });
}

5. ViewModels e DTOs (Data Transfer Objects) 📦

Muitas vezes, não queremos devolver todos os dados do banco para o cliente (ex: não queremos devolver a senha!). Usamos DTOs para filtrar o que entra e o que sai do sistema.

🆚 Comparação: MVVM (Mobile/Frontend)

Se você já ouviu falar de MVVM, o Service no Backend é muito similar ao papel do ViewModel no Frontend: ambos lidam com a lógica e os dados, deixando a "View" (ou Controller) limpa de complexidade.

6. Mini-Projeto: Refatorando para Service 🛠️

Imagine o sistema de Transferência Bancária. 1. Crie a função transferir(origem, destino, valor) no Service. 2. Quais validações você faria antes de confirmar a transferência? (Saldo, conta ativa, valores negativos...). 3. Simule o lançamento de um erro caso o saldo seja insuficiente.

7. Exercício de Fixação 🧠

O que acontece com a manutenção do sistema se um Service for reaproveitado por dois Controllers diferentes?
Por que o Service não deve saber que o req e o res do Express existem?
Qual a vantagem de "limpar" os dados (DTO) antes de enviá-los ao cliente?

Próxima Aula: Onde guardamos esses dados? Repositories e Banco de Dados (PostgreSQL) 🗄️

Aula 07 - Repositories e Banco de Dados (PostgreSQL) 🗄️

Objetivo

Objetivo: Entender a camada de persistência, aprender os fundamentos de Bancos de Dados Relacionais (SQL) e como o padrão Repository isola o acesso aos dados da lógica de negócio.

1. Onde os dados moram? 🏠

Até agora, se reiniciarmos nosso servidor, todos os dados (usuários, produtos, etc) somem. Para que a informação sobreviva, precisamos de um Banco de Dados.

Neste curso, usaremos o PostgreSQL, um dos bancos relacionais mais robustos e utilizados no mundo backend.

2. Bancos Relacionais vs SQL 📊

Um banco relacional organiza os dados em Tabelas (linhas e colunas), como uma planilha de Excel gigante, mas com "superpoderes" de relacionamento.

O SQL (Structured Query Language) é a linguagem que usamos para falar com o banco.

Comandos Essenciais (CRUD):

CREATE: INSERT INTO tabela (campos) VALUES (valores);
READ: SELECT * FROM tabela WHERE condicao;
UPDATE: UPDATE tabela SET campo = valor WHERE id = 1;
DELETE: DELETE FROM tabela WHERE id = 1;

3. Relacionamentos (O "Relacional") 🔗

O grande poder do SQL é ligar tabelas: * 1:N (Um para Muitos): Um Usuário tem muitos Pedidos. * N:N (Muitos para Muitos): Um Estudante está em muitos Cursos, e um Curso tem muitos Estudantes.

4. O Padrão Repository 📥

Assim como o Controller não deve "cozinhar", o Service não deve saber "falar SQL". O Service pede os dados para o Repository.

Vantagem: Se amanhã decidirmos trocar o PostgreSQL pelo MongoDB ou por um arquivo TXT, só precisamos mudar o Repository. O Service continua igual!

// Exemplo no Repository
async buscarPorId(id) {
    return await db.query("SELECT * FROM usuarios WHERE id = $1", [id]);
}

5. Migrations: O Histórico do Banco 📜

Migrations são arquivos que descrevem as mudanças no banco de dados ao longo do tempo. * "Criar tabela de produtos". * "Adicionar coluna de preço". * "Remover coluna de descrição".

Isso permite que toda a equipe tenha sempre a mesma estrutura de banco.

6. Mini-Projeto: Modelando o Banco 🏗️

Imagine um sistema de Livraria. 1. Quais tabelas seriam necessárias? (Livros, Autores, Vendas). 2. Como você ligaria um Livro ao seu Autor? (Chave Estrangeira - Foreign Key). 3 Escreva o comando SQL para buscar todos os livros que custam menos de R$ 50,00.

7. Exercício de Fixação 🧠

Qual a diferença entre uma Chave Primária (Primary Key) e uma Chave Estrangeira (Foreign Key)?
Por que é perigoso deixar o Service rodar comandos SQL diretamente?
O que acontece se executarmos um DELETE sem a cláusula WHERE? (⚠️ Cuidado!).

Próxima Aula: Como garantir que os dados que entram no banco estão corretos? Boas Práticas e Validação de Dados ✅

Aula 08 - Boas Práticas e Validação de Dados ✅

Objetivo

Objetivo: Aprender a garantir a integridade dos dados que entram no sistema, prevenir ataques comuns e escrever um código backend limpo, sustentável e fácil de manter.

1. Por que validar? 🛡️

O lema de todo desenvolvedor backend deve ser: "Nunca confie nos dados vindos do cliente". O frontend pode ter falhas ou alguém pode tentar burlar a interface e enviar dados maliciosos diretamente para a API.

Validar evita: * Dados Inconsistentes: Um produto sem preço ou um usuário sem e-mail. * Crashes: O servidor tentando processar algo que não existe. * Vulnerabilidades: Como nomes gigantes que quebram o layout ou scripts maliciosos.

2. Validação vs Sanitização 🧼

Validação: Checar se o dado está correto (ex: "Isso é um e-mail válido?", "A idade é maior que 18?").
Sanitização: Limpar o dado (ex: remover espaços em branco extras, remover tags HTML de um comentário).

3. Esquemas de Validação (Zod/Joi) 📐

Em vez de encher o Controller de if (campo == null), usamos bibliotecas de Schema Validation. Definimos um "contrato" e a biblioteca checa tudo para nós.

// Exemplo de esquema (Conceitual)
const usuarioSchema = {
    nome: string().min(3),
    email: string().email(),
    idade: number().min(18)
};

4. Tratamento Global de Erros 🚨

Não devemos colocar try/catch em todas as funções. O ideal é ter um Middleware de Erro que captura qualquer falha inesperada e envia uma resposta padrão para o cliente.

Benefícios:

O código fica limpo.
As mensagens de erro para o cliente são amigáveis.
Você pode logar o erro real no servidor para o time analisar sem expor detalhes sensíveis (como queries SQL) ao usuário final.

5. Clean Code: O Backend Elegante ✨

Nomes Descritivos: buscarUsuarioPorId é melhor que getUs.
Funções Pequenas: Se uma função faz 10 coisas, ela deve ser dividida.
Princípio DRY: Don't Repeat Yourself (Não se repita). Se você usa o mesmo código em dois lugares, ele deve virar uma função ou utilitário.

🆚 Comparação: Clean Architecture no Mobile

Separar as regras de interface da lógica de validação é fundamental. O Clean Code é uma linguagem universal que separa o programador amador do profissional.

6. Mini-Projeto: O Validador de Produtos 🛒

Crie o esquema de validação para o cadastro de um Produto de E-commerce. * nome: Obrigatório, mínimo 5 caracteres. * preco: Obrigatório, deve ser maior que zero. * estoque: Inteiro, não pode ser negativo. * categoria: Deve ser uma das opções: 'Eletrônicos', 'Roupas' ou 'Alimentos'.

7. Exercício de Fixação 🧠

Qual a diferença entre uma falha de validação (erro 400) e um erro inesperado no servidor (erro 500)?
Por que sanitizar o texto de um comentário de usuário antes de salvá-lo no banco?
O que acontece se uma API retornar detalhes técnicos do banco de dados (Stack Trace) em uma mensagem de erro para o cliente? (Dica: pense em segurança).

Próxima Aula: Entrando no Módulo 3! Segurança e Autenticação com JWT 🔐

Aula 09 - Segurança e Autenticação com JWT 🔐

Objetivo

Objetivo: Entender os conceitos de Autenticação e Autorização, aprender como funciona o padrão JWT (JSON Web Token) e como implementar um login seguro e sem estado (stateless).

1. Autenticação vs Autorização 🚦

Embora pareçam iguais, são processos diferentes: * Autenticação: "Quem é você?" (Validar e-mail e senha). * Autorização: "O que você pode fazer?" (Checar se você tem permissão de Admin, por exemplo).

2. O Problema das Sessões (Stateful) 🍪

Antigamente, o servidor guardava uma "sessão" na memória para cada usuário logado. * Problema: Se você tivesse 1 milhão de usuários, a memória do servidor estourava. * Problema 2: Se você tivesse dois servidores, o segundo não conheceria a sessão guardada no primeiro.

3. A Solução: JWT (Stateless) 🎫

O JWT (JSON Web Token) é como um "crachá digital". O servidor não guarda nada na memória. Ele entrega o crachá assinado para o usuário, e o usuário deve apresentar esse crachá em todas as próximas requisições.

Estrutura do JWT:

O token é composto por 3 partes separadas por pontos (.): 1. Header: Tipo do token e algoritmo de criptografia. 2. Payload: Os dados do usuário (ex: id, nome, permissões). Atenção: Não guarde senhas aqui, pois o payload é apenas codificado, não encriptado! 3. Signature: A "assinatura digital" que garante que o token não foi alterado.

Cliente envia e-mail e senha.
Servidor valida os dados no banco.
Servidor gera um JWT usando uma "Chave Secreta" e envia para o cliente.
Cliente armazena o token (geralmente no localStorage).
Cliente envia o token no header Authorization em todas as rotas protegidas.

5. Implementando no Backend ⚡

Usamos bibliotecas como jsonwebtoken para assinar e validar os tokens.

// Gerando o token
const token = jwt.sign({ id: user.id }, 'CHAVE_SUPER_SECRETA', { expiresIn: '1d' });

🆚 Comparação: Keychain / EncryptedSharedPreferences (Mobile)

No Mobile, o JWT deve ser guardado com segurança máxima. * Web: Usamos Cookies (HttpOnly) ou localStorage (com cautela). Nunca guarde o JWT em texto simples no dispositivo!

6. Mini-Projeto: Gerador de Tokens 🛠️

Crie uma função login(email, senha).
Se o e-mail for "admin@teste.com" e a senha "123456", gere um JWT com o payload { role: 'admin' }.
Defina que esse token deve expirar em apenas 1 hora (1h).

7. Exercício de Fixação 🧠

Por que o JWT é chamado de "Stateless" (Sem estado)?
O que acontece se uma pessoa mal-intencionada mudar o role de 'user' para 'admin' dentro do Payload do JWT? Por que a assinatura (Signature) impede isso?
Qual o perigo de usar uma "Chave Secreta" muito Curta ou óbvia (ex: "123")?

Próxima Aula: Como proteger rotas específicas? Controle de Acesso (RBAC) e Permissões 🛡️

Aula 10 - Controle de Acesso (RBAC) e Permissões 🛡️

Objetivo

Objetivo: Aprender a restringir o acesso a partes específicas da aplicação baseando-se no nível do usuário (Roles), utilizando o padrão RBAC (Role-Based Access Control) e Middlewares de autorização.

1. O que é RBAC? 👑

O RBAC (Role-Based Access Control) é um sistema onde você não dá permissão para um usuário específico, mas sim para um perfil (Role). * ADMIN: Pode criar, editar e deletar tudo. * EDITOR: Pode criar e editar, mas não deletar. * CLIENTE: Pode apenas visualizar o que é dele.

2. Middlewares de Autorização 🚧

Na aula passada, vimos a autenticação (login). Agora, precisamos de uma "cancela" que checa se o usuário logado tem o perfil certo para entrar em uma rota.

Como funciona: 1. O usuário envia o JWT. 2. O Middleware de Autenticação valida o token e extrai o id e o role. 3. O Middleware de Autorização checa: "Esse role está na lista de perfis permitidos?".

3. Implementando a Trava de Acesso 🔒

Criamos funções que geram middlewares dinamicamente.

// Exemplo conceitual
function autorizar(perfilNecessario) {
    return (req, res, next) => {
        if (req.usuario.role !== perfilNecessario) {
            return res.status(403).json({ mensagem: "Acesso Negado: Você não é um " + perfilNecessario });
        }
        next(); // Tudo certo, pode passar!
    };
}

4. Diferença entre 401 e 403 ❌

Estes dois códigos de erro são fundamentais no mundo da segurança: * 401 Unauthorized: "Não sei quem você é" (Token inválido, expirado ou ausente). * 403 Forbidden: "Eu sei quem você é, mas você não tem permissão para entrar aqui" (Ex: Cliente tentando entrar em rota de Admin).

5. Hierarquia de Permissões 🏛️

Em sistemas complexos, um Admin geralmente tem todas as permissões dos perfis abaixo dele. * Se uma rota permite EDITOR, o ADMIN também deve conseguir entrar automaticamente.

6. Mini-Projeto: O Gerente de Notificações 📢

Imagine um app escolar. 1. Crie uma rota /avisos/enviar. 2. Apenas usuários com o role PROFESSOR ou DIRETOR podem acessar essa rota. 3. Implemente o middleware que barra usuários do tipo ALUNO.

7. Exercício de Fixação 🧠

Por que é melhor usar Roles (Perfis) em vez de dar permissões específicas para cada ID de usuário?
Em qual parte do token JWT costumamos guardar o role do usuário?
Uma rota protegida deve primeiro passar pelo middleware de Autenticação ou pelo de Autorização? Por quê?

Próxima Aula: Como manter o usuário logado com segurança? Refresh Token e Segurança Avançada 🧵

Aula 11 - Refresh Token e Segurança Avançada 🏗️

Objetivo

Objetivo: Aprender a lidar com a expiração de tokens usando o padrão Refresh Token, configurar políticas de acesso com CORS e fortalecer o servidor contra ataques comuns usando Headers de Segurança (Helmet).

1. O Problema do Token Expirado ⏰

Tokens JWT devem ter vida curta (ex: 15 minutos). * Se for eterno: Se alguém roubar o celular, terá acesso para sempre. * Se for curto: O usuário terá que fazer login a cada 15 minutos (péssima experiência!).

A Solução: Refresh Token 🔁

Quando o usuário faz login, ele recebe dois tokens: 1. Access Token: Curto (15 min). Usado em cada requisição. 2. Refresh Token: Longo (7 dias). Guardado no Banco de Dados. Ele serve apenas para pedir um novo Access Token quando o antigo expirar.

2. CORS: Quem pode me chamar? 🌍

O CORS (Cross-Origin Resource Sharing) é uma trava que o navegador usa. * Se o seu site está em meusite.com e tenta chamar sua API em api.com, o navegador bloqueia por segurança, a menos que o servidor da API diga explicitamente: "Eu aceito chamadas de meusite.com".

No Backend (Express):

app.use(cors({
  origin: 'https://meusite.com'
}));

3. Helmet: Blindando os Headers 🪖

O Helmet é uma biblioteca que configura automaticamente vários cabeçalhos HTTP de segurança para esconder informações do seu servidor (ex: esconder que você usa Express) e prevenir ataques de injeção de scripts (XSS).

const helmet = require('helmet');
app.use(helmet());

4. Proteção contra Brute Force 🔨

Se um hacker tentar 1 milhão de senhas por segundo, ele vai acabar entrando. * Rate Limit: Limitamos que o mesmo IP só pode tentar o login 5 vezes a cada minuto. * Se passar disso, o IP é bloqueado temporariamente.

5. XSS e SQL Injection (Revisão) ⚔️

XSS: Injeção de scripts maliciosos no HTML. Previna limpando (sanitizando) o que o usuário digita.
SQL Injection: Vimos na Aula 08. Use sempre Query Parameters ou ORMs.

6. Mini-Projeto: O Flow do Refresh 🔄

Crie uma rota /refresh.
Essa rota deve receber um refreshToken.
Valide o token no banco de dados.
Se for válido, gere um NOVO accessToken e devolva para o usuário.

7. Exercício de Fixação 🧠

Por que guardamos o Refresh Token no Banco de Dados, mas o Access Token não (Stateless)?
O que acontece se você configurar o CORS com origin: '*'? Por que isso é perigoso em produção?
Qual a vantagem de usar o Helmet em um servidor em vez de configurar cada Header manualmente?

Próxima Aula: Fim do Módulo de Segurança! Vamos entrar no mundo das Aplicações Web Modernas? Introdução a SPAs e Frontend Moderno 🎨

Aula 12 - Introdução ao Frontend Moderno (React) ⚛️

Objetivo

Objetivo: Entender o que são Single Page Applications (SPAs), conhecer o ecossistema do React e aprender a arquitetura baseada em componentes.

1. O que é uma SPA? 📄

Antigamente, cada clique em um site fazia a página "piscar" e recarregar tudo do zero (HTML, CSS, JS). Nas Single Page Applications (SPAs): * A página carrega apenas uma vez. * Quando você clica em algo, apenas o conteúdo necessário é trocado (via Javascript). * É muito mais rápido e parece um aplicativo de celular.

2. Por que React? 🚀

O React (criado pelo Facebook) é a biblioteca mais usada no mundo para criar interfaces modernas. * Componentização: Você cria pequenos pedaços (botões, menus, cards) e os junta como peças de LEGO. * Virtual DOM: O React é inteligente e só atualiza na tela o que realmente mudou, tornando tudo muito performático.

3. Vite: A Ferramenta de Próxima Geração ⚡

Para criar um projeto React, usamos o Vite. Ele é extremamente rápido para o desenvolvedor (o código carrega instantaneamente enquanto você edita).

# Comando para criar um novo projeto
npm create vite@latest meu-app -- --template react

4. O Coração do React: Componentes 🧩

Um componente é apenas uma função Javascript que retorna algo parecido com HTML (chamado de JSX).

function Saudacao() {
  return (
    <div className="card">
      <h1>Olá, Mundo!</h1>
      <p>Este é meu primeiro componente React.</p>
    </div>
  );
}

Regras do JSX:

Você deve retornar apenas um elemento pai (ou usar um Fragment <></>).
Use className em vez de class (porque class é uma palavra reservada no Javascript).

5. Props: Passando Dados 🎁

Assim como passamos argumentos para funções, passamos Props para componentes.

function Usuario(props) {
  return <h2>Bem-vindo, {props.nome}!</h2>;
}

// Usando o componente:
<Usuario nome="Ricardo" />

6. Mini-Projeto: Dashboard de Vendas 📊

Crie um componente CardResumo que recebe titulo e valor.
Crie um componente ListaVendas que exibe 3 vendas falsas.
Monte uma página simples juntando esses componentes.

7. Exercício de Fixação 🧠

Qual a principal diferença entre um site tradicional (Multi Page) e uma SPA?
Por que o uso de componentes facilita a manutenção de projetos grandes?
O que é o JSX e por que ele não é exatamente HTML puro?

Próxima Aula: Como o React guarda informações? Hooks: useState e useEffect 🎣

Aula 13 - Estado e Reatividade (Hooks) 🎣

Objetivo

Objetivo: Aprender a tornar seus componentes vivos e interativos usando o hook useState, entendendo como o React reage a mudanças de dados.

1. O que é o "Estado" (State)? 🧠

Imagine um botão de curtir. O número de curtidas muda. No React, variáveis comuns NÃO fazem a tela atualizar. Para isso, usamos o Estado. * Variável Comum: Se o valor muda, a tela continua igual. * Estado (State): Se o valor muda, o React redesenha (re-renderiza) o componente na tela.

2. O Hook `useState` 🎣

O useState é uma função especial que nos dá duas coisas: o valor atual e uma função para mudar esse valor.

import { useState } from 'react';

function Contador() {
  // valor: o número atual | setValor: a função para mudar
  const [valor, setValor] = useState(0);

  return (
    <div>
      <p>Você clicou {valor} vezes</p>
      <button onClick={() => setValor(valor + 1)}>
        Aumentar
      </button>
    </div>
  );
}

3. Lidando com Eventos ⚡

No React, os eventos são muito parecidos com o HTML, mas usamos CamelCase: * onclick ➔ onClick * onchange ➔ onChange * onsubmit ➔ onSubmit

4. Inputs Controlados ⌨️

Para pegar o que o usuário digita, conectamos o valor do input ao nosso estado.

function Formulario() {
  const [nome, setNome] = useState("");

  return (
    <div>
      <input 
        type="text" 
        value={nome} 
        onChange={(e) => setNome(e.target.value)} 
        placeholder="Digite seu nome"
      />
      <p>Olá, {nome}!</p>
    </div>
  );
}

5. A Regra de Ouro: Nunca mude o estado diretamente ❌

Você nunca deve fazer isto: valor = valor + 1;. Você deve sempre usar a função disparadora: setValor(valor + 1);. Isso avisa ao React: "Ei, os dados mudaram! Desenha a tela de novo!".

6. Mini-Projeto: Lista de Compras Simples 🛒

Crie um input e um botão "Adicionar".
Use um estado para guardar a lista (um Array).
Ao clicar, adicione o texto do input no array usando setLista([...lista, novoItem]).
Exiba a lista usando .map().

7. Exercício de Fixação 🧠

O que acontece com a interface se você alterar uma variável comum let contador = 0 dentro de um componente?
Para que serve o segundo item retornado pelo useState (a função set...)?
Como limpamos um campo de input após o usuário clicar em um botão de enviar?

Próxima Aula: Ciclo de Vida e APIs! Hook: useEffect 🕒

Aula 14 - Efeitos e Chamadas de API (useEffect) 🌐

Objetivo

Objetivo: Entender o ciclo de vida de um componente React e aprender a buscar dados de APIs reais usando o hook useEffect.

1. O que são "Efeitos Colaterais"? 🧪

Em um componente, a tarefa principal é desenhar a tela. Qualquer coisa que aconteça "por fora" disso é um efeito colateral: * Buscar dados em uma API. { .fragment } * Mudar o título da aba do navegador. { .fragment } * Configurar um cronômetro (timer). { .fragment }

2. O Hook `useEffect` 🕒

O useEffect permite que você execute código em momentos específicos: 1. Quando o componente aparece na tela (Montagem). 2. Quando algum dado específico muda. 3. Sempre que o componente atualiza.

import { useEffect, useState } from 'react';

function Exemplo() {
  useEffect(() => {
    console.log("O componente apareceu na tela!");
  }, []); // [] = Array de dependências vazio significa "executa só uma vez"
}

3. O Array de Dependências 🗃️

É o segundo argumento do useEffect. Ele diz ao React quando rodar o efeito de novo: * []: Roda apenas na montagem. * [contador]: Roda na montagem e toda vez que contador mudar. * Sem array: Roda em toda e qualquer atualização (Cuidado! Pode causar loops infinitos).

4. Buscando Dados de uma API (Fetch) 📨

Vamos usar a API do GitHub como exemplo:

function PerfilGithub() {
  const [usuario, setUsuario] = useState(null);

  useEffect(() => {
    fetch("https://api.github.com/users/ricardotecpro")
      .then(response => response.json())
      .then(data => setUsuario(data));
  }, []);

  if (!usuario) return <p>Carregando...</p>;

  return (
    <div>
      <h1>{usuario.name}</h1>
      <img src={usuario.avatar_url} alt="Avatar" />
    </div>
  );
}

5. Boas Práticas: Loading e Error 🛡️

Sempre que fizermos uma chamada de rede, devemos tratar três estados: 1. Loading: "Aguarde, estamos buscando...". 2. Success: Exibir os dados. 3. Error: "Ops, algo deu errado!".

6. Mini-Projeto: Dashboard de Clima ☁️

Crie um estado para a cidade e outro para os dados do clima.
Use o useEffect para buscar os dados de uma API de clima sempre que a cidade mudar.
Exiba a temperatura e a condição atual.

7. Exercício de Fixação 🧠

O que acontece se esquecermos de passar o array de dependências [] em um useEffect que faz um fetch e atualiza o estado?
Como fazemos para que um efeito seja executado apenas quando uma variável ID mudar?
Para que serve o comando response.json() após uma chamada de fetch?

Próxima Aula: Navegação entre telas! React Router 🚦

Aula 15 - Navegação com React Router 🚦

Objetivo

Objetivo: Aprender a criar aplicações de múltiplas páginas (multi-page) dentro de uma SPA, configurando rotas, links e parâmetros de URL.

1. Por que precisamos de um Roteador? 🧭

Em uma Single Page Application (SPA), o navegador nunca "recarrega" de verdade. Se você clicar em um link comum, ele tenta buscar um novo arquivo HTML no servidor. O React Router intercepta os cliques e troca apenas o componente na tela, mantendo a sensação de um site completo com /home, /sobre, etc.

2. Instalação e Configuração ⚙️

O roteador não vem no React por padrão. Precisamos instalar: npm install react-router-dom

No seu App.jsx, configuramos a estrutura básica:

import { BrowserRouter, Routes, Route } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/sobre" element={<Sobre />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </BrowserRouter>
  );
}

3. Navegando entre Páginas 🏃‍♂️

Para mudar de página, nunca use a tag <a> comum, pois ela recarrega o site do zero. Use o componente <Link>:

import { Link } from 'react-router-dom';

function Navbar() {
  return (
    <nav>
      <Link to="/">Início</Link>
      <Link to="/sobre">Sobre</Link>
    </nav>
  );
}

4. Navegação Programática 🚀

Às vezes, queremos mudar de página via código (ex: após um login com sucesso). Para isso, usamos o hook useNavigate:

import { useNavigate } from 'react-router-dom';

function Login() {
  const navigate = useNavigate();

  const handleLogin = () => {
    // ... lógica de login
    navigate("/dashboard");
  };
}

5. Parâmetros de URL (Hooks) 🆔

Como exibir uma página específica de um produto (ex: /produto/123)? Usamos o caractere : na rota:

Rota: <Route path="/produto/:id" element={<Detalhes />} />
Captura: No componente Detalhes, usamos o hook useParams.

import { useParams } from 'react-router-dom';

function Detalhes() {
  const { id } = useParams();
  return <h1>Exibindo o produto ID: {id}</h1>;
}

6. Mini-Projeto: Blog de TecPro 📰

Crie uma página inicial que lista 3 posts (objetos simples).
Crie uma rota dinâmica /post/:id.
Ao clicar no link do post, o usuário deve ser levado para a página de detalhes que mostra o ID do post acessado.

7. Exercício de Fixação 🧠

Qual a principal diferença visual entre usar <a href="..."> e <Link to="..."> em um app React?
Para que serve o path="*" em uma configuração de rotas?
Se você quiser criar uma área de "Perfil do Usuário" onde a URL é /u/ricardo, como ficaria a definição do path no componente Route?

Próxima Aula: O grande final! Projeto Full-Stack Integrado 🏆

Aula 16 - Projeto Final e Conclusão 🏆

Objetivo

Objetivo: Aplicar TODO o conhecimento adquirido (Node.js, Express, JWT, RBAC, React, Hooks e Router) para criar uma aplicação Full-Stack completa e funcional.

1. O Desafio Final: "TecPro Connect" 🔗

Você deve criar uma plataforma web completa que conecte seu Frontend ao seu Backend. Escolha UM dos temas abaixo ou crie o seu:

Gerenciador de Tarefas Cloud: Sistema de login, cadastro de tarefas com categorias, salvamento no banco de dados e filtros de status.
Mini E-commerce: Listagem de produtos vindo da API, página de detalhes, "carrinho" (estado global) e simulação de checkout.
Rede Social de Bolso: Postagem de mensagens (tweets), perfil de usuário dinâmico e curtidas (likes) em tempo real.
Sistema de Chamados (Helpdesk): Usuário abre o ticket (Frontend) e o Admin visualiza e altera o status (Backend com permissões RBAC).

2. Requisitos Obrigatórios (Checkout) 📋

O projeto integrado deve conter obrigatoriamente: - [ ] Backend em Node.js: Pelo menos 3 rotas protegidas por JWT. - [ ] Frontend em React: Interface moderna, responsiva e baseada em componentes. - [ ] Integração (Fetch): O site deve buscar dados reais da sua API local ou hospedada. - [ ] Navegação: Uso de React Router para pelo menos 3 páginas (Login, Home, Perfil). - [ ] Estado: Uso de useState e useEffect para gerenciar os dados.

3. Dicas para um Portfólio Arrasador ✨

Para que seu projeto chame a atenção de empresas: 1. README.md Profissional: Explique o problema que você resolveu, como rodar o projeto (frontend e backend) e liste as tecnologias (ex: Vite, Express, Helmet). 2. Tratamento de Erros: Se o servidor cair, o frontend deve avisar o usuário amigavelmente. 3. Aesthetics: Capriche no CSS! Use cores harmônicas e uma tipografia limpa. 4. Segurança: Não esqueça de configurar o CORS no backend para aceitar os pedidos do seu frontend.

4. Onde continuar estudando? 📚

A jornada de um desenvolvedor Full-Stack está apenas começando. O que aprender agora? 1. TypeScript: O "superpoder" do Javascript para evitar erros de tipos. 2. Bancos de Dados SQL: Postgres ou MySQL para aplicações ainda mais robustas. 3. Next.js: O framework React que domina o mercado atual (com SSR e rotas nativas). 4. Docker: Para empacotar sua aplicação e rodar em qualquer lugar.

5. Mensagem Final 🌟

Parabéns! Você saiu do básico de requisições HTTP e hoje é capaz de construir uma ponte sólida entre o usuário e os dados. Você domina a arte de criar APIs seguras e interfaces vivas.

"A tecnologia é apenas uma ferramenta. Em termos de conseguir que as pessoas trabalhem juntas e as motivem, o desenvolvedor é o artista."

FIM DO CURSO 🚀🚀🚀 Desejamos muito sucesso na sua jornada como Desenvolvedor Full-Stack!

Exercícios

Listas de Exercícios 🏋️

Pratique o que aprendeu com desafios graduais para cada aula.

Módulo 1: Fundamentos de Backend ---
Módulo 2: Manipulação de Dados ---
Módulo 3: Segurança e Autenticação ---
Módulo 4: Aplicações SPA (React) ---

Exercícios 01 - Introdução a Microsserviços 🧩

🟢 Fáceis

Definição: Explique com suas palavras o que é um microsserviço.
Diferenciação: Cite 3 desvantagens de um sistema Monolítico em relação a uma arquitetura de Microsserviços.

🟡 Médios

Cenário: Uma startup de delivery começou com um monólito e agora está sofrendo para atualizar o sistema de pagamentos sem quebrar o rastreamento de pedidos. Qual vantagem dos microsserviços resolveria esse problema? Justifique.
Conectividade: O que é uma API e por que ela é fundamental na integração de sistemas distribuídos?

🔴 Desafio

Análise de Arquitetura: Imagine o sistema do "Netflix". Ele possui milhões de usuários acessando simultaneamente filmes, perfis e faturas.
- Se o serviço de "Busca" falhar, o usuário deve ser impedido de assistir aos filmes que já estão na sua lista "Continuar Assistindo"? Como a arquitetura de microsserviços ajuda nesse isolamento?
- Desenhe/Escreva como seria a divisão básica: Quais seriam os pelo menos 4 serviços independentes que você criaria para o Netflix?

Exercícios 02 - Arquitetura e Gateway 🏗️

🟢 Fáceis

Conceitos: Explique o que é um API Gateway com uma analogia da vida real (ex: uma recepção de hotel).
Síncrono vs Assíncrono: Diferencie os dois modelos de comunicação em uma frase cada.

🟡 Médios

Resiliência: O que acontece com um sistema distribuído que só usa comunicação síncrona se o serviço de banco de dados ficar muito lento? Como isso afeta o usuário final?
Segurança: Por que é melhor colocar a lógica de autenticação no API Gateway do que repetir em cada um dos 20 microsserviços?

🔴 Desafio

Cenário de Falha Crítica: O serviço de "Notificação" (envio de e-mail e SMS) está fora do ar.
- Se o seu sistema for síncrono, o usuário conseguirá finalizar uma compra?
- Como a abordagem assíncrona com filas resolveria esse problema, garantindo que o e-mail seja enviado quando o serviço voltar?
- Cite um exemplo de serviço que precisa ser síncrono (não pode esperar).

Exercícios 03 - Modelagem REST 📡

🟢 Fáceis

URI Design: Corrija as URIs abaixo para seguirem as boas práticas REST:
- GET /listar_todos_usuarios
- POST /criarNovoPedido
- DELETE /remover-produto-por-id/123
Verbos: Qual o verbo HTTP mais adequado para atualizar a senha de um usuário? Por que?

🟡 Médios

Status Codes: Escolha o código de status ideal para as situações:
- Usuário tentou deletar um arquivo, mas ele não tem permissão de administrador.
- O cadastro foi realizado com sucesso e o sistema retornou os dados do novo usuário.
- O servidor caiu por falta de memória.
Idempotência: Explique por que o POST não é idempotente e o GET é.

🔴 Desafio

Design de Contrato: Desenhe as rotas para um sistema de E-commerce.
- Como seria a URI para listar todos os itens de um carrinho específico?
- Como seria a URI para adicionar um item a este carrinho?
- Escreva o JSON que representaria um "Item de Carrinho" com: produto_id, nome, quantidade e preco_unitario.

Exercícios 04 - Documentação e Mocks 📝

🟢 Fáceis

Conceitos: O que é OpenAPI e qual a relação dela com o Swagger?
Mocks: Explique com suas palavras por que um desenvolvedor Frontend desejaria usar um Mock Server.

🟡 Médios

Análise de YAML: Analise o trecho OpenAPI abaixo e responda: Qual o endpoint? Qual o verbo? O que ele retorna no sucesso?

/usuarios/{id}:
  get:
    summary: Busca usuário por ID
    responses:
      '200':
        description: Usuário encontrado

Developer Experience (DX): Imagine que você recebeu uma documentação que diz apenas: POST /login - Envie os dados do usuário. Por que essa documentação é ruim sob a ótica de DX?

🔴 Desafio

Cenário de Desenvolvimento: Você é o arquiteto de um projeto onde o Backend vai demorar 3 semanas para liberar a primeira API, mas o Frontend precisa começar amanhã.
- Como você organizaria o trabalho usando Mocks?
- Como garantir que, quando o Backend ficar pronto, a integração ocorra sem precisar mudar nada no código do Frontend?
- Cite uma ferramenta que você usaria para subir esse Mock Server rapidamente.

Exercícios 05 - Implementação de APIs ⚙️

🟢 Fáceis

Responsabilidade: Qual a principal função de um Controller em uma arquitetura de camadas?
Mapeamento: O que é um "Handler" no contexto de rotas backend?

🟡 Médios

Parâmetros: Diferencie, com exemplos de URIs, o uso de Path Params e Query Params.
Erros: Por que o Controller nunca deve retornar uma resposta sem um Status Code explícito?

🔴 Desafio

Cenário Real: Imagine que você está implementando a rota de PUT /produtos/123.
- Como você capturaria o 123?
- Como você capturaria o novo nome do produto?
- Em qual objeto (req.params, req.query ou req.body) cada um desses dados estaria?
- O que você faria se o cliente enviasse o id no Body diferente do id na URL?

Exercícios 06 - Services e Regras de Negócio 🧠

🟢 Fáceis

Conceito: Explique por que não é uma boa prática colocar lógica de cálculo ou validação dentro do Controller.
Responsabilidade: Cite 3 exemplos de tarefas que devem ser feitas na camada de Service.

🟡 Médios

Tratamento de Erros: Por que o Service deve lançar (throw) um erro em vez de retornar um Status Code (ex: 404)?
Reutilização: Imagine que você tem um EmailService. Cite dois Controllers diferentes que poderiam usar esse mesmo serviço.

🔴 Desafio

Lógica de Negócio: Escreva o pseudocódigo para um PedidoService.finalizar(pedidoId).
- Quais validações você faria? (Estoque, status do pedido, limite de crédito do cliente).
- Como você lidaria com o caso de "Produto Sem Estoque"?
- Qual tipo de dado (DTO) o Service deveria retornar para o Controller após o sucesso?

Exercícios 07 - Repositories e Banco de Dados 🗄️

🟢 Fáceis

Fundamentos: O que significa a sigla SQL e para que ela serve?
CRUD: Escreva o comando SQL para inserir um novo produto (nome "Mouse", preço 50.00) na tabela produtos.

🟡 Médios

Relacionamentos: Explique a diferença entre uma Primary Key (PK) e uma Foreign Key (FK). Por que a FK é essencial para bancos relacionais?
Isolamento: Por que usamos o padrão Repository em vez de escrever o código SQL diretamente dentro do Service?

🔴 Desafio

Modelagem Real: Imagine um sistema de Blog. Temos Escritores e Artigos.
- 1:N: Como você modelaria a ligação entre um Escritor e seus Artigos?
- SQL: Escreva uma query que retorne o título de todos os artigos escritos pelo autor com id = 5.
- Repository: Como ficaria a assinatura (nome e parâmetros) da função no ArtigoRepository responsável por essa busca?

Exercícios 08 - Boas Práticas e Validação de Dados ✅

🟢 Fáceis

Conceito: Por que nunca devemos confiar 100% nos dados vindos do frontend?
Validação: Dê um exemplo de uma regra de validação para um campo de "Senha".

🟡 Médios

Sanitização: Qual a diferença prática entre validar um campo e sanitizar um campo? Quando usamos cada um?

Clean Code: Refatore o nome da função abaixo para seguir as boas práticas:

function usr_ch(a, b) { ... } // Recebe e-mail e id, checa se e-mail já existe

🔴 Desafio

Tratamento de Erros: Imagine que o banco de dados caiu. O Service lança um erro técnico.
- Como o Middleware Global de Erros deve reagir?
- O que ele deve enviar para o usuário final? (Erro 500 com mensagem técnica ou mensagem genérica?)
- Por que é importante logar o erro real apenas no console do servidor?

Exercícios 09 - Segurança e Autenticação com JWT 🔐

🟢 Fáceis

Conceito: Qual a principal diferença entre Autenticação e Autorização?
JWT: Quais são as 3 partes de um token JWT?

🟡 Médios

Segurança: Por que nunca devemos incluir informações sensíveis (como a senha do usuário) dentro do Payload do JWT?
Stateless: Quais as vantagens de uma arquitetura "Stateless" em sistemas que precisam escalar para milhões de usuários?

🔴 Desafio

Análise de Token: Imagine que você interceptou um token JWT.
- Como você faria para ler o nome do usuário que está dentro dele sem saber a chave secreta?
- Agora, imagine que você tentou mudar o id do usuário para burlar o sistema. Por que o servidor vai rejeitar esse token quando você tentar usá-lo?
- Onde o frontend deve armazenar o token para que ele não suma quando a página for recarregada?

Exercícios 10 - Controle de Acesso (RBAC) 🛡️

🟢 Fáceis

Conceito: No sistema RBAC, o que é uma "Role"?
Status Code: Se um usuário comum tenta acessar uma área de administrador, qual o código de erro HTTP (Status Code) mais apropriado?

🟡 Médios

Diferença: Explique a diferença fundamental entre erro 401 e erro 403. Em qual desses casos o usuário deve ser redirecionado para a tela de login?
Middleware: Imagine que você tem uma rota /admin/dashboard. Quais seriam os dois middlewares (nesta ordem) que o usuário deveria passar antes de chegar no Controller final?

🔴 Desafio

Hierarchy (Hierarquia): Implemente (em pseudocódigo) uma lógica onde a função autorizar(['EDITOR', 'ADMIN']) permita a passagem se o usuário logado tiver QUALQUER um desses dois perfis.
- Como você garantiria que um ADMIN sempre consiga acessar rotas de USER e EDITOR sem precisar listar o ADMIN em todas as rotas do sistema?
- Qual a vantagem dessa abordagem centralizada?

Exercícios 11 - Refresh Token e Segurança Avançada 🏗️

🟢 Fáceis

Conceito: Por que Access Tokens costumam ter vida curta?
Bibliotecas: Para que serve a biblioteca Helmet em um aplicativo Express?

🟡 Médios

CORS: Explique por que o CORS é uma segurança do Navegador e não do servidor. O que acontece se você tentar chamar uma API sem CORS a partir de um script no Terminal (cURL)?
Flow: Desenhe o fluxo de uma requisição que retorna erro 401 por token expirado e como o frontend deve agir para usar o Refresh Token.
Headers: Cite três informações sensíveis que o Helmet ajuda a esconder nos cabeçalhos HTTP.

🔴 Desafio

Segurança de Refresh Tokens: Se o Refresh Token permite gerar novos Access Tokens, por que ele é considerado mais seguro?
- Onde ele deve ser armazenado preferencialmente no navegador (LocalStorage ou Cookies HttpOnly)? Por quê?
- O que é o "Refresh Token Rotation"?

Exercícios 12 - Introdução ao React ⚛️

🟢 Fáceis

Conceito: O que significa a sigla SPA e qual sua principal vantagem?
Sintaxe: No React, usamos className ou class para definir classes CSS? Por quê?

🟡 Médios

Componentes: Por que dizemos que a arquitetura do React é baseada em "LEGO"? Como isso ajuda na organização do código?
Vite: Qual a função do Vite no desenvolvimento de um projeto React moderno?
Props: Explique como as props permitem que um mesmo componente (ex: um Botão) seja usado em vários lugares com textos e cores diferentes.

🔴 Desafio

JSX vs HTML: O código abaixo é Javascript ou HTML? Justifique sua resposta mencionando pelo menos duas diferenças sutis que o JSX impõe.
```
const elemento = (
  <div className="container">
    <h1>Título</h1>
    <br />
  </div>
);
```
- O que acontece se eu esquecer de fechar a tag <br>?
- Como eu faria para exibir o valor de uma variável nome dentro do h1?

Exercícios 13 - Estado e Reatividade (Hooks) 🎣

🟢 Fáceis

Conceito: Por que uma variável comum (ex: let x = 0) não serve para atualizar um contador na tela do React?
Sintaxe: O que faz o comando const [valor, setValor] = useState(0);? Explique cada um dos 3 elementos.

🟡 Médios

Eventos: Como passamos uma função que deve ser executada apenas quando o usuário clica em um botão? Mostre um exemplo de código.
Imutabilidade: Por que não podemos fazer lista.push(item) e depois setLista(lista) no React? Qual o jeito correto de adicionar um item a um array no estado?
Inputs: O que é um "Input Controlado" e como o atributo value e o evento onChange trabalham juntos?

🔴 Desafio

Toggle de Visibilidade: Crie a lógica para um componente que esconde ou mostra um texto secreto.
- Qual tipo de dado você usaria no useState (Boolean, String ou Number)?
- Como ficaria a expressão JSX para mostrar o texto apenas se o estado for verdadeiro?

Exercícios 14 - Efeitos e Chamadas de API 🌐

🟢 Fáceis

Conceito: O que é um "Efeito Colateral" (Side Effect) no desenvolvimento Frontend?
useEffect: O que acontece se passarmos um array de dependências vazio [] para o useEffect?

🟡 Médios

Dependências: Se eu quiser que o useEffect rode sempre que a variável usuarioID mudar, como deve ficar o array de dependências?

Fetch: Explique a ordem de execução do código abaixo:

console.log("A");
fetch("url").then(() => console.log("B"));
console.log("C");

Estados de Rede: Por que é importante ter um estado de loading (carregando) em aplicações que buscam dados na internet?

🔴 Desafio

Ciclo de Efeitos: Imagine que seu efeito faz um fetch e, dentro do .then(), você chama um setData(dados).
- O que acontece se você NÃO passar o array []? Explique o loop infinito que isso gera.
- Como você faria para exibir uma mensagem "Nenhum resultado encontrado" caso a API retorne um array vazio?

Exercícios 15 - Navegação com React Router 🚦

🟢 Fáceis

Conceito: Por que usamos o React Router em vez de links <a> comuns em uma SPA?
Componentes: Para que servem os componentes <BrowserRouter> e <Routes>?

🟡 Médios

Navegação: Qual a diferença entre usar o componente <Link> e o hook useNavigate? Em quais situações você usaria cada um?
Rota 404: Como configuramos uma rota que deve ser exibida quando o usuário digita uma URL que não existe no site?
Parâmetros: Dada a rota <Route path="/usuario/:nome" element={<Perfil />} />, como o componente Perfil pode descobrir qual o nome que foi digitado na URL?

🔴 Desafio

Proteção de Rotas: Imagine que você tem uma página /admin que só pode ser acessada se o usuário estiver logado.
- Como você usaria o useNavigate dentro de um useEffect para redirecionar o usuário para a página de /login caso ele não tenha um token salvo no localStorage?
- O que acontece se o usuário clicar no botão "Voltar" do navegador após ser redirecionado?

Exercícios 16 - Planejamento do Projeto Final 🏆

🟢 Fáceis

Escolha do Tema: Qual dos temas sugeridos (Tarefa Cloud, E-commerce, Rede Social, Helpdesk) você escolheu para o seu projeto final? Se for um tema autoral, descreva-o em uma frase.
Tecnologias: Enumere pelo menos 3 tecnologias do Frontend e 3 do Backend que você usará no seu TCC.

🟡 Médios

Arquitetura: Desenhe um diagrama simples (ou explique em texto) como os dados fluirão da sua API Node.js até a tela do usuário no React.
Segurança: Como você planeja proteger as informações sensíveis (senhas, segredos JWT) no seu projeto final?
CORS: Por que você precisará configurar o CORS no seu servidor para que o projeto funcione?

🔴 Desafio

Plano de Entrega: Crie um cronograma de 3 passos para a construção do seu projeto:
- Passo 1: O que será feito primeiro no Backend?
- Passo 2: Como será a integração inicial?
- Passo 3: Qual a funcionalidade de "brilho" (extra) que você quer adicionar?

Projetos

Projetos Práticos 🚀

Transforme teoria em prática com desafios progressivos que compõem seu portfólio.

Módulo 1: Fundamentos de Backend ---
Módulo 2: Manipulação de Dados ---
Módulo 3: Segurança e Autenticação ---
Módulo 4: Aplicações SPA (React) ---

Projeto 01 - Cinto de Utilidades Backend 🛠️

Objetivo: Validar a instalação das ferramentas e testar a comunicação básica com uma API pública.

O Desafio

Instale o Postman ou Insomnia.
Realize uma requisição do tipo GET para a API pública do GitHub: https://api.github.com/users/github.
Analise a resposta (JSON). Identifique os campos login, id e public_repos.
Instale o Docker Desktop e rode o comando docker run hello-world no terminal para garantir que a virtualização está ativa.
Crie uma conta no GitHub (se não tiver) e instale o Git.

O que entregar?

Print (screenshot) da resposta JSON no Postman/Insomnia.
Print do terminal com a mensagem de sucesso do Docker "Hello from Docker!".

Projeto 02 - Modelagem de Fluxo de Gateway 🏗️

Objetivo: Entender o roteamento e a agregação de dados em um Gateway.

O Desafio

Imagine que você tem dois serviços: - Serviço A (User): Retorna { "id": 1, "nome": "Ricardo" } - Serviço B (Orders): Retorna [ { "id": 101, "valor": 50.0 }, { "id": 102, "valor": 30.0 } ]

Desenhe um diagrama (pode ser no Mermaid ou papel) onde um API Gateway recebe uma chamada em /dashboard/1 e busca os dados nos dois serviços.
Escreva o JSON final que o Gateway entregaria para o Frontend, unindo as informações do usuário e seus pedidos.
Pesquisa: Liste 3 ferramentas famosas de API Gateway de mercado (ex: Kong, AWS API Gateway, etc).

O que entregar?

O diagrama de fluxo.
O JSON de resposta agregada.
A lista de ferramentas pesquisadas.

Objetivo: Aplicar os conceitos de recursos, verbos e JSON na modelagem de uma rede social.

O Desafio

Você deve projetar a API para o recurso "Postagens" (Posts).

Liste as 5 rotas principais (CRUD) para gerenciar postagens, indicando o Verbo, a URI e o Status Code de sucesso esperado.
Crie um exemplo de JSON para uma postagem que contenha:
- id
- autor_id
- conteúdo (texto)
- data_publicacao
- tags (lista de strings)
Simulação de Erro: Qual seria a URI e o Verbo para dar um "Like" em uma postagem? Projete isso.

O que entregar?

Tabela com as 5 rotas (Verbo, URI, Status).
Bloco de código com o JSON de exemplo.
Proposta da rota de "Like".

Projeto 04 - Criando o Primeiro Mock 🧱

Objetivo: Dominar o fluxo de documentação de contrato e simulação de servidor.

O Desafio

Você deve criar um servidor de Mock para uma API de Lista de Tarefas (ToDo).

Use o Postman (Mock Server) ou o Mockoon para criar 2 rotas:
- GET /tarefas: Deve retornar uma lista com pelo menos 3 tarefas.
- POST /tarefas: Deve aceitar uma nova tarefa e retornar 201 Created.
Documente os campos de uma tarefa (ex: id, titulo, concluida).
Teste as rotas e garanta que o servidor responda corretamente no formato JSON.

O que entregar?

Print (screenshot) do Swagger UI ou da tela do Mock Server rodando.
O JSON de exemplo retornado pelo GET /tarefas.
Print do teste da rota POST /tarefas com sucesso.

Projeto 05 - Meu Primeiro Controller ⚙️

Objetivo: Praticar a criação de rotas e a captura de diferentes tipos de parâmetros.

O Desafio

Crie a estrutura de um Controller para um sistema de Gestão de Tarefas (To-Do). Você deve definir (em pseudocódigo ou na linguagem que preferir):

Uma rota para listar todas as tarefas, permitindo um filtro opcional por status (ex: concluída ou pendente).
Uma rota para buscar uma única tarefa pelo seu id.
Uma rota para criar uma tarefa, recebendo titulo e descricao.
Sinalize qual seria o Status Code de sucesso para cada uma das rotas acima.

O que avaliar?

Uso correto de Path Params vs Query Params.
Escolha dos verbos HTTP adequados.
Padronização das respostas de sucesso.

Projeto 06 - Implementando a Lógica de Negócio 🧠

Objetivo: Aplicar a separação de camadas criando um Service para validação de dados.

O Desafio

Você deve criar o UsuarioService para um sistema de cadastro.

Função validarSenha(senha): Deve garantir que a senha tenha no mínimo 8 caracteres e contenha pelo menos um número.
Função criarUsuario(dados):
- Chama a validação de senha.
- Verifica se o e-mail já está sendo usado (simule um erro se estiver).
- Retorna o usuário criado (sem a senha!).
Simule o Controller chamando esse Service e tratando o erro de "Senha Insegura" com um Status Code 400.

O que observar?

O Service não deve usar objetos globais como req ou res.
As mensagens de erro devem ser claras e informativas.
Uso de DTOs (retornar objeto filtrado).

Projeto 07 - Modelagem de Banco de Dados 🗄️

Objetivo: Praticar a criação de esquemas relacionais e comandos SQL básicos.

O Desafio

Modele o banco de dados para um sistema de Aluguel de Filmes:

Tabelas: Crie as tabelas Clientes e Filmes.
Campos:
- Clientes deve ter id, nome e email.
- Filmes deve ter id, titulo e genero.
Relacionamento: Crie uma terceira tabela Alugueis que ligue um cliente a um filme (incluindo a data_aluguel).
SQL: Escreva uma query que liste o nome do cliente e o título do filme para todos os aluguéis feitos hoje.

O que avaliar?

Definição correta das Chaves Primárias.
Uso de Chaves Estrangeiras para conectar as tabelas.
Clareza na estrutura das colunas.

Projeto 08 - Schema de Validação Profissional ✅

Objetivo: Praticar a criação de regras de validação para garantir a integridade da API.

O Desafio

Crie o esquema de validação (em pseudocódigo ou usando uma biblioteca como Zod/Joi) para um Cadastro de Eventos:

Campos Obrigatórios: titulo (mín. 10 char), data (deve ser futura), capacidade_maxima (número positivo).
Campos Opcionais: descricao (máx. 500 char), link_inscricao (formato de URL).
Sanitização: O título não deve conter espaços em branco sobrando no início ou no fim (trim).
Simulação: Mostre qual seria a mensagem de erro retornada se o usuário enviasse uma capacidade negativa.

O que avaliar?

Clareza e rigor das regras de validação.
Escolha dos tipos de dados corretos.
Mensagens de erro amigáveis ao desenvolvedor (DX).

Objetivo: Implementar a lógica de geração de tokens JWT para autenticação.

O Desafio

Crie uma API de simulação de login:

Entrada: Receba um JSON com email e senha.
Validação: Verifique se a senha tem mais de 6 caracteres.
JWT: Use uma biblioteca (ou pseudocódigo) para gerar um token que contenha o id do usuário e sua permissão (ex: 'aluno').
Expiração: Configure o token para ser válido por apenas 24 horas.
Resposta: Retorne para o cliente um objeto contendo o token e o nome do usuário.

O que avaliar?

Tratamento correto de erro caso a senha seja curta.
Estrutura limpa do Payload do JWT.
Escolha de uma chave secreta segura (simulada).

Projeto 10 - Gerenciador de Permissões 🛡️

Objetivo: Implementar a lógica de proteção de rotas baseada em perfis de usuário.

O Desafio

Crie a estrutura de autorização para um Sistema de RH:

Roles: Defina três tipos: ADMIN, GESTOR e FUNCIONARIO.
Regras:
- Todos podem ver o próprio perfil (GET /me).
- Apenas GESTOR e ADMIN podem ver a lista de salários (GET /salarios).
- Apenas ADMIN pode deletar um registro (DELETE /colaboradores/:id).
Middleware: Desenhe (em desenho técnico ou código) como seria o "fluxo da cancela" (Authentication Middleware -> Authorization Middleware).

O que avaliar?

Separação clara entre quem é você e o que você pode fazer.
Uso correto dos Status Codes em caso de bloqueio.
Lógica de hierarquia (Admin pode tudo).

Projeto 11 - Blindagem de API 🏗️

Objetivo: Implementar camadas avançadas de segurança e renovação de tokens.

O Desafio

Fortaleça sua API de login:

Helmet: Instale e configure o Helmet para proteger os Headers.
CORS: Restrinja o acesso à API para que apenas o domínio http://localhost:3000 possa consultá-la.
Refresh Token: Implemente uma rota /refresh que receba um refresh token, valide-o no banco (ou lista em memória) e gere um novo accessToken.
Rate Limit: Adicione uma trava para que ninguém possa tentar logar mais de 5 vezes em 1 minuto.

O que avaliar?

Configuração correta das origens no CORS.
Lógica de expiração do Refresh Token (ele deve durar muito mais que o Access Token).
Verificação se o Helmet está realmente escondendo o header X-Powered-By.

Projeto 12 - Primeiro App React ⚛️

Objetivo: Criar e organizar componentes básicos usando React e Vite.

O Desafio

Crie uma página de Perfil de Usuário:

Componente FotoPerfil: Exibe uma imagem circular.
Componente InfoUsuario: Recebe nome e bio via props e exibe na tela.
Componente BotaoSeguir: Um botão simples que, por enquanto, apenas exibe um alerta ao ser clicado.
Layout: Organize esses componentes dentro do App.jsx usando CSS simples para centralizar o conteúdo.

O que avaliar?

Separação correta dos componentes em arquivos diferentes (ou funções separadas).
Uso correto de Props para personalizar o nome do usuário.
Sintaxe JSX correta (tags fechadas, className, etc).

Projeto 13 - Lista Dinâmica de Contatos 📱

Objetivo: Aplicar o uso de useState e gerenciamento de listas.

O Desafio

Crie um mini-gerenciador de contatos:

Inputs: Dois campos de texto (Nome e Telefone).
Botão Adicionar: Quando clicado, deve validar se os campos estão preenchidos e adicionar o contato em um Estado de Array.
Lista: Exiba todos os contatos adicionados abaixo do formulário.
Botão Limpar: Um botão que limpa toda a lista de contatos.

O que avaliar?

Uso correto do useState para os inputs e para a lista.
Uso do .map() para renderizar a lista de contatos.
Limpeza dos campos de input após a adição com sucesso.

Projeto 14 - Buscador de Repositórios 🔍

Objetivo: Consumir uma API real e gerenciar estados de carregamento.

O Desafio

Crie um app que busca repositórios do GitHub de um usuário:

Input: Campo para digitar o nome do usuário do GitHub.
Botão Buscar: Ao clicar, deve disparar a busca.
Loading: Enquanto a API não responde, deve aparecer o texto "Buscando repositórios...".
Lista: Exiba o nome de todos os repositórios públicos encontrados.
Erro: Se o usuário não existir, exiba "Erro: Usuário não encontrado".

O que avaliar?

Uso do useEffect para carregar dados (pode ser ao carregar a página ou via clique).
Tratamento correto dos estados: null, loading, data e error.
Renderização limpa usando .map().

Projeto 15 - Sistema de Multi-Páginas 🚦

Objetivo: Implementar a navegação completa em uma SPA.

O Desafio

Transforme seu app de repositórios ou contatos em um site completo com 3 páginas:

Home (/): Uma página de boas-vindas com links para as outras seções.
Dashboard (/app): Onde fica a funcionalidade principal (ex: a busca de repositórios).
Sobre (/sobre): Uma página contando quem criou o projeto.
404: Uma página personalizada para links quebrados.

Requisito Extra (Parâmetro)

Crie uma página de Perfil de Repositório (/repo/:id) que deve ser aberta ao clicar em um item da lista. Essa página só precisa exibir o ID que foi clicado por enquanto.

O que avaliar?

Configuração correta do BrowserRouter no main.jsx ou App.jsx.
Uso exclusivo de <Link> para navegação em menus.
Funcionamento correto dos parâmetros de URL com useParams.

Projeto 16 - App Final Full-Stack Integrador 🏆

Objetivo: O "TCC (Trabalho de Conclusão de Curso)" do desenvolvedor Full-Stack.

O Tema

Escolha um tema que resolva um problema real integrando o que você construiu no Backend (Módulos 1-3) com o que aprendeu no Frontend (Módulo 4).

Requisitos Mínimos

Backend (Express): Uso obrigatório de rotas protegidas por JWT e validação de dados.
Frontend (React): Componentização clara, uso de Hooks (useState, useEffect) e navegação com React Router.
Integração: O Frontend deve consumir a sua própria API de forma assíncrona.
UX/UI: Interface amigável, com tratamento de estados de carregamento e erro.
Segurança: Configuração correta de CORS e Headers de segurança (Helmet).

Documentação ✨

Seu repositório no GitHub deve ter um README.md impecável, com imagens (prints) da aplicação, explicação das tecnologias usadas e instruções claras de como rodar o servidor e o cliente. Este projeto será o seu maior cartão de visitas!

Boa sorte e bom código! 🚀🚀🚀

Quizzes

Quizzes Interativos 🧠

Teste seus conhecimentos rapidamente ao final de cada módulo.

Fase 1 ---
Fase 2 ---
Fase 3 ---
Fase 4 ---

Quiz 01 - Introdução

1. Qual a principal característica de uma arquitetura Monolítica?

É composta por vários serviços independentes

O sistema é um único bloco de código onde tudo está acoplado

É escrita apenas em JavaScript

Não utiliza banco de dados *Explicação: No monólito, todas as funcionalidades residem em um único processo e base de código.*

2. Qual vantagem é mais associada aos Microsserviços?

Simplicidade de deploy inicial

Baixo custo de infraestrutura

Escalabilidade granular e isolamento de falhas

Facilidade em depurar logs centralizados *Explicação: Microsserviços permitem escalar apenas a parte do sistema que precisa de mais fôlego (ex: pagamentos).*

3. O que é "Escalabilidade Horizontal"?

Aumentar a memória RAM de um único servidor

Adicionar mais máquinas ou instâncias para dividir a carga

Trocar o banco de dados SQL por NoSQL

Aumentar o tamanho das tabelas *Explicação: É o ato de adicionar mais "trabalhadores" ao sistema ao invés de aumentar o poder de um só (vertical).*

4. Qual o papel de uma API (Application Programming Interface)?

Criar o design da interface do usuário

Permitir a comunicação e troca de dados entre sistemas

Servir como o sistema operacional do servidor

Substituir o banco de dados *Explicação: APIs são os contratos de comunicação entre o backend e seus clientes ou outros serviços.*

5. Sobre Microsserviços, o que significa ser "Poliglota"?

Falar várias línguas humanas

A liberdade de usar diferentes linguagens/tecnologias para cada serviço

Rodar apenas em servidores internacionais

Usar apenas tradução automática nas rotas *Explicação: Um serviço pode ser em Node.js e outro em Java, dependendo da necessidade técnica.*

6. Qual destas ferramentas é usada para testar requisições para uma API sem precisar de frontend?

Photoshop

Postman / Insomnia

Excel

Docker *Explicação: Clients HTTP como o Postman permitem enviar verbos como GET, POST, etc., e ver a resposta direta.*

7. O que acontece se um módulo de um monólito tiver um "Memory Leak" crítico?

Apenas aquele módulo para de funcionar

O banco de dados se apaga automaticamente

Provavelmente todo o sistema ficará instável ou sairá do ar

O sistema migra sozinho para microsserviços *Explicação: Como tudo roda no mesmo processo, falhas críticas afetam o bloco inteiro.*

8. Qual o formato de dados mais comum usado hoje para comunicação entre serviços?

XML

JSON

CSV

TXT *Explicação: O JSON é leve, legível por humanos e o padrão de facto para APIs REST.*

9. Por que Microsserviços são considerados mais complexos operacionalmente?

Porque exigem mais linhas de código

Devido à necessidade de monitorar muitos serviços, redes e consistência distribuída

Porque só funcionam com Linux

Porque requerem hardware da NASA *Explicação: Manter 50 serviços conversando entre si exige muito mais automação e observabilidade.*

10. Qual ferramenta ajuda a garantir que o ambiente de desenvolvimento seja idêntico ao de produção?

Git

Postman

VS Code

Docker (Containerização) *Explicação: O Docker isola o serviço e suas dependências em um container que roda igual em qualquer lugar.*

Quiz 02 - Introdução

1. O que acontece na comunicação síncrona (Sync)?

O serviço envia a mensagem e esquece

O serviço envia a requisição e aguarda a resposta para continuar

A comunicação só ocorre via rádio

O banco de dados é desligado *Explicação: No modelo síncrono, a execução fica bloqueada até que o destino retorne o dado.*

2. Qual o principal perigo da comunicação síncrona em excesso?

O código fica muito curto

Cascateamento de falhas (um serviço lento trava todos os outros)

Economia exagerada de memória

O sistema fica rápido demais *Explicação: Se um serviço na cadeia falhar ou demorar, todos os serviços "acima" dele também sofrerão.*

3. Qual a função do API Gateway?

Armazenar as senhas dos desenvolvedores

Atuar como ponto único de entrada para roteamento e segurança

Substituir o roteador Wi-Fi da empresa

Processar scripts de interface visual *Explicação: O Gateway centraliza preocupações transversais como autenticação, log e roteamento.*

4. O que é "Rate Limiting"?

Aumentar a velocidade da internet

Limitar a quantidade de requisições que um cliente pode fazer em um tempo

Cobrar por cada clique no botão

Diminuir a fonte do texto *Explicação: Rate limiting protege o sistema contra abusos ou ataques de negação de serviço (DoS).*

5. No Service Discovery, como os serviços são localizados?

Por endereços IP fixos escritos no código

Via um registro dinâmico que mantém os endereços atualizados

Através de busca no Google

Usando GPS *Explicação: Em ambientes elásticos (Docker/K8s), os IPs mudam sempre, exigindo um "Discovery" dinâmico.*

6. Qual o papel do "Load Balancer"?

Medir o peso dos servidores físicos

Distribuir a carga de trabalho entre várias instâncias do mesmo serviço

Equilibrar o gasto de energia

Organizar as pastas do projeto *Explicação: Ele garante que nenhuma instância fique sobrecarregada enquanto outras estão ociosas.*

7. O que caracteriza a comunicação Assíncrona (Async)?

Uso obrigatório de cabos de fibra ótica

O uso de mensageria (filas) onde o chamador não espera a resposta imediata

Comunicação em tempo real por vídeo

Bloqueio total do banco de dados *Explicação: É ideal para processos longos ou para aumentar a resiliência do sistema.*

8. O que é um "Circuit Breaker" (Disjuntor)?

Um fusível físico no servidor

Um padrão que interrompe chamadas para um serviço falho para evitar sobrecarga

Um hacker que invade sistemas

O botão de desligar do computador *Explicação: Ele protege o sistema impedindo que requisições inúteis sejam feitas a um serviço que já se sabe estar fora do ar.*

9. Qual destas é uma responsabilidade típica de um Gateway?

Desenhar o logo da empresa

Compilar código C++

Agregação de respostas e Autenticação

Formatar o HD do servidor *Explicação: O Gateway pode unir dados de 3 serviços diferentes e entregar um único JSON ao frontend.*

10. Qual ferramenta é comumente usada para implementar Service Discovery?

Microsoft Word

Netflix Eureka / Consul

Adobe Photoshop

WhatsApp *Explicação: Eureka e Consul são soluções populares para gerenciar a agenda de serviços em microsserviços.*

Quiz 03 - Introdução

1. O que significa o termo "Stateless" no REST?

O servidor armazena o estado do cliente em variáveis globais

O servidor não guarda informações sobre sessões anteriores; cada requisição é independente

O app não precisa de internet para funcionar

O banco de dados nunca muda *Explicação: Stateless garante que o servidor possa escalar horizontalmente sem se preocupar em sincronizar sessões de usuários entre máquinas.*

2. Qual a regra de ouro para nomear URIs no REST?

Usar verbos de ação (ex: /getUsers)

Usar letras maiúsculas para destacar

Usar substantivos no plural (ex: /usuarios)

Colocar a senha do usuário na URL *Explicação: URIs devem representar recursos (coisas), e não ações. A ação é definida pelo Verbo HTTP.*

3. Qual verbo HTTP deve ser usado para criar um novo recurso?

GET

POST

PUT

DELETE *Explicação: O POST é o método padrão para submeter dados para a criação de novos recursos no servidor.*

4. Qual a diferença fundamental entre PUT e PATCH?

PUT é mais rápido que PATCH

PATCH remove o recurso e PUT cria um novo

PUT substitui o recurso inteiro, enquanto PATCH faz atualizações parciais

Não há diferença, ambos fazem a mesma coisa *Explicação: Use PUT para "trocar" o objeto todo e PATCH para mudar apenas um campo (ex: mudar apenas o preço de um produto).*

5. Qual código de status indica que um recurso foi criado com sucesso?

200 OK

201 Created

204 No Content

404 Not Found *Explicação: O 201 é específico para sinalizar que o POST resultou na criação física de um novo elemento.*

6. O que significa ser um método "Idempotente"?

Que ele gasta muita energia

Que múltiplas requisições idênticas têm o mesmo efeito que uma só

Que ele só funciona com números inteiros

Que ele apaga o banco de dados *Explicação: GET, PUT e DELETE são idempotentes. Se você deletar o mesmo ID 10 vezes, o resultado final (o recurso não existir) é o mesmo.*

7. Por que o JSON é preferido em relação ao XML em APIs modernas?

Porque ele é colorido

Porque é mais leve, menos verboso e mais fácil de ler/processar em JS

Porque o XML foi proibido pelo Google

Porque JSON aceita emojis e XML não *Explicação: O JSON tem uma sintaxe muito mais limpa e mapeia quase diretamente para objetos em linguagens modernas.*

8. O que o status code 403 Forbidden indica?

Que a página não existe

Que o usuário não está logado

Que o usuário está logado, mas não tem permissão para aquele recurso

Que o servidor explodiu *Explicação: Diferente do 401 (sem login), o 403 diz que você é conhecido, mas "não tem entrada permitida aqui".*

9. Em REST, o que compõe uma Interface Uniforme?

Usar a mesma cor em todos os botões

Uso de URIs para recursos, métodos HTTP padrão e representações de dados (JSON/XML)

Ter apenas um arquivo de código para tudo

Usar apenas um tipo de fonte de texto *Explicação: É o conjunto de regras que torna a API previsível e fácil de aprender por outros desenvolvedores.*

10. Qual a função do cabeçalho "Content-Type" em uma requisição?

Dizer o nome do autor da API

Informar ao servidor qual o formato dos dados que estão sendo enviados (ex: application/json)

Aumentar a segurança da senha

Definir a cor de fundo do site *Explicação: Sem o Content-Type, o servidor pode não saber como interpretar o corpo (body) da mensagem recebida.*

Quiz 04 - Introdução

1. O que é o OpenAPI (OAS)?

Uma linguagem de programação para backend

Uma especificação padrão para descrever e documentar APIs RESTful

Um navegador web para desenvolvedores

Um banco de dados em nuvem *Explicação: O OpenAPI define um formato padrão para descrever recursos, rotas e respostas de uma API.*

2. Qual a principal diferença entre OpenAPI e Swagger?

Swagger é pago e OpenAPI é gratuito

OpenAPI é a especificação e Swagger é o conjunto de ferramentas (UI, Editor, etc)

OpenAPI foi substituída pelo Swagger em 2021

Não há diferença, são nomes para a mesma cor *Explicação: Pense no OpenAPI como as "regras" e no Swagger como as "ferramentas" que usam essas regras.*

3. Para que serve o Swagger UI?

Para editar o banco de dados diretamente

Para gerar uma página visual e interativa onde se pode testar os endpoints documentados

Para compilar o código Java para o servidor

Para baixar músicas gratuitas *Explicação: O Swagger UI lê o arquivo YAML/JSON e cria uma interface amigável para humanos.*

4. Qual o objetivo principal de um "Mock de API"?

Substituir o backup do sistema

Simular o comportamento de uma API real para permitir o desenvolvimento paralelo

Aumentar a segurança contra vírus

Esconder o endereço IP do servidor *Explicação: Mocks permitem que o Frontend programe contra um servidor "de mentira" enquanto o real não está pronto.*

5. O que significa "Developer Experience" (DX)?

O tempo que o desenvolvedor gasta jogando videogame

A facilidade e satisfação de um desenvolvedor ao usar sua ferramenta ou API

A quantidade de memória RAM do monitor

O nome do sistema operacional dos servidores *Explicação: Uma boa DX significa documentação clara, erros úteis e facilidade de integração.*

6. Qual formato de arquivo é mais utilizado para escrever especificações OpenAPI?

.html

.yaml ou .json

.docx

.pdf *Explicação: YAML é preferido por ser mais legível por humanos e suportar identação clara.*

7. Por que retornar mensagens de erro explicativas no corpo da resposta (Body) é uma boa prática?

Para o log ficar mais colorido

Para ajudar o consumidor da API a entender exatamente o que errou sem precisar perguntar ao autor

Porque o HTTP obriga a escrever textos longos

Para ocupar mais espaço no servidor *Explicação: Um erro `400` com a mensagem `"Data de nascimento é obrigatória"` economiza horas de suporte.*

8. Qual componente do Swagger permite digitar e validar a especificação da API em tempo real?

Swagger Hub

Swagger Editor

Swagger Inspector

Swagger Play *Explicação: O Editor valida a sintaxe YAML e mostra o preview da documentação instantaneamente.*

9. Em qual fase do projeto o "Design de Contrato" deve ocorrer?

Somente no fim do projeto para arquivar

No início, antes mesmo de começar a codificar as rotas (API First)

Apenas se o cliente pedir

Nunca, é perda de tempo *Explicação: No API First, o contrato é acordado primeiro para que as equipes de Front e Back trabalhem em sintaxe.*

10. Qual ferramenta pode ser usada para subir um mock server local a partir de uma collection?

Microsoft Excel

Postman / Mockoon

Notepad++

Windows Paint *Explicação: Postman e Mockoon facilitam a criação de respostas estáticas baseadas em rotas.*

Quiz 05 - Introdução

1. Qual a principal responsabilidade da camada de Controller?

Salvar dados no banco de dados

Gerenciar a requisição HTTP e retornar a resposta adequada

Fazer cálculos complexos de impostos

Criar a interface gráfica do usuário *Explicação: O Controller age como um intermediário entre o mundo externo (HTTP) e a lógica interna do sistema.*

2. O que é um "Handler" em um sistema de rotas?

Um tipo de vírus de computador

A função específica que é executada quando uma rota é chamada

O nome do servidor de hospedagem

O arquivo onde guardamos as senhas *Explicação: Cada rota (Verbo + Path) é mapeada para um Handler que processa aquela ação específica.*

3. Qual a melhor forma de capturar o ID de um usuário para uma busca individual (ex: /usuarios/10)?

Query Param (?id=10)

Path Param (/usuarios/:id)

Request Body ({ "id": 10 })

Através de um cookie *Explicação: Path Params são ideais para identificar recursos de forma única e hierárquica na URI.*

4. Quando devemos usar "Query Params"?

Para enviar a senha do usuário

Para filtros, ordenação e paginação (ex: ?cor=azul)

Para atualizar o nome de um produto

Para deletar o banco de dados *Explicação: Query Params são usados para modificar ou filtrar a representação dos dados retornados.*

5. Em qual objeto da requisição costuma vir o JSON enviado via POST?

req.params

req.query

req.body

req.headers *Explicação: O Body é a parte da mensagem HTTP reservada para o transporte de dados complexos e volumosos.*

6. Qual analogia melhor define o papel do Controller?

O cozinheiro que prepara o prato

O garçom que anota o pedido e entrega o prato

O dono do restaurante que cuida do banco de dados

O cliente que come a comida *Explicação: O Controller apenas coordena a entrada e a saída, delegando a "preparação" para outras camadas.*

7. Por que a Injeção de Dependência é útil nos Controllers?

Para o código ficar mais pesado e seguro

Para facilitar a troca de comportamentos e a criação de testes automatizados

Para economizar espaço no HD

Porque o Google obriga *Explicação: Receber dependências prontas torna o Controller menos acoplado e mais fácil de manter.*

8. O que acontece se o Controller não retornar um Status Code?

O servidor explode

O cliente pode receber um status padrão (ex: 200) que não condiz com o resultado real

O computador trava

A internet cai *Explicação: É vital ser explícito sobre o que aconteceu (201 para sucesso, 400 para erro, etc).*

9. Onde configuramos o mapeamento de Verbo + Path no backend?

No banco de dados

No arquivo de roteamento (Router)

No arquivo de interface (CSS)

Dentro do arquivo de imagem .png *Explicação: O roteador é quem diz: "Se chegar esse verbo nesse caminho, chame essa função".*

10. Qual a vantagem de padronizar as respostas de erro em JSON?

Para o erro ficar mais bonito

Para que o frontend consiga ler a mensagem e exibir um alerta amigável ao usuário

Para economizar bateria do servidor

Para esconder o código do erro *Explicação: Um JSON de erro estruturado permite que o app reaja de forma inteligente a falhas.*

Quiz 06 - Introdução

1. O que acontece se colocarmos toda a lógica de negócio dentro do Controller?

O app fica mais rápido

O código fica difícil de testar, manter e reutilizar (o famoso "Controller Gordo")

O banco de dados se apaga sozinho

O roteamento para de funcionar *Explicação: Acoplar lógica de negócio ao transporte HTTP cria dívida técnica e dificulta a evolução do sistema.*

2. Qual a principal responsabilidade do Service?

Definir as rotas do app

Executar as regras de negócio, validações e cálculos

Gerar as respostas JSON para o cliente

Configurar a porta do servidor *Explicação: O Service é onde o conhecimento do domínio da aplicação (as regras do "negócio") reside.*

3. Como um Service deve notificar o Controller sobre uma falha de validação?

Retornando um número 400

Lançando uma exceção ou erro (throw Error)

Enviando um e-mail para o administrador

Mudando a cor do console *Explicação: O lançamento de erros permite que o Controller capture o fluxo e decida qual resposta HTTP enviar.*

4. Por que o Service não deve acessar os objetos `req` ou `res`?

Porque eles são secretos

Para manter o Service independente do protocolo de transporte (podendo ser usado em gRPC, CLI, etc)

Porque isso gasta muita internet

Para economizar linhas de código *Explicação: A camada de serviço deve ser "cega" para o transporte, focando apenas nos dados e regras.*

5. O que define uma "Regra de Negócio"?

O nome das variáveis do sistema

As diretrizes que ditam como o serviço deve operar (ex: "só maiores de 18 podem comprar")

O tipo de servidor onde o app está rodando

A cor do logotipo da empresa *Explicação: Regras de negócio são as "leis" do funcionamento daquela aplicação específica.*

6. Qual a vantagem de reutilizar um Service em diferentes Controllers?

Nenhuma, é melhor copiar o código

Consistência: a regra é aplicada da mesma forma em todo o sistema

Economiza espaço de memória no disco

Deixa o site mais colorido *Explicação: Centralizar a regra no Service garante que, se a lei mudar, você só precisa alterar em um lugar.*

7. O que é um DTO (Data Transfer Object)?

Um tipo de cabo para conectar servidores

Um objeto simples usado para transportar dados entre camadas sem expor a lógica interna

O nome do motor de busca do Google

Um comando do terminal Linux *Explicação: DTOs ajudam a filtrar campos sensíveis (como senhas) antes de enviá-los ao mundo externo.*

8. O que significa "Separation of Concerns" (Separação de Preocupações)?

Cada desenvolvedor deve trabalhar sozinho

Cada camada do sistema deve ter uma responsabilidade única e bem definida

O banco de dados deve ficar em outro país

O site deve ter várias cores diferentes *Explicação: Dividir o sistema em Controller, Service e Repository é aplicar esse princípio fundamental.*

9. Qual o momento ideal para chamar o Service dentro de uma rota?

Antes de receber a requisição

Após o Controller validar os parâmetros básicos de entrada

Depois que a resposta já foi enviada ao cliente

Nunca, o Controller deve fazer tudo *Explicação: O Controller "limpa" a entrada e passa os dados "puros" para o Service processar.*

10. Como o Controller deve tratar o retorno de um Service?

Ignorando o resultado

Capturando o dado retornado e devolvendo em um JSON com Status 200/201

Pedindo para o usuário reiniciar o computador

Exibindo o código fonte na tela *Explicação: O Controller é o tradutor final que comunica o sucesso ou erro do Service para o cliente HTTP.*

Quiz 07 - Introdução

1. Qual a função do PostgreSQL em uma arquitetura backend?

Criar a interface visual

Armazenar dados de forma persistente e relacional

Enviar e-mails automaticamente

Compilar o código Javascript *Explicação: O PostgreSQL é um Sistema de Gerenciamento de Banco de Dados (SGBD) que garante que os dados não se percam.*

2. O que significa a sigla CRUD?

Create, Remove, Update, Delete

Create, Read, Update, Delete

Clear, Read, Unit, Deploy

Code, Run, Update, Debug *Explicação: CRUD representa as quatro operações básicas de manipulação de dados em qualquer sistema.*

3. Qual o comando SQL usado para buscar dados em uma tabela?

INSERT

UPDATE

SELECT

DELETE *Explicação: O SELECT é o comando fundamental para realizar consultas no banco de dados.*

4. Para que serve o padrão Repository?

Para salvar arquivos PDF no servidor

Para isolar a lógica de acesso ao banco da lógica de negócio

Para criar rotas no Express

Para acelerar o download do app *Explicação: O Repository centraliza as chamadas ao banco, facilitando a troca de tecnologia sem afetar o resto do sistema.*

5. O que é uma Primary Key (Chave Primária)?

A senha master do servidor

Um identificador único para cada registro (linha) em uma tabela

O nome da tabela principal

O primeiro campo de um formulário HTML *Explicação: A PK garante que não existam dois registros idênticos e facilita a busca rápida.*

6. Quando usamos uma Foreign Key (Chave Estrangeira)?

Para traduzir o banco de dados

Para criar um link (relacionamento) entre duas tabelas diferentes

Para encriptar os dados

Para mudar o nome das colunas *Explicação: A FK é o que permite conectar, por exemplo, um Pedido ao Usuário que o realizou.*

7. O que acontece se rodarmos um `DELETE FROM usuarios` sem a cláusula `WHERE`?

O banco pede confirmação

Todos os registros da tabela "usuarios" serão apagados!

Apenas o primeiro registro é apagado

O comando dá erro de sintaxe *Explicação: Sem o WHERE, o comando afeta todas as linhas da tabela. Muito cuidado!*

8. O que são "Migrations"?

Pessoas que mudam de país

Arquivos que versionam a estrutura do banco de dados (schema)

A troca de servidor de hospedagem

Um tipo de loop em Javascript *Explicação: Migrations garantem que todos os desenvolvedores tenham a mesma versão da estrutura do banco.*

9. Qual o tipo de relacionamento quando um Autor pode escrever vários livros?

1:1 (Um para um)

1:N (Um para muitos)

N:N (Muitos para muitos)

N:1 (Muitos para um) *Explicação: Um único recurso pai (Autor) está ligado a múltiplos recursos filhos (Livros).*

10. Por que o Service deve chamar o Repository em vez de rodar SQL direto?

Para o código ficar mais longo

Para seguir o princípio de responsabilidade única e facilitar testes

Porque SQL é uma linguagem antiga

Porque o computador processa Services mais rápido *Explicação: Separar as camadas torna o sistema modular: o Service dita O QUE fazer, o Repository sabe COMO buscar.*

Quiz 08 - Introdução

1. Por que o backend nunca deve confiar nos dados vindos do frontend?

Para economizar bateria do servidor

Porque a requisição pode ter sido interceptada, alterada ou burlada

Porque o frontend é sempre feito por iniciantes

Porque os navegadores são lentos *Explicação: Segurança baseada em "confiança" no cliente é uma vulnerabilidade grave.*

2. Qual a diferença entre Validar e Sanitizar?

Validar limpa o dado, Sanitizar checa a regra

Validar checa se o dado está correto, Sanitizar "limpa" o dado de impurezas (espaços, tags HTML)

São a mesma coisa com nomes diferentes

Validar é para banco SQL, Sanitizar é para NoSQL *Explicação: Validar diz "SIM ou NÃO", Sanitizar diz "AGORA ESTÁ LIMPO".*

3. Para que servem bibliotecas como Zod ou Joi?

Para acelerar a conexão com o banco

Para definir e aplicar esquemas de validação de forma declarativa e robusta

Para desenhar gráficos no painel do administrador

Para comprimir arquivos PDF *Explicação: Essas bibliotecas removem o excesso de "if/else" e centralizam as regras de entrada.*

4. O que é o princípio DRY (Don't Repeat Yourself)?

Beber água durante o código

Evitar a duplicação de lógica, transformando repetir em funções ou serviços únicos

Escrever o código o mais rápido possível

Não usar a tecla Backspace *Explicação: Código repetido é difícil de manter; se a regra muda, você esquece de atualizar em algum lugar.*

5. O que um Middleware de Erro Global faz?

Impede que o computador trave

Captura qualquer erro não tratado e envia uma resposta padronizada ao cliente

Apaga os logs do servidor

Avisa o usuário que a internet caiu *Explicação: Centralizar o erro evita que o servidor "morra" e permite um tratamento profissional de falhas.*

6. Por que NÃO devemos enviar o Stack Trace (detalhes técnicos do erro) para o usuário final?

Porque gasta muitos dados de internet

Por segurança, pois revela detalhes da estrutura do banco e do código (ajuda hackers)

Porque o usuário não entende inglês

Porque o Stack Trace é feio *Explicação: Informações técnicas sobre o erro devem ser logadas internamente, nunca expostas publicamente.*

7. Qual a vantagem de usar nomes de funções altamente descritivos?

O código fica mais colorido no editor

Melhora a legibilidade e facilita a manutenção por outros desenvolvedores (ou por você no futuro)

O compilador processa nomes longos mais rápido

Ocupa menos espaço no servidor *Explicação: Código deve ser lido como um livro; o nome da função deve dizer exatamente O QUE ela faz.*

8. O que caracteriza um Erro 400 (Bad Request)?

O servidor parou de funcionar

O cliente enviou dados inválidos ou incompletos que o sistema não aceita

O usuário não tem permissão para acessar

A página não existe *Explicação: Erros 400 indicam que a culpa é do "lado de lá" (cliente/requisição).*

9. O que caracteriza um Erro 500 (Internal Server Error)?

O usuário digitou a senha errada

Ocorreu uma falha inesperada na lógica ou infraestrutura do servidor

O link está quebrado

A conta do usuário foi deletada *Explicação: Erros 500 indicam que algo "quebrou" no backend e precisa de reparo.*

10. Como o Clean Code ajuda na escalabilidade de um projeto?

Comprimindo o banco de dados

Mantendo o código organizado e modular, facilitando a adição de novas funcionalidades

Diminuindo o preço da hospedagem

Aumentando o número de acessos simultâneos *Explicação: Um código limpo é como um quebra-cabeça bem encaixado; é fácil adicionar peças novas.*

Quiz 09 - Introdução

1. Qual a diferença entre Autenticação e Autorização?

Autenticação é sobre permissões, Autorização é sobre identidade

Autenticação checa quem você é, Autorização checa o que você pode fazer

Autenticação é para o backend, Autorização é para o frontend

É a mesma coisa, apenas nomes diferentes *Explicação: Primeiro você prova quem é (Login), depois o sistema checa se você tem acesso (Roles).*

2. O que significa a sigla JWT?

Java Web Tool

JSON Web Token

Javascript Web Transfer

Just Web Ticket *Explicação: É um padrão de mercado para transmissão segura de informações como objetos JSON.*

3. Quantas partes compõem um token JWT?

Uma parte única

Duas partes (Dados e Assinatura)

Três partes (Header, Payload e Signature)

Quatro partes (Header, Payload, Signature e Expire) *Explicação: As três partes são unidas por pontos para formar o token completo.*

4. O que é o "Payload" do JWT?

O algoritmo de criptografia

A senha do banco de dados

O corpo do token, onde ficam os dados do usuário (ex: id, nome)

A chave secreta do servidor *Explicação: É aqui que guardamos as "alegações" (claims) sobre o usuário logado.*

5. Por que a "Assinatura" (Signature) é a parte mais importante para a segurança?

Porque ela deixa o token colorido

Porque ela garante que o Payload não foi alterado por terceiros

Porque ela esconde o nome do usuário

Porque ela faz o token expirar mais rápido *Explicação: Se alguém mudar um único caractere no Payload, a assinatura deixará de ser válida.*

6. O que significa dizer que o JWT é "Stateless" (Sem Estado)?

Que o servidor não tem banco de dados

Que o servidor não precisa guardar informações da sessão do usuário na memória

Que o token nunca expira

Que o usuário não precisa de internet *Explicação: Toda a informação necessária para validar o usuário está dentro do próprio token.*

7. Onde o Payload do JWT pode ser lido?

Apenas pelo servidor que tem a chave secreta

Por qualquer pessoa, pois ele é apenas codificado (Base64), não encriptado

Apenas por usuários com permissão de Admin

Em lugar nenhum, ele é invisível *Explicação: CUIDADO! Nunca guarde senhas ou dados sensíveis no Payload, pois qualquer um pode ler.*

8. Qual o objetivo do campo "expiresIn" (ou 'exp')?

Mudar o nome do usuário

Definir um tempo de validade para o token, após o qual ele será rejeitado

Apagar o banco de dados

Aumentar a velocidade da API *Explicação: Tokens não devem ser eternos; limitando a duração, reduzimos riscos de roubo de sessão.*

9. Onde o frontend geralmente envia o JWT para o servidor?

No corpo da mensagem (Body)

No cabeçalho (Header) de autorização: `Authorization: Bearer `

No nome do arquivo

Por e-mail *Explicação: O padrão Bearer Token nos headers HTTP é a forma mais comum de enviar o JWT.*

10. O que acontece se o servidor perder a "Chave Secreta"?

Os usuários ganham acesso livre

Todos os tokens emitidos anteriormente se tornam inválidos instantaneamente

O banco de dados é deletado

Nada, a chave secreta não é importante *Explicação: Sem a chave, o servidor não consegue mais verificar se as assinaturas dos tokens são legítimas.*

Quiz 10 - Introdução

1. O que significa a sigla RBAC?

Real-Binary-Authentication-Code

Role-Based Access Control

Route-Based Authorization Check

Restricted-Backend-Access-Control *Explicação: É o padrão de mercado para gerenciar permissões baseadas em "perfis" ou "papéis" do usuário.*

2. No RBAC, a quem atribuímos as permissões de acesso?

A cada usuário individualmente por seu CPF

A um perfil (Role) que pode ser compartilhado por vários usuários

Apenas ao dono da empresa

Ao endereço IP do computador *Explicação: Atribuir a perfis facilita a manutenção, especialmente em sistemas com muitos usuários.*

3. Qual o código HTTP para "Acesso Negado" (Usuário identificado, mas sem permissão)?

401 Unauthorized

404 Not Found

403 Forbidden

500 Internal Error *Explicação: O 403 indica que o servidor entendeu quem é você, mas proibiu a ação.*

4. Qual a ordem correta dos middlewares em uma rota protegida?

Primeiro Autorização, depois Autenticação

Primeiro Autenticação, depois Autorização

Ambos devem rodar ao mesmo tempo

Apenas um é necessário *Explicação: Primeiro desvendamos QUEM é o usuário (Token), para depois checar O QUE ele pode fazer.*

5. O que um Middleware de Autorização faz se o usuário não tem o nível necessário?

Reinicia o servidor

Interrompe a requisição e retorna um erro 403 ao cliente

Envia a requisição para outra rota aleatória

Formata o banco de dados *Explicação: O middleware age como uma trava que impede a execução do código do Controller.*

6. Por que o Erro 401 (Unauthorized) é retornado quando o token JWT é inválido?

Porque o usuário é feio

Porque a identidade do usuário não pôde ser confirmada

Porque o servidor está desligado

Porque o sistema está em manutenção *Explicação: 401 significa "Quem é você? Não te conheço ou seu crachá é falso".*

7. Em um sistema de E-commerce, quem deve ter permissão para a rota `DELETE /produtos/:id`?

Todos os clientes

Apenas usuários com a Role 'ADMIN' ou 'GERENTE'

Qualquer pessoa sem login

Apenas o programador que criou o site *Explicação: Ações destrutivas devem ser restritas a perfis de alta confiança.*

8. O que é "Hierarquia de Roles"?

Uma lista de nomes em ordem alfabética

Quando perfis superiores (ex: Admin) herdam automaticamente as permissões de perfis inferiores

O tamanho da letra no banco de dados

A ordem de criação dos usuários *Explicação: Facilita o código, evitando ter que listar 'ADMIN' em todas as rotas simples.*

9. O que acontece se chamarmos a função `next()` dentro de um middleware?

O servidor para

O processamento passa para o próximo middleware ou para o Controller

O usuário é deslogado

Uma nova aba abre no navegador *Explicação: O `next()` é o sinal verde para a requisição seguir seu fluxo.*

10. Qual a principal vantagem de centralizar a autorização em middlewares?

O app fica mais bonito

Segurança e Reuso: você protege rotas inteiras com uma única linha de código

O banco de dados fica mais rápido

Os usuários ganham descontos *Explicação: Centralizar evita que você esqueça de colocar "if" em algum Controller, deixando brechas de segurança.*

Quiz 11 - Introdução

1. Por que não é recomendado que o Access Token dure muitos dias?

Porque ele ocupa muito espaço no servidor

Por segurança: se for roubado, o hacker terá acesso por pouco tempo

Porque o navegador apaga tokens longos automaticamente

Porque o Google não permite *Explicação: Tokens curtos minimizam o estrago em caso de vazamento de credenciais.*

2. Para que serve o Refresh Token?

Para mudar a senha do usuário

Para pedir um novo Access Token sem que o usuário tenha que digitar a senha novamente

Para aumentar a velocidade da internet

Para carregar imagens mais rápido *Explicação: Ele garante uma boa experiência de uso (UX) sem sacrificar a segurança.*

3. O que significa a sigla CORS?

Central-Order-Resource-System

Cross-Origin Resource Sharing

Code-Origin-Restriction-Safe

Chrome-Only-Response-System *Explicação: É o mecanismo que define quais sites externos podem acessar sua API.*

4. Quem aplica o bloqueio de CORS?

O Provedor de Internet

O Microprocessador do celular

O Navegador (Chrome, Firefox, Safari)

O Teclado do usuário *Explicação: O navegador bloqueia a leitura da resposta se o servidor não enviar os headers de permissão corretos.*

5. Qual a função da biblioteca Helmet?

Proteger o servidor contra quedas físicas

Configurar automaticamente diversos headers de segurança no HTTP

Aumentar o brilho da tela

Traduzir o app para inglês *Explicação: O Helmet ajuda a esconder detalhes do servidor e prevenir ataques como XSS.*

6. O que é "Rate Limiting"?

O limite de velocidade do Wi-Fi

Uma técnica para limitar o número de requisições que um usuário/IP pode fazer em um tempo

Quando o app fica lento de propósito

O limite de amigos que alguém pode ter *Explicação: É essencial para evitar ataques de força bruta (Brute Force) e ataques de negação de serviço (DoS).*

7. Por que devemos evitar `origin: '*'` no CORS em produção?

Porque o servidor fica pesado

Porque qualquer site malicioso do mundo poderia tentar roubar dados da sua API

Porque o Google penaliza sites assim

Porque os usuários não gostam *Explicação: O ideal é listar apenas os domínios oficiais que você confia.*

8. O que é o ataque XSS (Cross-Site Scripting)?

Quando o banco de dados é deletado

Quando um invasor consegue injetar scripts maliciosos em páginas vistas por outros usuários

Quando o cabo USB desconecta

Quando a senha é muito curta *Explicação: O invasor pode usar isso para roubar tokens ou cookies de outros usuários.*

9. Qual desses é o lugar mais seguro para guardar o Refresh Token no navegador?

localStorage

sessionStorage

Cookie com a flag HttpOnly

No histórico de navegação *Explicação: Cookies HttpOnly não podem ser lidos via Javascript, o que protege contra ataques XSS.*

10. O que acontece em um "Refresh Token Rotation"?

O token muda de cor

Sempre que um novo Access Token é pedido, o Refresh Token antigo é invalidado e um novo é gerado

O usuário é obrigado a trocar a senha

O servidor reinicia *Explicação: É uma camada extra de segurança para detectar se um Refresh Token foi roubado.*

Quiz 12 - Introdução

1. O que é o React?

Uma linguagem de programação nova

Uma biblioteca Javascript para criar interfaces de usuário (UIs)

Um banco de dados que roda no navegador

Uma ferramenta para editar imagens *Explicação: O React ajuda a criar sites dinâmicos e rápidos através de componentes.*

2. O que caracteriza uma Single Page Application (SPA)?

O site tem apenas uma página de texto simples

O site carrega apenas uma vez e troca o conteúdo dinamicamente sem recarregar a página inteira

É um app que só funciona em celulares antigos

É um site que não usa CSS *Explicação: SPAs dão uma experiência fluida de "navegação instantânea" ao usuário.*

3. No React, o que é um "Componente"?

Uma peça física do computador

Uma função Javascript que retorna uma parte da interface (Botão, Menu, Card)

Um erro que acontece no código

A cor de fundo do site *Explicação: Pensar em componentes é como pensar em peças de LEGO que se encaixam.*

4. Qual a função do Vite no desenvolvimento moderno?

Traduzir o site para chinês

Rodar um servidor de desenvolvimento ultra rápido e preparar o projeto para publicação

Criar logotipos automaticamente

Gerenciar a folha de pagamento da empresa *Explicação: O Vite substituiu ferramentas mais lentas, tornando o dia a dia do dev muito melhor.*

5. O que significa JSX?

Java Syntax eXtension

JavaScript XML: uma extensão de sintaxe que permite escrever algo parecido com HTML dentro do JS

Uma nova marca de TV

JavaScript Xtreme *Explicação: O JSX torna a criação de interfaces muito mais visual e fácil de ler.*

6. Qual a regra fundamental ao retornar conteúdo de um componente React?

Deve ter no máximo 10 linhas

Deve retornar apenas um único elemento pai (ou usar um Fragment)

Deve estar todo escrito em letras maiúsculas

Não pode conter números *Explicação: O React precisa de uma raiz única para conseguir montar a árvore de elementos corretamente.*

7. Para que servem as "Props" em um componente?

Para aumentar a performance do site

Para passar informações de um componente pai para um componente filho

Para salvar dados no banco de dados

Para mudar a senha do administrador *Explicação: Props são como "argumentos" que tornam o componente dinâmico e reutilizável.*

8. Por que usamos `className` em vez de `class` no JSX?

Porque `className` é mais bonito

Porque `class` é uma palavra reservada do Javascript para criar classes de objetos

Porque o HTML mudou de nome

Para economizar memória *Explicação: Como o JSX é Javascript, precisamos evitar conflitos com nomes que o JS já usa.*

9. O que é o "Virtual DOM" (Conceito)?

Uma simulação de videogame

Uma cópia em memória da interface que o React usa para saber exatamente o que atualizar na tela real

O nome do servidor da Microsoft

Um tipo de vírus de computador *Explicação: O Virtual DOM é o segredo da velocidade do React, evitando redesenhar a página toda sem necessidade.*

10. Como exibimos uma variável Javascript dentro do JSX?

Usando aspas duplas: "variavel"

Usando parênteses: (variavel)

Usando chaves: {variavel}

Usando um ponto de interrogação: ?variavel *Explicação: Tudo que estiver entre chaves { } no JSX será tratado como código Javascript puro.*

Quiz 13 - Introdução

1. O que acontece quando o valor de um "State" muda no React?

O computador reinicia

O React re-seta (redesenha) o componente na tela com os novos dados

O código Javascript é deletado

Nada, o desenvolvedor deve atualizar a tela manualmente *Explicação: A reatividade automática é um dos maiores poderes do React.*

2. Qual a forma correta de criar um estado para guardar um número?

let x = 0;

const x = 0;

const [x, setX] = useState(0);

val x by state(0); *Explicação: Usamos o "Array Destructuring" para pegar a variável e a função disparadora.*

3. Por que não podemos fazer `contador = contador + 1` diretamente?

Porque gasta muita energia

Porque o Javascript proíbe

Porque o React não ficará sabendo da mudança e não atualizará a tela

Porque isso apaga o banco de dados *Explicação: A função `set...` é quem avisa ao React que algo mudou.*

4. O que é um Hook?

Um erro CSS

Uma função especial (como useState) que permite "enganchar" recursos do React em componentes de função

Um tipo de cabo USB

O vilão do Peter Pan *Explicação: Hooks revolucionaram o React, removendo a necessidade de usar "Classes" complexas.*

5. Qual o evento correto para detectar o clique em um botão no React?

onclick

onClick (com o C maiúsculo)

click

on-press *Explicação: Eventos no React seguem o padrão CamelCase.*

6. Como você adiciona um novo elemento em um array de estado `lista` sem quebrar a imutabilidade?

lista.push(novo)

lista += novo

setLista([...lista, novo])

setLista(novo) *Explicação: Usamos o "Spread Operator" (...) para criar uma cópia da lista original com o novo item.*

7. Em um "Input Controlado", quem manda no valor que aparece na caixinha de texto?

O usuário

O Teclado

O Estado (State)

O CSS *Explicação: O valor do input é amarrado ao estado, garantindo que o JS tenha controle total do que é digitado.*

8. O que o parâmetro `e` em `onChange={(e) => ...}` representa?

Erro

Estilo

O Objeto de Evento que contém dados como `target.value`

Email *Explicação: O evento contém todas as informações sobre a interação que acabou de acontecer.*

9. Qual o valor inicial de `cont` em `const [cont, setCont] = useState(10)`?

0

null

10

undefined *Explicação: O valor dentro dos parênteses do useState define o ponto de partida.*

10. Se um componente pai muda seu estado, o que acontece com seus componentes filhos?

Eles param de funcionar

Eles também são re-renderizados pelo React

Eles ficam travados

Eles mudam de cor sozinhos *Explicação: O fluxo de dados no React é descendente; se o pai muda, a árvore abaixo dele se atualiza.*

Quiz 14 - Introdução

1. O que é um "Efeito Colateral" no React?

É um bug que trava o computador

Uma ação que acontece fora do fluxo normal de renderizar a interface (ex: buscar dados, timers)

É o nome de uma biblioteca de animação

É quando o CSS muda a cor do botão *Explicação: Efeitos saem do campo puro de "desenhar componentes" e tocam o mundo externo.*

2. Qual o segundo parâmetro do `useEffect`?

Um número inteiro

O array de dependências

O nome do componente

Um arquivo CSS *Explicação: Esse array decide quando o efeito deve ser re-executado.*

3. O que acontece se passarmos um array de dependências vazio `[]`?

O efeito nunca roda

O efeito roda em todo "re-render"

O efeito roda apenas uma vez, quando o componente é montado (aparece na tela)

O app fecha com erro *Explicação: É o padrão usado para buscar dados iniciais de uma API.*

4. Como fazemos para que um efeito rode toda vez que o estado `tema` mudar?

useEffect(() => { ... })

useEffect(() => { ... }, [])

useEffect(() => { ... }, [tema])

useEffect([tema], () => { ... }) *Explicação: Incluir a variável no array obriga o React a monitorá-la.*

5. O que a função `fetch()` retorna?

O dado final em formato JSON

Uma Promise (Promessa)

Um número de erro

Uma string de texto *Explicação: Chamadas de rede são assíncronas; o fetch promete que trará o dado no futuro.*

6. Para que serve o `.then(res => res.json())`?

Para salvar o dado no disco

Para fechar a conexão

Para converter a resposta bruta da rede em um objeto Javascript que possamos usar

Para criptografar os dados *Explicação: A resposta inicial é um objeto de rede; precisamos extrair o corpo dela em JSON.*

7. Qual a maneira correta de lidar com o estado de "Carregando"?

Usar um cronômetro de 5 segundos

Criar um estado booleano `isLoading` e exibi-lo enquanto a API não responde

Pedir para o usuário clicar em "Refresh"

Não precisa lidar, o React faz sozinho *Explicação: Feedback para o usuário é essencial para uma boa experiência (UX).*

8. O que acontece se você atualizar um estado dentro de um `useEffect` sem o array `[]`?

O estado não muda

Pode gerar um loop infinito (o efeito muda o estado, que re-renderiza, que roda o efeito...)

O site fica mais rápido

O computador reinicia *Explicação: Este é um dos erros mais comuns de iniciantes no React.*

9. Onde devemos colocar a chamada `fetch` para que ela não rode milhares de vezes sem necessidade?

Fora do componente

No meio do JSX

Dentro de um `useEffect` com dependências controladas

Dentro do CSS *Explicação: O useEffect isola a lógica de disparos de rede.*

10. Se quisermos limpar um timer ou fechar um socket quando o componente sumir da tela, onde fazemos isso?

Em outro componente

No `useState`

Na função de "cleanup" retornada pelo `useEffect`

Deletando o arquivo *Explicação: O useEffect permite retornar uma função que o React chama ao "desmontar" o componente.*

Quiz 15 - Introdução

1. O que é uma SPA (Single Page Application)?

Um site que só funciona em um navegador

Uma aplicação onde o HTML é carregado uma única vez e o Javascript troca o conteúdo da tela

Um site que não tem Javascript

Um aplicativo de celular que não usa internet *Explicação: SPAs oferecem uma experiência fluida, parecida com um app nativo, sem recarregamentos de página.*

2. Qual componente é obrigatório para envolver toda a aplicação que usará rotas?

*Explicação: Ele é o "contexto" que permite ao React monitorar a URL do navegador.*

3. Como definimos uma rota específica para a página de contato?

} />">} />

*Explicação: No React Router v6, usamos os atributos `path` e `element`.*

4. Por que não devemos usar a tag `` para navegar entre rotas no React?

Porque ela é proibida pelo Google

Porque ela gasta mais bateria

Porque ela causa um recarregamento total da página, perdendo o estado do React

Porque ela não aceita CSS *Explicação: O componente `` intercepta o clique para manter a troca de telas interna.*

5. Para que serve o caractere `*` no atributo `path`?

Para indicar uma rota secreta

Como um "coringa" para capturar qualquer URL que não foi definida anteriormente (Página 404)

Para multiplicar o número de páginas

Para aceitar qualquer tipo de arquivo *Explicação: É a forma padrão de lidar com links inexistentes.*

6. Qual hook usamos para capturar parâmetros da URL (ex: o ID em `/post/10`)?

useID()

useRoute()

useParams()

useQuery() *Explicação: Os parâmetros definidos com `:` na rota são extraídos por este hook.*

7. Como redirecionamos o usuário para a Home após ele clicar em um botão de "Sair"?

window.location.href = "/"

const navigate = useNavigate(); navigate("/");

useRoute("/") *Explicação: O hook `useNavigate` permite navegação via lógica de programação.*

8. O que acontece se removermos o componente `` e deixarmos apenas os ``?

O app continua funcionando

O React Router gerará um erro, pois os Route precisam estar dentro de um provedor de rotas

O site fica mais lento

O menu desaparece *Explicação: `` é o componente que escolhe qual rota renderizar baseada na URL atual.*

9. Em qual pacote extra encontramos as ferramentas de roteamento do React?

react-dom

react-router

react-router-dom

vite-plugin-router *Explicação: O `react-router-dom` é a versão específica para navegadores web.*

10. Como definimos um parâmetro dinâmico chamado `slug` na URL?

path="/blog/slug"

path="/blog/:slug"

path="/blog/{slug}"

path="/blog/*slug" *Explicação: O uso dos dois pontos (`:`) sinaliza que aquela parte da URL é uma variável.*

Quiz 16 - Introdução

1. Qual o principal objetivo do "Trabalho de Conclusão de Curso (TCC)" no TecPro?

Ganhar um prêmio em dinheiro

Consolidar o aprendizado em um projeto Full-Stack real para servir de portfólio para o mercado

Escrever o código mais longo do mundo

Criar um site que não use internet *Explicação: O projeto final prova que você sabe conectar o Frontend ao Backend com segurança.*

2. Por que o `README.md` no seu GitHub é considerado seu "Cartão de Visitas"?

Porque ele tem as cores da sua empresa

Porque é a primeira coisa que um recrutador ou tech lead olha para entender seu projeto

Porque ele apaga o resto do código

Porque o GitHub cobra se você não tiver um *Explicação: Um bom README com prints e tecnologias demonstra profissionalismo e clareza.*

3. Como você pode tornar seu projeto "impecável" para o mercado?

Colocando o máximo de animações possível, mesmo que trave

Usando rotas seguras, código limpo, tratamento de erros e um design organizado

Cobrando caro para as pessoas verem o código

Copiando o código de outro site sem mudar nada *Explicação: Qualidade técnica e atenção aos detalhes são o que diferenciam um júnior de um pleno.*

4. O que é o `TypeScript` (citado como próximo passo)?

Um novo tipo de processador

Uma linguagem que adiciona "tipos" ao Javascript, evitando erros comuns em tempo de desenvolvimento

O sucessor do HTML

Uma ferramenta para criar foguetes em 3D *Explicação: TypeScript é o padrão em grandes empresas para projetos robustos.*

5. O que significa ser um desenvolvedor `T-Shaped`?

Ter uma camiseta com estampa de código

Ter conhecimento amplo em várias áreas (Backend, Frontend, UX) e profundo em uma (ex: Node.js)

Programar apenas com a mão esquerda

Saber usar apenas uma linguagem de programação *Explicação: É o perfil mais valorizado pelas empresas modernas de tecnologia.*

6. Qual a importância das `Soft Skills` para um desenvolvedor Full-Stack?

Nenhuma, dev só precisa falar com o computador

Essencial para trabalhar em equipe, entender o cliente e explicar decisões técnicas

Serve apenas para quem trabalha no RH

É o nome de uma biblioteca de animação suave *Explicação: Software é feito por pessoas para pessoas. Saber se comunicar é vital.*

7. O que é o `Next.js`?

Um curso para aprender Javascript em 5 minutos

O framework React mais popular que permite criar sites rápidos com renderização no servidor (SSR)

O nome do navegador do Google

Uma versão do Javascript que roda apenas em smartwatches *Explicação: Next.js é a evolução natural para quem já domina os fundamentos do React.*

8. Como se manter atualizado em um mercado que muda todo mês?

Lendo livros de 20 anos atrás

Acompanhando documentações oficiais, comunidades, newsletters e praticando sempre

Esperando o chefe mandar estudar

Decorando todos os comandos de uma vez *Explicação: Estudo contínuo é parte fundamental da rotina de um desenvolvedor.*

9. O que fazer ao encontrar um bug impossível no seu código?

Chorar e desistir da carreira

Consultar a documentação, fóruns como StackOverflow, usar IA (com sabedoria) e debugar passo a passo

Apagar o Windows e reinstalar tudo

Ignorar o erro e avisar o usuário para não clicar ali *Explicação: Resolver problemas complexos é a alma do trabalho do programador.*

10. Qual a mensagem final do curso para o aluno?

Que agora você já sabe tudo e não precisa mais estudar

Que você construiu uma base sólida e agora tem o poder de criar soluções web completas

Que o mercado de programação vai acabar amanhã

Que o PHP é a única linguagem que existe *Explicação: O curso é apenas o início de uma carreira incrível e cheia de inovação.*

Slides

Slides 📺

Material visual para acompanhamento das vídeo-aulas.

Módulo 1 ---
Módulo 2 ---
Módulo 3 ---
Módulo 4 ---

Aula 01 - Introdução a Microsserviços 🌐

De Monólitos a Sistemas Distribuídos

Agenda de Hoje 📅

Panorama do Software Moderno
Monólitos vs Microsserviços
A Economia das APIs
Escalabilidade Vertical vs Horizontal
Cinto de Utilidades (Ferramentas)
Setup do Ambiente

1. O Mundo Cloud-Native ☁️

Sistemas globais exigem disponibilidade 24/7.
Milhões de requisições por segundo.
Deploy contínuo (várias vezes ao dia).

2. A Evolução da Arquitetura 🏛️➡️🏗️

2.1 O Monólito 🏛️

Um único projeto, um único deploy.
Tudo ou nada: erro em um lugar afeta tudo.
Difícil de escalar partes específicas.
Ideal para: Projetos pequenos, MVPs rápidos.

2.2 Microsserviços 🏗️

Conjunto de serviços independentes.
Comunicação via rede (APIs).
Cada um com seu banco de dados.
Ideal para: Sistemas complexos e escaláveis.

3. O Papel das APIs 📡

Contract-First: Acordo de comunicação.
REST como padrão dominante.
JSON: A língua universal.

Escalabilidade: Vertical vs Horizontal

Vertical (Scale Up)	Horizontal (Scale Out)
Aumenta CPU/RAM	Adiciona mais servidores
Tem limite físico	Virtualmente ilimitada
Causa downtime no upgrade	Zero downtime (Redundância)

Arquitetura de Microsserviços

graph LR
    User[Cliente] --> AGW[API Gateway]
    AGW --> S1[Usuários]
    AGW --> S2[Pedidos]
    AGW --> S3[Pagamentos]
    S1 --> DB1[(DB)]
    S2 --> DB2[(DB)]
    S3 --> DB3[(DB)]

4. Ferramentas Indispensáveis 🛠️

Client HTTP: Postman & Insomnia

Testar rotas sem Frontend.
Analisar Headers e Status Codes.
Simular diferentes cenários de erro.

Containerização: Docker 🐋

"Roda na minha máquina, roda em qualquer lugar".
Isola dependências e versões.
Facilita a subida de múltiplos serviços locais.

5. Estrutura de Projeto Backend 📂

Divisão clara de responsabilidades.
Controllers, Services e Repositories.
Tratamento global de exceções.

6. Setup do Ambiente 🚀

Requisitos:

IDE: VS Code ou IntelliJ.
Postman (Desktop ou Extensão).
Docker Desktop.
Git & GitHub.

Resumo da Aula ✅

Microsserviços trazem resiliência e escala.
APIs são o coração da comunicação moderna.
Ferramentas como Docker mudaram o jogo.
Começamos nossa jornada Fullstack!

Próxima Aula: Arquitetura e Gateway 🏗️

Como os serviços conversam?
O que é Service Discovery?
Protegendo a porta de entrada.

Dúvidas? 🤔

"A arquitetura de hoje é o legado de amanhã. Escolha com sabedoria."

Aula 02 - Arquitetura e Gateway 🏗️

Orquestrando Microsserviços

Agenda 📅

Comunicação entre Serviços
Síncrono vs Assíncrono
O Papel do API Gateway
Service Discovery
Load Balancing
Padrões de Resiliência

1. Como os Serviços Conversam? 💬

Microsserviços são ilhas que precisam de pontes.
Dois mundos: Sync e Async.

1.1 Comunicação Síncrona 🔄

Cliente bloqueia até a resposta.
Uso de HTTP/REST ou gRPC.
Risco: Acoplamento temporal e gargalos.

1.2 Comunicação Assíncrona 📬

Envia e esquece (Eventos).
Uso de Filas e Tópicos (Broker).
Vantagem: Escalabilidade e desacoplamento.

2. API Gateway: O Porteiro 🚪

Única entrada para o mundo exterior.
Esconde a complexidade interna.

Gateway Responsibilities

Roteamento: /p -> Pagamento, /e -> Estoque.
Segurança: Autenticação centralizada.
Rate Limit: Proteção contra flood.
Logs & Monitoramento.

3. Service Discovery 🔎

Onde está o servidor de pagamentos?
Agenda dinâmica de IPs e Portas.
Ferramentas: Netflix Eureka, Consul.

4. Load Balancing ⚖️

Distribuição inteligente da carga.
Evita que um container "morra" de trabalho.

graph TD
    GW[Gateway] --> LB[Load Balancer]
    LB --> S1[Serviço A]
    LB --> S2[Serviço B]
    LB --> S3[Serviço C]

5. Resiliência: Circuit Breaker 🔌

Detecta serviços lentos ou falhos.
Abre o circuito para proteger o resto do sistema.
Evita o cascateamento de erros.

Comparativo: Sync vs Async

Característica	Síncrono 🔄	Assíncrono 📬
Resposta	Imediata	Eventual
Desempenho	Limitado pelo destino	Alto débito
Uso comum	Cadastro/Login	Geração de Relatórios

6. Prática: O "Dashboard" Agregador 💻

Como o Gateway une dados de 3 serviços?
Agregação de respostas (Aggregation Pattern).

Desafio Relâmpago ⚡

O que acontece se o seu API Gateway cair? Ele é um ponto único de falha?

Resumo ✅

Sync é fácil, Async é escalável.
API Gateway protege e organiza.
Service Discovery é essencial em containers.
Resiliência não é opcional!

Próxima Aula: Modelagem REST 📡

Verbos HTTP.
Status Codes.
O contrato ideal.

Dúvidas? 🏗️

Aula 03 - Modelagem de APIs RESTful 📡

Recursos, Verbos e Contratos

Agenda 📅

O que é REST?
Recursos e URIs
Verbos HTTP (GET, POST, PUT...)
Status Codes
JSON: A Linguagem das APIs
Boas Práticas de Design

1. REST: A "Língua" da Web 🌐

Style arquitetural para sistemas distribuídos.
Baseado no protocolo HTTP.
Independência entre Client e Server.

Princípios REST

Stateless: Cada requisição é única.
Uniform Interface: Padrões compartilhados.
Cacheable: Melhore a performance.

2. Identificando Recursos 📍

Um recurso é qualquer coisa que expomos.
URI: O endereço do recurso.

O que NÃO fazer:

GET /obterUsuarios ❌

O que fazer:

GET /usuarios ✅ (Sempre substantivos no plural!)

3. Os Verbos HTTP 🛠️

Eles definem a intenção da chamada:

GET: Buscar dados.
POST: Criar novo dado.
PUT: Atualizar (Trocar tudo).
PATCH: Atualizar (Apenas um pedaço).
DELETE: Remover dado.

Idempotência e Segurança

Verbo	Seguro?	Idempotente?
GET	Sim ✅	Sim ✅
POST	Não ❌	Não ❌
PUT	Não ❌	Sim ✅
DELETE	Não ❌	Sim ✅

4. Status Codes: A Resposta 🚦

2xx: Deu certo! (200, 201, 204).
4xx: Você (cliente) errou algo (400, 401, 404).
5xx: Eu (servidor) quebrei (500, 503).

5. O Formato JSON 🏗️

{
  "nome": "Curso Backend",
  "modulo": 1,
  "ativo": true
}

Leve, legível e universal.

6. Design de URIs Complexas

Como buscar os pedidos de um usuário específico?

GET /usuarios/123/pedidos ✅

Hierarquia lógica e limpa.

7. Prática: Postman em Ação 💻

Testando verbos em APIs reais.
Analisando Headers e Body.

Desafio REST ⚡

Se você quer mudar apenas o e-mail de um usuário, qual verbo deve usar: PUT ou PATCH?

Resumo ✅

REST é sobre recursos e padrões.
URIs usam substantivos no plural.
Status codes guiam o frontend.
JSON é o padrão de facto.

Próxima Aula: Swagger e Mocks 📝

Documentação automática.
Como trabalhar sem o backend pronto?

Dúvidas? 📡

Aula 04 - Documentação e Mocks 📝

Developer Experience e Contratos

Agenda 📅

Por que documentar?
OpenAPI vs Swagger
Swagger UI e Editor
O Poder dos Mocks
Developer Experience (DX)
Ferramentas de Simulação

1. Documentação é DX 🚀

Sua API é seu produto.
Documentar economiza tempo de suporte.
Facilita a integração com Front/Mobile.

2. OpenAPI (OAS) 📜

O padrão mundial.
Arquivo YAML ou JSON descritivo.
Agnóstico de linguagem.

3. Swagger: O Canivete Suíço 🛠️

Editor: Escreva e valide o contrato.
UI: Gere a página visual de testes.
Codegen: Gere código (client/server) automaticamente.

Swagger UI em Ação

Permite testar endpoints no próprio navegador.
Mostra exemplos de JSON de entrada e saída.
Exibe todos os Status Codes possíveis.

4. O Poder dos Mocks 🎭

Development in Parallel: Front não espera pelo Back.
Servidor "Fake" que retorna dados reais.
Valide a experiência antes da implementação complexa.

5. Developer Experience (DX) 👨‍💻

Como ser amado por outros devs:

Nomes de rotas claros.
Erros descritivos no Body.
Exemplos de requisição.
Documentação atualizada (ou gerada pelo código).

6. Ferramentas Recomendadas 🧰

Swagger Editor: Online ou Local.
Mockoon: Mock local amigável.
Prism: Mock via CLI.
Postman: Collections documentadas.

7. Prática: Editando um YAML 💻

Desenhando um endpoint GET /tarefas.
Definindo parâmetros de entrada.
Criando esquemas de dados.

Desafio: Mock vs Stubs ⚡

Qual a principal vantagem de um Mock Server online (como Postman) em relação a um Mock rodando apenas no computador do desenvolvedor?

Resumo ✅

OpenAPI é o contrato.
Swagger UI é a vitrine da sua API.
Mocks destravam o desenvolvimento da equipe.
DX é o diferencial de uma boa API.

Próxima Aula: Implementação Backend! 💻

Módulo 2: Manipulação de Dados

Controllers e Services.
Repositories e Banco de Dados.
Mão na massa com código real!

Dúvidas? 📝

Aula 05 - Implementação de APIs ⚙️

Controllers e Rotas

Agenda 📅

Camadas do Backend
O Papel do Controller
Rotas e Handlers
Capturando Dados (Params/Body)
Status Codes na Prática
Injeção de Dependência

1. Organização em Camadas 🧱

Controller: Trata a entrada (HTTP).
Service: Regras de negócio.
Repository: Acesso ao banco.

2. O Papel do Controller 🎮

Ele é o ponto de entrada.
Não deve ter lógica complexa!
Deve apenas orquestrar a execução.

Controller = Garçom 🤵 Service = Cozinheiro 👨‍🍳

3. Rotas e Handlers 📍

Rota: Verbo HTTP + Path.
Handler: Função executada.

router.post('/login', controller.realizarLogin);

4. Capturando Dados 📥

Path Params: /id/123 (Identificação).
Query Params: ?q=busca (Filtro).
Body: Enviando JSON (Criação/Update).

5. Respostas de Qualidade 📤

Nunca esqueça o Status Code!
Sucesso: 200, 201, 204.
Erro: 400, 401, 404, 500.

6. Injeção de Dependência 💉

Receber serviços prontos.
Facilita testar o Controller "isolado".

7. Prática: O Primeiro Endpoint 💻

Mapeando um GET /ping.
Retornando um pong em JSON.
Testando no Insomnia/Postman.

Desafio: Params vs Query ⚡

Se você quer listar todos os alunos de uma sala com o nome "Pedro", qual tipo de parâmetro você usaria para o nome?

Resumo ✅

Controllers são a porta de entrada.
Devem ser leves e objetivos.
Capturam dados e retornam status/JSON.
Seguem as rotas definidas.

Próxima Aula: Regras de Negócio! 🧠

Services e Validações

Onde o cálculo acontece.
Isolando o código do "mundo externo".

Dúvidas? ⚙️

Aula 06 - Services e Regras de Negócio 🧠

O Cérebro da Aplicação

Agenda 📅

Por que separar as coisas?
Responsabilidades do Service
O Fluxo: Controller -> Service
Tratamento de Erros Profissional
DTOs: Protegendo os Dados
Service vs ViewModel (Mobile)

1. O Problema: "Controller Gordo" 🍔

Lógica de negócio misturada com HTTP.
Código impossível de reutilizar.
Difícil de testar.

2. A Solução: Layered Architecture 🧱

Controller: Trata o transporte (HTTP).
Service: Trata a regra (O QUE fazer).

3. O que vai no Service? ⚖️

Validações complexas.
Cálculos de valores.
Envio de e-mails/notificações.
Integração com repositórios.

4. Tratamento de Erros ⚠️

O Service Lança (Throws).
O Controller Captura (Catches).

// Service
if (!saldo) throw new Error("Saldo Insuficiente");

// Controller
try { ... } catch (e) { res.status(400)... }

5. DTOs: Filtrando a Saída 📦

Nunca envie "tudo" do banco para o cliente.
Proteja campos sensíveis (Ex: senha_hash).
Melhore a performance (menos dados trafegados).

6. Service vs ViewModel 🆚

No Backend: Service é o cérebro.
No Mobile/Front: ViewModel é o cérebro.
Ambos servem para "limpar" a camada de visualização.

7. Prática: Validando um Cadastro 💻

Verificando se o e-mail é válido.
Verificando se o usuário já existe.
Lançando erros específicos.

Desafio: Onde colocar? ⚡

Se uma regra diz: "Usuários VIP ganham 20% de desconto", essa regra deve ficar no Controller ou no Service?

Resumo ✅

Controllers recebem, Services processam.
Mantenha seus Controllers "finos" (Slim Controllers).
Centralize as regras para facilitar a manutenção.
DTOs são as fronteiras dos dados.

Próxima Aula: Onde os dados vivem! 🗄️

Repositories e Banco de Dados

PostgreSQL e SQL básico.
Camada de persistência.

Dúvidas? 🧠

Aula 07 - Repositories e Banco de Dados 🗄️

Onde a informação descansa

Agenda 📅

Por que Bancos de Dados?
PostgreSQL: O Robusto
SQL Básico (SELECT, INSERT...)
Relacionamentos (1:N, N:N)
Camada de Persistence
O Padrão Repository

1. Persistência de Dados 💾

Sem banco, o servidor esquece tudo ao reiniciar.
Precisamos de segurança e integridade.
Estritamente Tipado: O banco garante o formato.

2. Por que PostgreSQL? 🐘

Código Aberto (Open Source).
Extremamente confiável (ACID).
Suporta dados complexos (JSONB).

3. SQL: A Linguagem Universal 🗣️

-- Buscar usuários VIP
SELECT * FROM usuarios 
WHERE tipo = 'VIP' 
ORDER BY nome;

DDL: Define a estrutura (Tabelas).
DML: Manipula os dados (Linhas).

4. O Coração: Relacionamentos 🔗

1:N: Um cliente, muitos pedidos.
N:N: Muitos alunos, muitos cursos.
Foreign Key: A âncora que liga tudo.

5. Camada de Persistence 🧱

O código que conversa com o driver do banco.
Onde as queries são traduzidas para o código.

6. Padrão Repository 📥

"Não me diga como, diga O QUE você quer".
Isola o SQL da regra de negócio.

// No Service
userRepository.findByEmail(email);

7. Migrations 📜

Controle de versão para o Banco.
Permite "voltar no tempo" se algo quebrar.
Mantém o time em sincronia.

Desafio SQL ⚡

Qual comando você usaria para mudar o preço de todos os produtos da categoria 'Games' para 99.90?

Resumo ✅

Bancos de dados dão memória ao sistema.
PostgreSQL é o padrão da indústria.
SQL é habilidade obrigatória para backend.
Repository Pattern traz flexibilidade.

Próxima Aula: Integridade! ✅

Validação e Boas Práticas

Garantindo que dados "sujos" não entrem no banco.
Tratamento de exceções de banco.

Dúvidas? 🗄️

Aula 08 - Boas Práticas e Validação ✅

Qualidade e Segurança no Backend

Agenda 📅

Por que Validar Tudo?
Validação vs Sanitização
Schema Validation (Ex: Zod)
Clean Code (Código Limpo)
Tratamento de Erros Profissional
Middlewares Globais

1. Regra de Ouro: Desconfiança 🛡️

O cliente é o "lado perigoso" da aplicação.
Validações evitam dados corrompidos.
Defesa em Profundidade: Garanta a regra no banco E no código.

2. Validar vs Sanitizar 🧼

Validar: Checar (Idade > 18?).
Sanitizar: Limpar (Remover <script>).

3. Schema Validation 📐

Crie "moldes" para seus dados.
Validação centralizada e reutilizável.

const userSchema = {
    nome: string().min(3),
    email: string().email()
};

4. O Backend Elegante (Clean Code) ✨

DRY: Don't Repeat Yourself (Não repita lógica).
KISS: Keep It Simple, Stupid (Mantenha o simples).
Nomes de funções que explicam o que está acontecendo.

5. Tratamento de Erros 🚨

Controller trata o fluxo, não o detalhe técnico.
Try/Catch Global: Evite crashes.
Mensagens amigáveis para o cliente.

6. Logs vs Mensagens 📜

Terminal/Log: Detalhe técnico completo.
Cliente (JSON): Apenas o que ele precisa saber.

"Ocorreu um erro interno" (Cliente) ✅ "Query failed at line 42 due to NULL constraint" (Logs) ✅

7. Prática: O Schema Perfeito 💻

Validando um produto complexo.
Tratando erros de tipo (String no lugar de Number).

Desafio: Limpeza ⚡

Se você recebe um texto de um post com muitos espaços em branco no final, você deve Validar ou Sanitizar?

Resumo ✅

Backend robusto exige validação rigorosa.
Limpe os dados antes de salvar (Sanitize).
Middleware Global centraliza a gestão de falhas.
Código limpo economiza meses de manutenção.

Próxima Aula: Módulo 3! 🔐

Segurança e Autenticação

Quem é você? (Authentication).
O que você pode fazer? (Authorization).

Dúvidas? ✅

Aula 09 - Segurança e Autenticação com JWT 🔐

Portas trancadas e Crachás Digitais

Agenda 📅

Autenticação vs Autorização
O Fim das Sessões (Stateful)
O que é JWT?
Estrutura: Header, Payload, Signature
Fluxo de Login completo
Melhores Práticas de Segurança

1. Quem é Você? (Autenticação) 🚦

Validar a identidade do usuário.
Login e Senha.
Autorização: O que você PODE fazer? (Níveis de acesso).

2. Por que JWT? 🤔

Abordagem Stateless (Sem estado).
O servidor não guarda sessão na memória (escalável!).
Perfeito para Microserviços e Mobile.

3. Estrutura do Token 🎫

[Header].[Payload].[Signature]

Header: Algoritmo (ex: HS256).
Payload: Os dados (id, role, nome).
Signature: O lacre de segurança.

4. O Coração do JWT: A Assinatura 🖋️

Usa uma SECRET_KEY no servidor.
Garante que o token não foi "hackeado" ou alterado.

Envia credenciais -> 2. Servidor valida -> 3. Gera JWT -> 4. Frontend guarda o Token -> 5. Envia no Header em cada requisição.

6. Segurança em Mobile 📱

Nunca guarde em arquivos de texto!
Use EncryptedSharedPreferences (Android) ou Keychain (iOS).

7. Melhores Práticas 🏆

Use chaves secretas longas e seguras.
Defina tempo de expiração (expiresIn).
Protocolo HTTPS é obrigatório!

Desafio de Segurança ⚡

O Payload do JWT é criptografado ou apenas codificado? Posso guardar a senha do usuário lá?

Resumo ✅

JWT permite autenticação rápida e escalável.
Header + Payload + Signature.
Stateless = Servidor mais leve.

Próxima Aula: Controle de Acesso 🛡️

Quem manda aqui? (RBAC)

Middlewares de autorização.
Protegendo rotas por nível de usuário.

Dúvidas? 🔐

Aula 10 - Controle de Acesso (RBAC) 🛡️

Hierarquia e Segurança em Camadas

Agenda 📅

O que é RBAC? (Roles)
Autenticação vs Autorização
O Fluxo do Middleware
Erros 401 vs 403
Protegendo rotas na prática
Hierarquia de Perfis

1. Role-Based Access Control 👑

Permissões ligadas a Perfis (Roles).
Ex: ADMIN, EDITOR, VIEWER.
Facilita a gestão de milhares de usuários.

2. A Cancela (Middleware) 🚧

O middleware checa se o usuário tem a "chave" certa.
Se não tiver -> 403 Forbidden.
Se tiver -> next().

3. O Fluxo de Segurança 🌊

graph LR
    Req[Request] --> Auth[Autenticação]
    Auth --> |OK| Role[Autorização]
    Role --> |OK| Controller[Recurso Final]

4. 401 vs 403: Não confunda! ❌

401 (Unauthorized): "Quem é você?". Token inválido ou ausente.
403 (Forbidden): "Eu sei quem você é, mas não deixo entrar". Falta de permissão.

5. Implementação Dinâmica 🔒

// Middleware genérico
router.delete('/usuario/:id', 
    autenticar, 
    autorizar(['ADMIN']), 
    userController.remover
);

6. Hierarquia de Acesso 🏛️

Um Admin deve poder acessar rotas de User?
Design de sistema: Roles "Pai" e "Filho".

7. Melhores Práticas 🏆

Centralize a lógica em Middlewares.
Nunca exponha permissões sensíveis no frontend (segurança do lado do servidor).

Desafio: Segurança ⚡

Em um sistema escolar, o Diretor e o Professor podem ver notas. O Aluno só vê as dele. Como você configuraria a Role da rota GET /notas?

Resumo ✅

RBAC organiza permissões por grupos.
Middlewares são os guardiões das rotas.
Diferenciar 401 de 403 é vital para Debug.

Próxima Aula: Segurança Avançada 🏗️

Session vs Token e Refresh Tokens

O que fazer quando o token expira?
Protegendo contra ataques comuns (XSS, CSRF).

Dúvidas? 🛡️

Aula 11 - Refresh Token e Segurança Avançada 🏗️

Blindando sua API contra o mundo

Agenda 📅

O Problema do Token Curto ⏰
Refresh Tokens (O que são?)
CORS: Origens e Destinos
Helmet: Headers de Aço
Rate Limit: Contra Brute Force
Ataques Comuns (XSS, Injection)

1. Por que Tokens Expiram? ⏰

Segurança! Se roubarem o token, ele dura pouco.
Problema: O usuário odeia fazer login toda hora.

2. Refresh Token 🔁

Um token de longa duração (7 dias+).
Serve apenas para trocar por um novo Access Token.
Deve ser invalidado se o usuário deslogar.

"Quem pode me chamar?".
Resolvido via Headers no Servidor.
Nunca use origin: '*' em ambientes reais!

4. Helmet: Proteção de Headers 🪖

Remove o X-Powered-By (não diz que é Express).
Adiciona proteção contra Clickjacking e XSS.

5. Rate Limiting 🔨

5 tentativas de login por minuto? Sim.
Evita que robôs tentem descobrir senhas via "força bruta".

6. Onde salvar os Tokens? 🛡️

Frontend: LocalStorage? Seguro?
Melhor Prática: Cookies HttpOnly + Secure.

7. Melhores Práticas de Segurança 🏆

Use HTTPS sempre.
Valide TODAS as entradas do usuário.
Mantenha as bibliotecas atualizadas.

Desafio de Segurança ⚡

Qual a diferença entre 401 e 403 no contexto de Refresh Tokens? Se eu recebo 401, eu tento o refresh ou deslogo o usuário?

Resumo ✅

Refresh Token equilibra UX e Segurança.
CORS e Helmet são as portas do seu castelo.
Proteja-se contra robôs com Rate Limit.

Próximo Módulo: Front-End Moderno 🎨

Saindo das APIs e indo para a Web!

Introdução ao React/Vite.
Consumindo nossas APIs no navegador.

Dúvidas? 🏗️

Aula 12 - Introdução ao React ⚛️

O Poder dos Componentes Modernos

Agenda 📅

O que são SPAs?
Por que React?
Vite: A Ferramenta Rápida
JSX: JS + HTML
Componentes e LEGO
Props: O Coração Dinâmico

1. Single Page Applications (SPA) 📄

O site que nunca recarrega.
Navegação fluida e instantânea.
Ex: Gmail, Facebook, Spotify Web.

2. Por que o React venceu? ⚔️

Componentização (Foco no Reuso).
Virtual DOM (Foco na Performance).
Gigantesco Ecossistema (Foco no Emprego).

3. Vite: O Novo Padrão ⚡

Inicia o projeto em segundos.
Feedback instantâneo durante o código.

4. JSX: A Mistura Perfeita 🧪

function Titulo() {
  const nome = "React";
  return <h1>Olá, {nome}!</h1>;
}

Parece HTML, mas tem o poder do Javascript.

5. Componentes = LEGO 🧩

Pequenas partes isoladas.
Facilita testes e trabalho em equipe.

6. Props: Passando o Bastão 🎁

Permite que componentes recebam dados do "pai".
Torna componentes genéricos e reutilizáveis.

Resumo ✅

SPA torna a Web parecida com Apps.
React organiza sua UI em componentes.
Vite é seu melhor amigo no desenvolvimento.

Próxima Aula: Dinâmica e Estado 🎣

O que acontece quando o usuário clica?

Hooks: useState.
Reatividade na prática.

Dúvidas? ⚛️

Aula 13 - Estado e Hooks 🎣

Tornando seu App Interativo

Agenda 📅

O que é o Estado (State)?
Hook useState
Lidando com Cliques e Eventos
Inputs Controlados
Imutabilidade e Arrays

1. O Problema da Estática 🧱

Variáveis comuns mudam nos bastidores...
...mas a tela continua a mesma!
O React precisa de um sinal para re-desenhar.

2. useState: O Motor de Mudança 🚀

const [cont, setCont] = useState(0);

cont: O valor atual.
setCont: A função que atualiza.
0: O ponto de partida.

3. Eventos no React ⚡

onClick={funcao}
onChange={(e) => ...}
Sempre em CamelCase!

4. Inputs Controlados ⌨️

O React é quem manda no valor do input.
value={estado} + onChange.
Facilita validação e limpeza de campos.

5. Imutabilidade (Muito Importante!) 💎

Nunca altere o estado original: lista.push(x) ❌
Sempre crie uma cópia nova: setLista([...lista, x]) ✅

6. Fluxo de Dados 🌊

O estado flui do Pai para o Filho via Props.
Se o estado do Pai muda, todo mundo abaixo dele atualiza.

Desafio de Estado ⚡

Se eu tenho um botão que soma +1 ao contador, o que acontece com a interface se eu esquecer de importar o useState e usar uma variável global let contador = 0?

Resumo ✅

useState traz vida aos componentes.
Mudança de estado = Re-renderização.
Use sempre funções disparadoras (set...).

Próxima Aula: Efeitos e APIs 🌐

Buscando dados no mundo real!

Hook: useEffect.
Consumindo nossa API Backend.

Dúvidas? 🎣

Aula 14 - Efeitos e APIs 🌐

Conectando seu App ao Mundo Real

Agenda 📅

O que são Side Effects?
Hook useEffect
O Array de Dependências
Buscando dados com fetch
Estados de Carregamento e Erro

1. Além da Interface 🧪

Efeitos colaterais são ações que tocam o mundo externo ao componente.
Ex: Buscar usuários, mudar o título da aba, iniciar um cronômetro.

2. useState vs useEffect 🥊

useState: Para dados que o usuário vê mudando.
useEffect: Para ações que o componente faz "sozinho".

3. Os 3 Momentos do useEffect 🕒

Montagem: Quando o componente nasce.
Atualização: Quando um dado monitorado muda.
Desmontagem: Quando o componente morre (Cleanup).

4. O Array de Dependências `[]` 🗃️

[] -> Roda só uma vez.
[cont] -> Roda sempre que cont mudar.
Sem array -> Roda em toda atualização (Perigo!).

5. Chamadas de API (Fetch) 📨

useEffect(() => {
  fetch("https://api...")
    .then(res => res.json())
    .then(data => setData(data));
}, []);

6. UX: Estados de Rede 🛡️

Loading: Mostre um Spinner enquanto espera.
Error: Avise se a internet caiu ou o usuário não existe.
Empty: Diga se não há resultados.

Desafio de Efeito ⚡

Se você colocar um alert("Olá") dentro de um useEffect sem o array [], quantas vezes o alerta vai aparecer se o usuário ficar digitando em um campo de texto que atualiza o estado?

Resumo ✅

useEffect organiza as ações assíncronas.
Controle quando rodar via array de dependências.
Trate sempre o carregamento e erros para uma boa UX.

Próxima Aula: Navegação 🚦

Multi-páginas com React Router!

/home, /perfil, /contato.
Links e Navegação Programática.

Dúvidas? 🌐

Aula 15 - React Router 🚦

Criando Apps Multi-Página

Agenda 📅

O que são SPAs?
Multi-páginas (Simuladas)
Componentes de Rota
Navegação (Link e useNavigate)
Parâmetros dinâmicos (:id)

1. O Mundo do SPA ⚛️

O site é uma única página HTML.
O Javascript "troca" a tela sem recarregar.
UX rápida e fluida.

2. React Router Dom ⚙️

npm install react-router-dom

A biblioteca padrão para web.
Permite que a URL combine com o que aparece na tela.

3. A Estrutura Básica 🏗️

BrowserRouter: O container principal.
Routes: O seletor de rotas.
Route: Define o caminho (path) e o componente (element).

4. Navegando sem Recarregar! 🏃‍♂️

Use <Link to="/contato">
NUNCA use <a href="..."> para rotas internas.

5. Navegação Programática 🚀

const navigate = useNavigate();

onClick={() => navigate("/dashboard")}

Ideal para redirecionar após ações (Login, Clique em Card).

6. Rotas Dinâmicas (URL Params) 🆔

path="/perfil/:username"
Hook useParams() captura o valor.
Uma única página que se adapta a mil perfis.

7. Página 404 (Not Found) 👻

path="*"
Garante que o usuário nunca caia em uma tela em branco.

Desafio de Roteamento ⚡

Se eu digitar www.meusite.com/asdfg e não tiver uma rota configurada para isso, o que o usuário vai ver se eu NÃO colocar uma rota com o path="*"?

Resumo ✅

Roteamento traz a sensação de um site real.
Hooks useNavigate e useParams são essenciais.
SPAs são o padrão da indústria moderna.

Próxima Aula: O Grande Final 🏆

Projeto Integrado: Backend + Frontend!

Conectando nossa API Node ao site React.
O Projeto Final do Curso!

Dúvidas? 🚦

Aula 16 - Projeto Final e Conclusão �

De aluno a Desenvolvedor Full-Stack

Agenda 📅

O Desafio Final 🔗
Requisitos Técnicos
Portfólio no GitHub
Onde continuar estudando?
Mensagem de Encerramento

1. O Desafio Final 🚀

Você deve entregar um projeto integrado contendo: - Frontend: SPA em React com rotas. - Backend: API segura em Node.js. - Integração: Conexão real entre os dois. - Design: CSS moderno e responsivo.

2. Sugestões de Temas 💡

Gerenciador de Tarefas �
Mini E-commerce 🛒
Rede Social Simplificada 💬
Dashboard de Monitoramento 📊

3. O README de Elite ✨

Prints ou Vídeos do site funcionando.
Lista detalhada de tecnologias.
Guia: "Como rodar o Projeto".

4. Onde ir agora? 📚

TypeScript: Segurança de tipos.
Bancos SQL: Postgres e MySQL.
Next.js: O rei do mercado React.
Docker: Infraestrutura moderna.

5. Soft Skills 🤝

Não é só saber programar!
Trabalho em equipe.
Resolução de problemas reais.

6. O Mercado Full-Stack 📈

Demanda altíssima por devs completos.
Salários excelentes.
Dashboards e Sistemas Web movem o mundo!

7. Mensagem Final 🌟

"Programar é a arte de criar soluções onde antes só havia problemas."

Você construiu a base sólida.
O código é sua ferramenta de transformação.

Parabéns pela Jornada! 🎓🚀

Vá e construa o futuro da Web.

Dúvidas Finais? 🤔

Configuração

Ambientes de Desenvolvimento 🛠️

Guias para configurar seu computador para o desenvolvimento mobile.

Android --- Instalação do Android Studio, SDK e emuladores.
- Setup 01 - Android Studio
iOS (Opcional/Referência) --- Configuração básica de Xcode e ferramentas Mac.
- Setup 02 - Xcode Foundation
Ferramentas de Apoio --- Git, Terminais e Postman/Insomnia para testes de API.
- Setup 03 - Tools

Setup 01: Android Studio 🤖

O Android Studio é a IDE oficial para o desenvolvimento Android.

1. Requisitos de Sistema

RAM: Mínimo 8GB (Sugerido 16GB+).
Espaço: Mínimo 10GB para IDE + SDKs.
Processador: Intel Core i5 ou equivalente.

2. Instalação

Acesse o site oficial: developer.android.com/studio.
Baixe a versão mais recente para o seu Sistema Operacional.
Execute o instalador e escolha a opção "Standard" na configuração inicial.

3. Configurando o SDK

Após a instalação, vá em Settings > Languages & Frameworks > Android SDK.
Certifique-se de que a versão mais recente do Android (estável) esteja instalada.
Na aba SDK Tools, instale o "Android Emulator" e o "Intel x86 Emulator Accelerator (HAXM)" se estiver no Windows com Intel.

4. Criando um Emulador (AVD)

Abra o Device Manager.
Clique em Create Device.
Escolha um dispositivo (ex: Pixel 7).
Selecione uma imagem de sistema (ex: Level 34 - Android 14).
Finalize e clique no "Play" para iniciar o celular virtual.

5. Solução de Problemas ⚠️

VT-x is disabled: Você precisa habilitar a virtualização na BIOS do seu computador.
Studio muito lento: Adicione a pasta do projeto e as pastas do Android SDK nas exclusões do seu Antivírus.

Setup 02: Xcode (iOS Foundation) 🍎

O Xcode é a ferramenta necessária para compilar e testar apps iOS.

[!IMPORTANT] O Xcode requer um computador Mac (macOS).

1. Instalação

Abra a App Store no seu Mac.
Pesquise por Xcode.
Clique em Obter/Instalar.
Após o download, abra o Xcode para carregar os componentes adicionais do macOS.

2. Configurando Simuladores

Vá em Settings > Platforms.
Verifique se o componente "iOS" está baixado.
Se não estiver, clique em "GET" para baixar a versão mais estável.

3. Comandos de Linha (CLI)

Para que ferramentas de automação funcionem, você precisa instalar os Command Line Tools:

xcode-select --install

4. Opcional: CocoaPods

Muitos projetos iOS antigos ainda usam CocoaPods para dependências:

sudo gem install cocoapods

5. Solução de Problemas ⚠️

Espaço em Disco: O Xcode é muito grande. Garanta pelo menos 40GB de espaço livre para ele e os simuladores.
Build Lento: Use simuladores de modelos mais simples (ex: iPhone SE) para poupar memória RAM se necessário.

Sobre

Sobre o Curso

🎓 APIs e Microsserviços Profissionais

Este curso foi projetado para capacitar desenvolvedores na criação de arquiteturas distribuídas modernas, focando na integração entre backends escaláveis e frontends dinâmicos do tipo SPA.

🎯 Objetivos do Curso

Arquitetura Distribuída --- Compreender a transição de monólitos para microsserviços e a importância da comunicação eficiente entre serviços.
Domínio de APIs REST --- Dominar a modelagem, implementação e documentação de APIs seguindo as melhores práticas do mercado.
Segurança Avançada --- Implementar sistemas de autenticação e autorização robustos utilizando JWT e controle de acesso baseado em perfis.
Frontend Moderno (SPA) --- Desenvolver interfaces ricas e reativas, conectando-as perfeitamente ao ecossistema de APIs backend.

📚 O Que Você Vai Aprender

Módulo 1 – Serviços e Microsserviços

Conceitos de Microsserviços vs Monólitos
Arquitetura e API Gateways
Modelagem de APIs RESTful
Documentação com Swagger e Mocks

Módulo 2 – Manipulação de Dados

Implementação de Endpoints (Backend)
Persistência com ORM e SQL
Testes Unitários com Mocks
Testes Integrados e Deploy

Módulo 3 – Autenticação e Segurança

Estratégias Web (Cookies vs Tokens)
Implementação de JWT
Criptografia e Proteção de Rotas
Autorização RBAC (Perfis)

Módulo 4 – Aplicações Web SPA

Conceitos de SPA e Renderização
Componentização e Templates
Gerenciamento de Estados e Eventos
Roteamento e Projeto Integrador

🛠️ Metodologia

Foco 100% prático e orientado a projetos. Cada módulo culmina em uma etapa funcional de um sistema completo, garantindo que ao final do curso você tenha um portfólio robusto de arquitetura fullstack.

Pronto para dominar o Backend? Começar Agora

Roadmap do Projeto: APIs e Microsserviços 🚀

Este documento rastreia a evolução do curso.

✅ Fase 1: Planejamento (Concluído)

[x] Definição Syllabus (16 Aulas)
[x] Estrutura Backend-first com integração SPA
[x] Configuração MkDocs Material

✅ Fase 2: Conteúdo Base (Concluído)

[x] Criação das 16 Aulas (Markdown)
[x] Criação dos 16 Quizzes (HTML)
[x] Criação dos 16 Conjuntos de Exercícios
[x] Criação dos 16 Slides (RevealJS)

✅ Fase 3: Projetos e UX (Concluído)

[x] Definição dos 16 Projetos práticos
[x] Documentação Swagger/OpenAPI integrada
[x] Diagramação Mermaid de arquitetura de serviços

🚀 Fase 4: Lançamento e Manutenção

[x] Deploy GitHub Pages (GitHub Actions)
[ ] Atualização para novas versões de frameworks (Spring/Node/React)
[ ] Inclusão de exemplos de mensageria (RabbitMQ/Kafka)

Status Atual: Finalizado / Manutenção Última Atualização: 19/02/2026

Materiais Complementares 📚

Bem-vindo à seção de materiais complementares do curso de APIs e Microsserviços. Aqui você encontra recursos adicionais para apoiar seus estudos e aprofundar seu conhecimento técnico.

Slides
- Acompanhe o conteúdo teórico com slides dinâmicos.
Exercícios
- Pratique a implementação de microsserviços e rotas REST.
Quizzes
- Valide seu aprendizado com testes rápidos por módulo.
Projetos
- Construa um ecossistema completo para seu portfólio.
Ambiente
- Guias de instalação (Docker, IDEs, Postman).

Versão para Impressão

Esta página foi gerada automaticamente para impressão.

Desenvolvimento de APIs e Microsserviços 💻

🎯 O Que Você Vai Aprender

📚 Jornada de Aprendizado (16 Aulas)

🧱 Módulo 1: Serviços e Microsserviços (Aulas 01-04)

🏗️ Módulo 2: CRUD e Persistência (Aulas 05-08)

🔌 Módulo 3: Autenticação e Segurança (Aulas 09-11)

🚀 Módulo 4: Aplicações Web SPA (Aulas 12-16)

Plano de Ensino 📅

Ementa

Cronograma (16 Aulas)

Módulo 1: Serviços e Microsserviços

Módulo 2: Manipulação de Dados via APIs REST

Módulo 3: Autenticação e Autorização

Módulo 4: Aplicações Web SPA

Avaliação

Aulas

Aula 01 - Introdução a Serviços e Microsserviços 🌐

1. O que são Serviços e Microsserviços? 🧩

🏛️ O Monólito

🏗️ Os Microsserviços

2. Comparativo: Monólito vs Microsserviços ⚖️

Visualização de Arquitetura (Mermaid)

3. A Economia das APIs 📡

4. Ferramentas Essenciais 🛠️

5. Estrutura de um Projeto Moderno 📂

Visão de Pastas (Padrão Backend)

6. Mini-Projeto: Configurando o Cinto de Utilidades 🚀

7. Exercício de Fixação 🧠

Aula 02 - Arquitetura de Microsserviços e API Gateway 🏗️

1. Comunicação entre Serviços 💬

🔄 Comunicação Síncrona (Sync)

📬 Comunicação Assíncrona (Async)

2. O Papel do API Gateway 🚪

Responsabilidades do Gateway:

3. Service Discovery e Load Balancing 🔍⚖️

🔎 Service Discovery

⚖️ Load Balancing (Balanceamento de Carga)

4. Padrões de Resiliência: Circuit Breaker 🔌

5. Mini-Projeto: Simulando um Gateway 🚀

6. Exercício de Fixação 🧠

Aula 03 - Modelagem de APIs RESTful 📡

1. O que é REST? 🧊

Princípios Fundamentais:

2. Recursos e URIs 📍

3. Verbos (Métodos) HTTP 🛠️

4. Códigos de Status (HTTP Status Codes) 🚦

5. O Formato JSON 🏗️

6. Mini-Projeto: Desenhando um Contrato ✍️

7. Exercício de Fixação 🧠

Aula 04 - Documentação (Swagger) e Mock de APIs 📝

1. Por que documentar APIs? 🧐

Benefícios:

2. OpenAPI e Swagger 🛠️

3. O Poder dos Mocks 🎭

O que é um Mock?

Ferramentas de Mock:

4. Developer Experience (DX) 🚀

5. Estrutura de Documentação Profissional 📂

6. Mini-Projeto: Criando Documentação no Swagger 🚀

7. Exercício de Fixação 🧠

Aula 05 - Implementação de APIs (Controllers e Rotas) ⚙️

1. A Camada de Controller 🎮

2. Anatomia de uma Rota 📍

Exemplo (Conceitual):

3. Capturando Dados do Cliente 📥

4. O Objeto de Resposta (Response) 📤

5. Injeção de Dependência (Introdutório) 💉

6. Mini-Projeto: Dashboard de Usuários 👥

7. Mini-Projeto: Criando seu primeiro Controller ⌨️

7. Exercício de Fixação 🧠

Aula 06 - Services e Regras de Negócio 🧠

1. Por que usar Services? 🏗️

2. A Responsabilidade do Service ⚖️

3. O Fluxo de Execução 🌊

4. Tratamento de Erros Profissional ⚠️

5. ViewModels e DTOs (Data Transfer Objects) 📦

🆚 Comparação: MVVM (Mobile/Frontend)

6. Mini-Projeto: Refatorando para Service 🛠️

7. Exercício de Fixação 🧠

Aula 07 - Repositories e Banco de Dados (PostgreSQL) 🗄️

2. O Hook `useState` 🎣

2. O Hook `useEffect` 🕒