Pular para conteúdo

Aplicação Full Stack 🌐

Build Status

Curso avançado focado na arquitetura de Microsserviços, desenvolvimento de APIs RESTful profissionais e frontends modernos utilizando o padrão SPA (Single Page Application).

🔗 Acesse o curso online: https://ricardotecpro.github.io/ads_proj_aplicacao_full_stack

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

  • Configuração do Projeto ---

    1. Clone o repositório: 
      git clone https://github.com/ricardotecpro/ads_proj_aplicacao_full_stack.git
cd ads_proj_aplicacao_full_stack
    2. Instale as dependências: 
      npm install
    3. Inicie o ambiente de desenvolvimento: 
      npm start
      Ver Projetos

📚 Jornada de Aprendizado (16 Aulas)

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

🧱 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)

Começar Minha Jornada Fullstack

Plano de Ensino 🧭

Curso: Plano Mestre - Curso Modular
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Plano Mestre - Curso Modular.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Introdução a Serviços e Microsserviços Teoria, Prática Guiada, Quiz e Exercícios
02 Arquitetura de Microsserviços e API Gateway ️ Teoria, Prática Guiada, Quiz e Exercícios
03 Modelagem de APIs RESTful Teoria, Prática Guiada, Quiz e Exercícios
04 Documentação (Swagger) e Mock de APIs Teoria, Prática Guiada, Quiz e Exercícios
05 Implementação de APIs (Controllers e Rotas) ️ Teoria, Prática Guiada, Quiz e Exercícios
06 Services e Regras de Negócio Teoria, Prática Guiada, Quiz e Exercícios
07 Repositories e Banco de Dados (PostgreSQL) ️ Teoria, Prática Guiada, Quiz e Exercícios
08 Boas Práticas e Validação de Dados Teoria, Prática Guiada, Quiz e Exercícios
09 Segurança e Autenticação com JWT Teoria, Prática Guiada, Quiz e Exercícios
10 Controle de Acesso (RBAC) e Permissões ️ Teoria, Prática Guiada, Quiz e Exercícios
11 Refresh Token e Segurança Avançada ️ Teoria, Prática Guiada, Quiz e Exercícios
12 Introdução ao Frontend Moderno (React) ️ Teoria, Prática Guiada, Quiz e Exercícios
13 Estado e Reatividade (Hooks) Teoria, Prática Guiada, Quiz e Exercícios
14 Efeitos e Chamadas de API (useEffect) Teoria, Prática Guiada, Quiz e Exercícios
15 Navegação com React Router Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Final e Conclusão Teoria, Prática Guiada, Quiz e Exercícios
17 Integração Avançada Frontend/Backend com WebSockets Teoria, Prática Guiada, Quiz e Exercícios
18 Gestão de Estado de Aplicação Full Stack e Caching Distribuído Teoria, Prática Guiada, Quiz e Exercícios
19 Testes E2E de Ponta a Ponta Integrados Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Aplicação Full Stack Production-Ready Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Plano Mestre - Curso Modular.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado em 5 módulos estruturados.

📚 Módulos do Curso

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:

  1. Client HTTP (Postman/Insomnia): Para testar endpoints sem precisar de um frontend.
  2. Docker: Para "empacotar" seus serviços e garantir que rodem em qualquer máquina.
  3. Git/GitHub: Para versionamento e colaboração.
  4. 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:

  1. Instalar o Visual Studio Code (ou IntelliJ CE).
  2. Instalar o Postman ou a extensão Thunder Client no VS Code.
  3. Instalar o Docker Desktop.
  4. 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:

  1. Explique o conceito de "Escalabilidade Horizontal" no contexto de microsserviços.
  2. Qual a função de um API Gateway em um sistema distribuído?
  3. 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:

  1. Roteamento: Encaminha a requisição para o serviço correto (ex: /users vai para User-Service).
  2. Autenticação: Verifica se o usuário está logado antes de passar a bola para os serviços internos.
  3. Rate Limiting: Impede que um cliente faça requisições demais e derrube o sistema.
  4. 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. Simulação de API Gateway no Terminal 💻

O Gateway recebe uma requisição central e a distribui para os serviços internos.

# Requisição para o Gateway (Porta 8080)
$ curl http://localhost:8080/users
# O Gateway redireciona internamente para User-Service (Porta 3001)
> Roteando para: http://internal-service:3001/users

$ curl http://localhost:8080/orders
# O Gateway redireciona internamente para Order-Service (Porta 3002)
> Roteando para: http://internal-service:3002/orders

6. Mini-Projeto: Simulando um Gateway 🚀

Vamos simular o comportamento de um Gateway usando o Postman:

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

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

6. Exercício de Fixação 🧠

  1. Qual a diferença entre um API Gateway e um Load Balancer?
  2. Explique o problema do "Cascateamento de Falhas" em comunicações síncronas.
  3. 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:

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

🏛️ Arquitetura Client-Server (Mermaid)

graph LR
    C[Client - SPA] -- "Request (HTTP + JSON)" --> S[Server - API]
    S -- "Response (Status + JSON)" --> C

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"]
}

🖥️ Testando Verbos no Terminal

# Listar produtos
$ curl -X GET http://localhost:3000/produtos

# Criar um produto
$ curl -X POST http://localhost:3000/produtos -d '{"nome": "Mouse"}'

# Deletar um produto
$ curl -X DELETE http://localhost:3000/produtos/123

6. Mini-Projeto: Desenhando um Contrato ✍️

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

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

7. Exercício de Fixação 🧠

  1. Diferencie PUT de PATCH com um exemplo prático.
  2. Por que não devemos usar verbos nas URIs (ex: /deletarUsuario/123)?
  3. 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.

🔄 Fluxo de Desenvolvimento Paralelo (Mermaid)

Com contratos bem definidos, o time de Frontend não precisa esperar o Backend terminar.

graph TD
    Contract[Contrato OpenAPI] --> Frontend[Time Frontend]
    Contract --> Backend[Time Backend]
    Frontend --> Mock[Usa API Mock]
    Backend --> Real[Cria API Real]
    Mock -.-> Real[Troca p/ API Real quando pronta]
# 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.

🎭 Simulando Mocks no Terminal

# Rodando um servidor de Mock a partir de um arquivo OpenAPI
$ npx prism mock storage.yaml

# Acessando o endpoint mockado
$ curl http://localhost:4010/produtos
> [{"id": 1, "nome": "Produto Mockado"}]

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:

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

7. Exercício de Fixação 🧠

  1. Qual a diferença entre a Especificação OpenAPI e a Ferramenta Swagger?
  2. Como o uso de Mocks pode acelerar o cronograma de um projeto de software?
  3. 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).

Analogia: 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!

🗺️ O Papel do Controller (Mermaid)

graph LR
    User([Usuário]) -- Request --> C[Controller]
    C -- "Call Service (Cozinha)" --> S[Service]
    S -- "Data (Prato)" --> C
    C -- "JSON Response" --> User

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 👥

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

Testando com cURL (Terminal)

$ curl -X GET http://localhost:3000/usuarios
[{"id": 1, "nome": "Ricardo"}]

$ curl -X POST http://localhost:3000/usuarios -d '{"nome": "Ana"}'
{"status": "Criado"}

7. Exercício de Fixação 🧠

  1. Por que o Controller não deve conter regras de negócio (ex: cálculo de desconto)?
  2. Qual a diferença prática entre usar um Query Param e um Path Param?
  3. 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.

Fluxo de Comunicação (Mermaid)

graph LR
    Client([Cliente]) -- HTTP Request --> Controller([Controller])
    Controller -- Call Logic --> Service([Service])
    Service -- Return Result --> Controller
    Controller -- HTTP Response --> Client

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: Componentes no Frontend

Para quem já desenvolveu no Frontend, o Service no Backend é similar ao papel de um Hook customizado ou uma Store de Estado: ambos concentram a lógica de negócio e os dados, permitindo que a "View" (ou o Controller no nosso caso) foque apenas na interação/transporte.

Migrações no Terminal (Exemplo)

$ npx knex migrate:make criar_tabela_usuarios
Created: 20240101_criar_tabela_usuarios.js

$ npx knex migrate:latest
Batch 1 run: 1 migrations

5. 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 🧠

  1. O que acontece com a manutenção do sistema se um Service for reaproveitado por dois Controllers diferentes?
  2. Por que o Service não deve saber que o req e o res do Express existem?
  3. 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.

🔗 Diagrama de Relacionamento (Mermaid)

erDiagram
    USUARIO ||--o{ PEDIDO : "realiza"
    PEDIDO ||--|{ ITEM_PEDIDO : "contém"
    PRODUTO ||--o{ ITEM_PEDIDO : "é incluído"

📐 Performance: Teorema de CAP

Em sistemas distribuídos (como microsserviços), lidamos com o Teorema de CAP:

\[ C + A + P \implies \text{Escolha apenas dois} \]

Onde: - C (Consistency): Consistência. - A (Availability): Disponibilidade. - P (Partition Tolerance): Tolerância a Partições.

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.

Migrações no Terminal (Exemplo)

$ npx knex migrate:make criar_tabela_usuarios
Created: 20240101_criar_tabela_usuarios.js

$ npx knex migrate:latest
Batch 1 run: 1 migrations

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 🧠

  1. Qual a diferença entre uma Chave Primária (Primary Key) e uma Chave Estrangeira (Foreign Key)?
  2. Por que é perigoso deixar o Service rodar comandos SQL diretamente?
  3. 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.

🧩 Arquitetura de Validação (Mermaid)

Um bom fluxo de dados garante que apenas informações limpas cheguem ao core da sua aplicação.

graph LR
    User([Usuário]) --> Client([Frontend])
    Client -- "Dados Sujos" --> API([API Gateway/Controller])
    API -- "Schema Validation" --> V{Validador}
    V -- "Inválido" --> E[Erro 400]
    V -- "Válido (Limpo)" --> B[(Banco de Dados)]
    E --> User

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 🧠

  1. Qual a diferença entre uma falha de validação (erro 400) e um erro inesperado no servidor (erro 500)?
  2. Por que sanitizar o texto de um comentário de usuário antes de salvá-lo no banco?
  3. 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.

4. O Fluxo do Login 🌊

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

Fluxo de Login JWT (Mermaid)

sequenceDiagram
    participant C as Cliente/App
    participant S as Servidor/API
    participant DB as Banco de Dados

    C->>S: POST /login (email, senha)
    S->>DB: Buscar usuário
    DB-->>S: Usuário encontrado
    S->>S: Assinar JWT (Secret)
    S-->>C: Retorna Token (Crachá)
    C->>S: GET /perfil (Header: Authorization: Bearer JWT)
    S->>S: Validar Assinatura
    S-->>C: Dados do Perfil

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' });

🔒 Onde armazenar o JWT no Frontend?

No desenvolvimento Web, temos duas opções principais para guardar o token: * LocalStorage: Fácil de usar, mas vulnerável a ataques XSS (Cross-Site Scripting). * Cookies (HttpOnly): Mais seguros, pois o Javascript não consegue lê-los, protegendo contra roubo de token via script malicioso. Nunca guarde o JWT em texto simples ou em locais sem proteção de segurança mínima!

Verificando Token no Terminal

$ export TOKEN="seu_jwt_aqui"
$ curl -H "Authorization: Bearer $TOKEN" http://localhost:3000/perfil
{"nome": "Ricardo", "role": "admin"}

6. Mini-Projeto: Gerador de Tokens 🛠️

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

7. Exercício de Fixação 🧠

  1. Por que o JWT é chamado de "Stateless" (Sem estado)?
  2. 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?
  3. 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.

Fluxo RBAC (Mermaid)

graph TD
    User([Usuário Logado]) --> JWT{Possui JWT?}
    JWT -- Não --> E401([401 Unauthorized])
    JWT -- Sim --> Role{Role == 'ADMIN'?}
    Role -- Não --> E403([403 Forbidden])
    Role -- Sim --> Sucesso([Acesso Permitido])

5. Testando Permissões no Terminal 💻

Simulando o acesso de um usuário comum tentando entrar em uma área de Admin.

# Usuário tenta acessar rota de Admin
$ curl -H "Authorization: Bearer TOKEN_USUARIO" http://localhost:3000/admin/delete-all
# Resposta do servidor (Middleware barrou)
> 403 Forbidden: Acesso Negado

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 🧠

  1. Por que é melhor usar Roles (Perfis) em vez de dar permissões específicas para cada ID de usuário?
  2. Em qual parte do token JWT costumamos guardar o role do usuário?
  3. 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.

Flow de Refresh (Mermaid)

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: Requisição (Token Expirado)
    S-->>C: Erro 401 (Expired)
    C->>S: POST /refresh (RefreshToken)
    S->>S: Validar RefreshToken no DB
    S-->>C: Novo AccessToken
    C->>S: Repetir Requisição Inicial (Novo Token)
    S-->>C: Sucesso

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.

Testando Segurança (Terminal)

$ curl -I http://localhost:3000
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains

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 🔄

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

7. Exercício de Fixação 🧠

  1. Por que guardamos o Refresh Token no Banco de Dados, mas o Access Token não (Stateless)?
  2. O que acontece se você configurar o CORS com origin: '*'? Por que isso é perigoso em produção?
  3. 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.

Arquitetura SPA (Mermaid)

graph LR
    Client([Browser/SPA]) -- Requisição JSON --> API([Backend/API])
    API -- Resposta JSON --> Client
    Client -- Manipula DOM --> UI([Interface Dinâmica])

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).

Criando Projeto (Terminal)

$ npm create vite@latest meu-app -- --template react
$ cd meu-app
$ npm install
$ npm run dev

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:

  1. Você deve retornar apenas um elemento pai (ou usar um Fragment &lt;&gt;&lt;/&gt;).
  2. 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:
`&lt;Usuario nome="Ricardo" /&gt;`

6. Mini-Projeto: Dashboard de Vendas 📊

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

7. Exercício de Fixação 🧠

  1. Qual a principal diferença entre um site tradicional (Multi Page) e uma SPA?
  2. Por que o uso de componentes facilita a manutenção de projetos grandes?
  3. 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.

Fluxo de Reatividade (Mermaid)

graph TD
    Data([Dados/Estado]) -- Alteração --> React([React Engine])
    React -- Re-renderização --> DOM([DOM Virtual])
    DOM -- Update --> UI([Interface do Usuário])

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 🛒

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

7. Exercício de Fixação 🧠

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

💻 Ambiente de Desenvolvimento (Terminal)

$ npm run dev
VITE v5.0.0  ready in 150ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose

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.

Ciclo de Vida (Mermaid)

graph LR
    Mount([Montagem]) --> Effect([Executa useEffect])
    Update([Atualização]) --> Change([Dependência Mudou?])
    Change -- Sim --> Effect
    Unmount([Desmontagem]) --> Clean([Limpeza/Cleanup])

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. * Mudar o título da aba do navegador. * Configurar um cronômetro (timer).

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>
  );
}

Consumindo API (Terminal)

$ curl https://api.github.com/users/ricardotecpro
{
  "login": "ricardotecpro",
  "name": "Ricardo Tec Pro",
  "bio": "Desenvolvedor Full Stack"
}

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 ☁️

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

7. Exercício de Fixação 🧠

  1. O que acontece se esquecermos de passar o array de dependências [] em um useEffect que faz um fetch e atualiza o estado?
  2. Como fazemos para que um efeito seja executado apenas quando uma variável ID mudar?
  3. 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.

Navegação de Rotas (Mermaid)

graph TD
    Browser([Browser]) -- /home --> Home([Home Component])
    Browser -- /sobre --> Sobre([Sobre Component])
    Browser -- /perfil --> Perfil([Perfil Component])

Instalando Router (Terminal)

$ npm install react-router-dom
added 3 packages, and audited 47 packages in 2s

1. Por que precisamos de um Roteador? 🧭

En 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 &lt;a&gt; comum, pois ela recarrega o site do zero. Use o componente &lt;Link&gt;:

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: &lt;Route path="/produto/:id" element={&lt;Detalhes /&gt;} /&gt;
  • 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 📰

  1. Crie uma página inicial que lista 3 posts (objetos simples).
  2. Crie uma rota dinâmica /post/:id.
  3. 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 🧠

  1. Qual a principal diferença visual entre usar <a href="..."> e <Link to="..."> em um app React?
  2. Para que serve o path="*" em uma configuração de rotas?
  3. 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?

Finalização (Terminal)

$ npm run build
$ npx serve -s dist
serving /dist on http://localhost:3000

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

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.

Integração Full-Stack (Mermaid)

graph TD
    UI([React UI]) -- HTTPS/JSON --> API([Express API])
    API -- SQL --> DB[(PostgreSQL)]
    API -- Success/Error --> UI

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:

  1. Gerenciador de Tarefas Cloud: Sistema de login, cadastro de tarefas com categorias, salvamento no banco de dados e filtros de status.
  2. Mini E-commerce: Listagem de produtos vindo da API, página de detalhes, "carrinho" (estado global) e simulação de checkout.
  3. Rede Social de Bolso: Postagem de mensagens (tweets), perfil de usuário dinâmico e curtidas (likes) em tempo real.
  4. 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."

Finalização (Terminal)

$ npm run build
$ npx serve -s dist
serving /dist on http://localhost:3000

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

Aula 17 - Integração Avançada Frontend/Backend com WebSockets ⚡

Objetivo Pedagógico

Objetivo: Conexão bidirecional resiliente de ponta a ponta entre SPA (Frontend) e API (Backend) com WebSockets, protocolo heartbeat e sincronização reativa de tela.

📑 1. Fundamentos Teóricos & Análise Técnica

A integração em tempo real entre o frontend moderno e o backend distribuído requer sincronização de estado fluida e de baixa latência. No contexto de Aplicações Full Stack, estabelecer uma conexão WebSocket exige coordenar os dois lados da arquitetura: 1. No Backend (Servidor de Eventos): Autenticação da conexão no handshake inicial via token JWT, gerenciamento de conexões ativas em memória e difusão de eventos (broadcast) segmentada por permissões. 2. No Frontend (Cliente Reativo): Módulo de conexão resiliente que gerencia reconexão automática com recuo exponencial (exponential backoff), enfileira mensagens offline para reenvio e atualiza o estado da aplicação (como uma store Zustand ou Signal) imediatamente ao receber novas mensagens. 3. Mecanismo de Heartbeat (Ping/Pong): Detecção proativa de conexões mortas (zombie connections) causadas por perda de sinal de Wi-Fi ou suspensão de tela em dispositivos móveis.

📐 Arquitetura Conceitual & Diagrama de Fluxo

sequenceDiagram
    autonumber
    participant Frontend as SPA Frontend (React/Vue)
    participant WSGateway as WebSocket Gateway (Backend)
    participant StateStore as Client State Store (Zustand/Signals)

    Frontend->>WSGateway: 1. Handshake HTTP com Token JWT
    WSGateway-->>Frontend: 2. Upgrade para WebSocket Concluído (Conectado!)
    loop Sincronização e Heartbeat
        WSGateway->>Frontend: 3. Ping (A cada 25s)
        Frontend-->>WSGateway: 4. Pong
    end
    WSGateway->>Frontend: 5. Evento: "TASK_UPDATED" { id: 42, status: "DONE" }
    Frontend->>StateStore: 6. Atualização Reativa Cirúrgica do Estado
    StateStore-->>Frontend: 7. Interface Atualizada Instantaneamente!

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Autenticação no Handshake: Validação do token de segurança antes de aceitar a conexão persistente. - Reconexão com Backoff Exponencial: Prevenção de ataques de negação de serviço acidentais contra o próprio servidor após reinicializações. - Gerenciamento de Estado Reativo: A integração direta dos eventos de WebSocket com a store da SPA elimina telas desatualizadas. - Enfileiramento Offline: Mensagens disparadas pelo usuário durante quedas temporárias de rede são enviadas assim que a conexão volta.

🛠️ 2. Implementação Prática em Full Stack WebSockets e Eventos Reativos

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// websocket-client.ts (Cliente WebSocket Resiliente para Frontend Full Stack)
export class ResilientWebSocketClient {
  private ws: WebSocket | null = null;
  private retryDelay = 1000;

  constructor(
    private readonly url: string,
    private readonly onMessageCallback: (data: any) => void
  ) {}

  connect() {
    this.ws = new WebSocket(this.url);

    this.ws.onopen = () => {
      console.log('[WebSocket] Conexão estabelecida com sucesso.');
      this.retryDelay = 1000; // Reseta delay após sucesso
    };

    this.ws.onmessage = (event) => {
      const data = JSON.parse(event.data);
      this.onMessageCallback(data);
    };

    this.ws.onclose = () => {
      console.warn(`[WebSocket] Conexão perdida. Tentando reconectar em ${this.retryDelay}ms...`);
      setTimeout(() => this.connect(), this.retryDelay);
      this.retryDelay = Math.min(this.retryDelay * 2, 30000); // Backoff até 30s
    };
  }

  send(payload: any) {
    if (this.ws && this.ws.readyState === WebSocket.OPEN) {
      this.ws.send(JSON.stringify(payload));
    }
  }
}

💡 Análise Passo a Passo do Código

  1. Backoff Exponencial: Math.min(this.retryDelay * 2, 30000) duplica o tempo de espera a cada falha de reconexão, estabilizando a rede.
  2. Tratamento de Desconexão: O evento onclose dispara nova tentativa de conexão de forma totalmente autônoma.
  3. Integração com Store: onMessageCallback recebe os dados parsed e despacha atualizações para a interface.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🌐

Objetivo Pedagógico

Objetivo: Arquitetura de sincronização de estado entre cliente e servidor com TanStack Query (React Query), cache distribuído com Redis e invalidação por tags.

📑 1. Fundamentos Teóricos & Análise Técnica

Em aplicações Full Stack modernas, a gestão de dados transita entre duas realidades distintas: o Estado do Servidor (Server State) e o Estado do Cliente (Client State). Confundir esses dois estados em uma única store global gera dados obsoletos (stale data), problemas de sincronização e perda de performance.

A solução arquitetural de ponta divide a responsabilidade: 1. No Servidor: Implementação do padrão Cache-Aside com Redis, onde requisições frequentes de leitura consultam a memória em cache antes de tocar o banco relacional. Mutações invalidam chaves ou tags de cache correspondentes de forma atômica. 2. No Cliente: Utilização de bibliotecas de sincronização como TanStack Query (React Query). Ela atua como um coordenador inteligente que gerencia deduplicação de requisições, refetch em background quando a janela ganha foco (Window Focus Refetching), atualizações otimistas (Optimistic Updates) e expiração de dados (Stale Time).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Client["SPA Frontend (TanStack Query)"] -->|Cache-First: staleTime 60s| ClientCache["Cache de Memória no Navegador"]
    ClientCache -->|Se Dados Obsoletos: Fetch| Gateway["API Gateway / Backend"]
    Gateway --> Redis["Redis Cache (Cache-Aside)"]
    Redis -->|Cache Hit| Gateway
    Redis -->|Cache Miss| SQL["PostgreSQL / MySQL"]
    SQL --> Redis
    style Client fill:#e1f5fe,stroke:#01579b
    style ClientCache fill:#e8f5e9,stroke:#2e7d32
    style Gateway fill:#fff3e0,stroke:#e65100
    style Redis fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Padrão Cache-Aside: O backend busca primeiro no cache rápido; se ausente, lê do banco e popula o cache. - Atualizações Otimistas (Optimistic Updates): A UI reflete a alteração do usuário instantaneamente antes da resposta do servidor, revertendo apenas em caso de erro. - Invalidação de Cache por Tags: Purga seletiva de coleções inteiras no Redis quando uma entidade é criada ou atualizada. - Deduplicação de Requisições: Múltiplos componentes solicitando o mesmo recurso acionam apenas uma requisição HTTP.

🛠️ 2. Implementação Prática em Arquitetura Full Stack e Cache Distribuído

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// optimistic-mutation.ts (Atualização Otimista com TanStack Query)
import { useMutation, useQueryClient } from '@tanstack/react-query';

interface Task { id: string; title: string; completed: boolean; }

export function useToggleTask() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: async (task: Task) => {
      const res = await fetch(`/api/tasks/${task.id}`, {
        method: 'PATCH',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ completed: !task.completed })
      });
      if (!res.ok) throw new Error('Falha ao atualizar tarefa.');
      return res.json();
    },
    // Atualização Otimista: altera a tela antes da resposta da API!
    onMutate: async (updatedTask) => {
      await queryClient.cancelQueries({ queryKey: ['tasks'] });
      const previousTasks = queryClient.getQueryData<Task[]>(['tasks']);

      queryClient.setQueryData<Task[]>(['tasks'], (old = []) =>
        old.map(t => t.id === updatedTask.id ? { ...t, completed: !t.completed } : t)
      );

      return { previousTasks };
    },
    // Se falhar, reverte para o estado anterior
    onError: (err, task, context) => {
      if (context?.previousTasks) {
        queryClient.setQueryData(['tasks'], context.previousTasks);
      }
    },
    // Invalida e sincroniza com o servidor
    onSettled: () => {
      queryClient.invalidateQueries({ queryKey: ['tasks'] });
    }
  });
}

💡 Análise Passo a Passo do Código

  1. onMutate Imediato: Aplica a alteração diretamente no cache local do cliente, proporcionando sensação de resposta instantânea.
  2. onError Rollback: Se o servidor retornar erro 500, a lista é restaurada exatamente para o estado anterior.
  3. onSettled Sincronização: Garante que o estado local seja alinhado com a resposta definitiva do banco de dados.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Testes E2E de Ponta a Ponta Integrados 🎭

Objetivo Pedagógico

Objetivo: Construção de suítes de testes End-to-End (E2E) com Playwright, simulando fluxos completos de usuários reais através de navegadores headless em pipelines de CI/CD.

📑 1. Fundamentos Teóricos & Análise Técnica

Os Testes de Ponta a Ponta (End-to-End - E2E) situam-se no topo da pirâmide de testes de software. Diferente de testes unitários ou de integração isolados, os testes E2E validam a aplicação como um sistema completo e integrado: o frontend executando em um motor de navegador real (Chromium, Firefox, WebKit), comunicando-se através da rede com a API de backend, gravando dados no banco relacional e reagindo a eventos de mensageria.

A ferramenta moderna de referência para essa prática é o Playwright: 1. Arquitetura Baseada em Protocolos Nativos de Navegador (Chrome DevTools Protocol): Muito mais rápido, estável e resiliente que os antigos drivers Selenium/WebDriver. 2. Auto-Waiting Nativo: O Playwright aguarda automaticamente que os elementos estejam visíveis, estáveis e interativos antes de clicar ou digitar, eliminando flaky tests causados por esperas manuais (sleep). 3. Isolamento Total de Sessão com BrowserContext: Cada teste executa em um contexto limpo e isolado de cookies e armazenamento local em milissegundos, permitindo paralelização massiva.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Runner["Playwright Test Runner"] --> Context["BrowserContext Isolado (Chromium)"]
    Context --> Page["Página Web Renderizada (SPA)"]
    Page -->|Ação do Teste: Clica no Botão de Cadastro| Backend["API de Backend (Serviço Real)"]
    Backend --> DB["Banco de Dados de Testes (PostgreSQL)"]
    DB --> Backend
    Backend --> Page
    Page --> Assertion["Asserção Visual: expect(page).toHaveURL('/dashboard')"]
    style Runner fill:#e1f5fe,stroke:#01579b
    style Page fill:#fff3e0,stroke:#e65100
    style Backend fill:#e8f5e9,stroke:#2e7d32
    style Assertion fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Eliminação de Flakiness: Espera automática de estabilidade de layout antes de qualquer interação com o DOM. - Multi-Browser e Multi-Dispositivo: Execução simultânea em motores Chromium, Firefox, WebKit e emulações de dispositivos móveis. - Geração de Traces e Vídeos: Captura de gravações em vídeo e inspeção passo a passo (trace viewer) em caso de falha no CI. - Testes de Redes e Mocking de Rotas: Capacidade de interceptar e manipular chamadas HTTP de terceiros diretamente no navegador.

🛠️ 2. Implementação Prática em Playwright, Testes E2E e Automação Full Stack

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// auth-flow.spec.ts (Teste E2E de Fluxo de Login com Playwright)
import { test, expect } from '@playwright/test';

test.describe('Fluxo Completo de Autenticação Full Stack', () => {
  test('deve autenticar usuário válido e redirecionar para o dashboard', async ({ page }) => {
    // 1. Navega para a tela inicial
    await page.goto('http://localhost:3000/login');

    // 2. Preenche os campos do formulário
    await page.getByLabel('E-mail Corporativo').fill('admin@empresa.com');
    await page.getByLabel('Senha').fill('SenhaSegura123!');

    // 3. Submete o formulário
    await page.getByRole('button', { name: 'Entrar na Plataforma' }).click();

    // 4. Valida redirecionamento e mensagem de boas-vindas
    await expect(page).toHaveURL('http://localhost:3000/dashboard');
    await expect(page.getByRole('heading', { name: 'Painel Geral' })).toBeVisible();
  });
});

💡 Análise Passo a Passo do Código

  1. Localizadores Semânticos Acessíveis: getByLabel e getByRole testam a aplicação da mesma forma que os usuários e leitores de tela interagem com ela.
  2. Auto-Waiting Automático: O Playwright aguarda o formulário ser processado pela API e a navegação ocorrer antes de avaliar toHaveURL.
  3. Ambiente Real: Valida a cadeia inteira de autenticação: cookies HttpOnly gravados, redirecionamento do roteador e renderização do dashboard.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Aplicação Full Stack Production-Ready 🏆

Objetivo Pedagógico

Objetivo: Construção de uma aplicação Full Stack autônoma pronta para produção (Production-Ready), integrando frontend SPA moderno, backend modular, PostgreSQL, Redis, CI/CD e monitoramento.

📑 1. Fundamentos Teóricos & Análise Técnica

O Projeto Capstone de Aplicações Full Stack é o ápice prático de formação do desenvolvedor como Engenheiro Full Stack completo. O objetivo é conceber, desenvolver, testar e empacotar uma Plataforma Colaborativa de Gestão de Incidentes em Tempo Real, garantindo padrões de engenharia de software de ponta a ponta.

O projeto avalia a integração harmoniosa de todos os subsistemas: 1. Frontend: Single Page Application reativa com design system acessível, gerenciamento de estado com atualizações otimistas e cliente WebSocket com reconexão automática. 2. Backend: API RESTful e WebSocket Gateway com arquitetura modular limpa, validação de esquemas e autenticação stateless baseada em JWT. 3. Infraestrutura: Orquestração de todos os serviços (Frontend, Backend, PostgreSQL e Redis) via Docker Compose, com variáveis de ambiente padronizadas. 4. Garantia de Qualidade: Pipeline automatizado de testes unitários, testes de integração de API e testes E2E executados com sucesso no CI.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    subgraph FrontendApp ["Frontend (Nginx / SPA)"]
        UI["React / Vue / Svelte SPA"]
    end
    subgraph BackendApp ["Backend (Node / Python / Go)"]
        API["REST API & WebSocket Server"]
    end
    subgraph InfraData ["Infraestrutura de Dados"]
        DB["PostgreSQL Relational DB"]
        Cache["Redis In-Memory Cache"]
    end
    UI <-->|HTTP REST / WebSocket| API
    API <--> DB
    API <--> Cache
    style FrontendApp fill:#e1f5fe,stroke:#01579b
    style BackendApp fill:#fff3e0,stroke:#e65100
    style InfraData fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Monorepo Organizado: Estrutura limpa dividida em /apps/frontend, /apps/backend e /packages/shared. - Zero Downtime Deploy: Configuração de probes de saúde (healthchecks) para transição de tráfego contínua. - Segurança em Todas as Camadas: Proteção contra XSS, CSRF, rate limiting ativado e variáveis de ambiente secretas protegidas. - Conformidade com 12-Factor App: Aderência rigorosa às boas práticas mundiais de desenvolvimento de software em nuvem.

🛠️ 2. Implementação Prática em Arquitetura Full Stack, CI/CD e Docker Compose

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// docker-compose.yml (Orquestração Completa da Aplicação Full Stack)
version: '3.8'

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: app_db
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password123
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    environment:
      DATABASE_URL: postgresql://user:password123@postgres:5432/app_db
      REDIS_URL: redis://redis:6379
      PORT: 8080
    ports:
      - "8080:8080"
    depends_on:
      - postgres
      - redis

  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "80:80"
    depends_on:
      - backend

volumes:
  pgdata:

💡 Análise Passo a Passo do Código

  1. Rede Bridge Integrada: O Docker Compose cria uma rede privada automática onde os serviços se comunicam pelo nome do serviço (postgres, redis, backend).
  2. Persistência com Named Volumes: O volume pgdata garante que os dados do banco não sejam perdidos ao reiniciar os contêineres.
  3. Isolamento de Portas: Apenas as portas de interesse do frontend e da API pública são mapeadas para o ambiente hospedeiro.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

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

🟢 Fáceis

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

🟡 Médios

  1. 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.
  2. Conectividade: O que é uma API e por que ela é fundamental na integração de sistemas distribuídos?

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Definição **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução a Serviços e Microsserviços**, o conceito abordado (Definição) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Diferenciação **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução a Serviços e Microsserviços**, o conceito abordado (Diferenciação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Cenário **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução a Serviços e Microsserviços**, o conceito abordado (Cenário) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Conectividade **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução a Serviços e Microsserviços**, o conceito abordado (Conectividade) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Análise de Arquitetura **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução a Serviços e Microsserviços**, o conceito abordado (Análise de Arquitetura) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 02 - Arquitetura e Gateway 🏗️

🟢 Fáceis

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

🟡 Médios

  1. 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?
  2. 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

  1. 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).

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceitos **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Microsserviços e API Gateway ️**, o conceito abordado (Conceitos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Síncrono vs Assíncrono **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Microsserviços e API Gateway ️**, o conceito abordado (Síncrono vs Assíncrono) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Resiliência **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Microsserviços e API Gateway ️**, o conceito abordado (Resiliência) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Segurança **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Microsserviços e API Gateway ️**, o conceito abordado (Segurança) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Cenário de Falha Crítica **Resposta Comentada:** - **Fundamentação:** No contexto de **Arquitetura de Microsserviços e API Gateway ️**, o conceito abordado (Cenário de Falha Crítica) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 03 - Modelagem REST 📡

🟢 Fáceis

  1. 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
  2. Verbos: Qual o verbo HTTP mais adequado para atualizar a senha de um usuário? Por que?

🟡 Médios

  1. 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.
  2. Idempotência: Explique por que o POST não é idempotente e o GET é.

🔴 Desafio

  1. 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.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: URI Design **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de APIs RESTful**, o conceito abordado (URI Design) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Verbos **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de APIs RESTful**, o conceito abordado (Verbos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Status Codes **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Status Codes
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Modelagem de APIs RESTful**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Idempotência **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de APIs RESTful**, o conceito abordado (Idempotência) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Design de Contrato **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de APIs RESTful**, o conceito abordado (Design de Contrato) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

  1. 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
  2. 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

  1. 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.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceitos **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação (Swagger) e Mock de APIs**, o conceito abordado (Conceitos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Mocks **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação (Swagger) e Mock de APIs**, o conceito abordado (Mocks) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Análise de YAML **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação (Swagger) e Mock de APIs**, o conceito abordado (Análise de YAML) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Developer Experience (DX) **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação (Swagger) e Mock de APIs**, o conceito abordado (Developer Experience (DX)) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Cenário de Desenvolvimento **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação (Swagger) e Mock de APIs**, o conceito abordado (Cenário de Desenvolvimento) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

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

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Responsabilidade **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Responsabilidade
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Implementação de APIs (Controllers e Rotas) ⚙️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Mapeamento **Resposta Comentada:** - **Fundamentação:** No contexto de **Implementação de APIs (Controllers e Rotas) ⚙️**, o conceito abordado (Mapeamento) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Parâmetros **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Parâmetros
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Implementação de APIs (Controllers e Rotas) ⚙️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Erros **Resposta Comentada:** - **Fundamentação:** No contexto de **Implementação de APIs (Controllers e Rotas) ⚙️**, o conceito abordado (Erros) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Cenário Real **Resposta Comentada:** - **Fundamentação:** No contexto de **Implementação de APIs (Controllers e Rotas) ⚙️**, o conceito abordado (Cenário Real) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

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

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Services e Regras de Negócio**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Responsabilidade **Resposta Comentada:** - **Fundamentação:** No contexto de **Services e Regras de Negócio**, o conceito abordado (Responsabilidade) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Tratamento de Erros **Resposta Comentada:** - **Fundamentação:** No contexto de **Services e Regras de Negócio**, o conceito abordado (Tratamento de Erros) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Reutilização **Resposta Comentada:** - **Fundamentação:** No contexto de **Services e Regras de Negócio**, o conceito abordado (Reutilização) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Lógica de Negócio **Resposta Comentada:** - **Fundamentação:** No contexto de **Services e Regras de Negócio**, o conceito abordado (Lógica de Negócio) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

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

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Fundamentos **Resposta Comentada:** - **Fundamentação:** No contexto de **Repositories e Banco de Dados (PostgreSQL) ️**, o conceito abordado (Fundamentos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: CRUD **Resolução e Implementação:** 
// Estrutura de implementação recomendada para CRUD
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Repositories e Banco de Dados (PostgreSQL) ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Relacionamentos **Resposta Comentada:** - **Fundamentação:** No contexto de **Repositories e Banco de Dados (PostgreSQL) ️**, o conceito abordado (Relacionamentos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Isolamento **Resposta Comentada:** - **Fundamentação:** No contexto de **Repositories e Banco de Dados (PostgreSQL) ️**, o conceito abordado (Isolamento) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Modelagem Real **Resposta Comentada:** - **Fundamentação:** No contexto de **Repositories e Banco de Dados (PostgreSQL) ️**, o conceito abordado (Modelagem Real) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

  1. Sanitização: Qual a diferença prática entre validar um campo e sanitizar um campo? Quando usamos cada um?
  2. 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

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Boas Práticas e Validação de Dados ✅**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Validação **Resposta Comentada:** - **Fundamentação:** No contexto de **Boas Práticas e Validação de Dados ✅**, o conceito abordado (Validação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Sanitização **Resposta Comentada:** - **Fundamentação:** No contexto de **Boas Práticas e Validação de Dados ✅**, o conceito abordado (Sanitização) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Clean Code **Resposta Comentada:** - **Fundamentação:** No contexto de **Boas Práticas e Validação de Dados ✅**, o conceito abordado (Clean Code) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Tratamento de Erros **Resposta Comentada:** - **Fundamentação:** No contexto de **Boas Práticas e Validação de Dados ✅**, o conceito abordado (Tratamento de Erros) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

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

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança e Autenticação com JWT**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: JWT **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança e Autenticação com JWT**, o conceito abordado (JWT) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Segurança **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança e Autenticação com JWT**, o conceito abordado (Segurança) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Stateless **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança e Autenticação com JWT**, o conceito abordado (Stateless) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Análise de Token **Resposta Comentada:** - **Fundamentação:** No contexto de **Segurança e Autenticação com JWT**, o conceito abordado (Análise de Token) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

  1. Conceito: No sistema RBAC, o que é uma "Role"?
  2. 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

  1. 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?
  2. 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

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Controle de Acesso (RBAC) e Permissões ️**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Status Code **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Status Code
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Controle de Acesso (RBAC) e Permissões ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Diferença **Resposta Comentada:** - **Fundamentação:** No contexto de **Controle de Acesso (RBAC) e Permissões ️**, o conceito abordado (Diferença) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Middleware **Resposta Comentada:** - **Fundamentação:** No contexto de **Controle de Acesso (RBAC) e Permissões ️**, o conceito abordado (Middleware) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Hierarchy (Hierarquia) **Resposta Comentada:** - **Fundamentação:** No contexto de **Controle de Acesso (RBAC) e Permissões ️**, o conceito abordado (Hierarchy (Hierarquia)) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

  1. 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)?
  2. 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.
  3. Headers: Cite três informações sensíveis que o Helmet ajuda a esconder nos cabeçalhos HTTP.

🔴 Desafio

  1. 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"?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Refresh Token e Segurança Avançada ️**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Bibliotecas **Resposta Comentada:** - **Fundamentação:** No contexto de **Refresh Token e Segurança Avançada ️**, o conceito abordado (Bibliotecas) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: CORS **Resposta Comentada:** - **Fundamentação:** No contexto de **Refresh Token e Segurança Avançada ️**, o conceito abordado (CORS) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Flow **Resposta Comentada:** - **Fundamentação:** No contexto de **Refresh Token e Segurança Avançada ️**, o conceito abordado (Flow) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Headers **Resposta Comentada:** - **Fundamentação:** No contexto de **Refresh Token e Segurança Avançada ️**, o conceito abordado (Headers) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Segurança de Refresh Tokens **Resposta Comentada:** - **Fundamentação:** No contexto de **Refresh Token e Segurança Avançada ️**, o conceito abordado (Segurança de Refresh Tokens) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

  1. Componentes: Por que dizemos que a arquitetura do React é baseada em "LEGO"? Como isso ajuda na organização do código?
  2. Vite: Qual a função do Vite no desenvolvimento de um projeto React moderno?
  3. 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

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Frontend Moderno (React) ⚛️**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Sintaxe **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Sintaxe
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Frontend Moderno (React) ⚛️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Componentes **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Frontend Moderno (React) ⚛️**, o conceito abordado (Componentes) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Vite **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Frontend Moderno (React) ⚛️**, o conceito abordado (Vite) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Props **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Frontend Moderno (React) ⚛️**, o conceito abordado (Props) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: JSX vs HTML **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Frontend Moderno (React) ⚛️**, o conceito abordado (JSX vs HTML) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

  1. 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.
  2. 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?
  3. Inputs: O que é um "Input Controlado" e como o atributo value e o evento onChange trabalham juntos?

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Estado e Reatividade (Hooks)**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Sintaxe **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Sintaxe
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estado e Reatividade (Hooks)**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Eventos **Resposta Comentada:** - **Fundamentação:** No contexto de **Estado e Reatividade (Hooks)**, o conceito abordado (Eventos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Imutabilidade **Resposta Comentada:** - **Fundamentação:** No contexto de **Estado e Reatividade (Hooks)**, o conceito abordado (Imutabilidade) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Inputs **Resposta Comentada:** - **Fundamentação:** No contexto de **Estado e Reatividade (Hooks)**, o conceito abordado (Inputs) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Toggle de Visibilidade **Resposta Comentada:** - **Fundamentação:** No contexto de **Estado e Reatividade (Hooks)**, o conceito abordado (Toggle de Visibilidade) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 14 - Efeitos e Chamadas de API 🌐

🟢 Fáceis

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

🟡 Médios

  1. Dependências: Se eu quiser que o useEffect rode sempre que a variável usuarioID mudar, como deve ficar o array de dependências?
  2. Fetch: Explique a ordem de execução do código abaixo: 
    console.log("A");
fetch("url").then(() => console.log("B"));
console.log("C");
  3. Estados de Rede: Por que é importante ter um estado de loading (carregando) em aplicações que buscam dados na internet?

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Efeitos e Chamadas de API (useEffect)**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: useEffect **Resolução e Implementação:** 
// Estrutura de implementação recomendada para useEffect
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Efeitos e Chamadas de API (useEffect)**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Dependências **Resposta Comentada:** - **Fundamentação:** No contexto de **Efeitos e Chamadas de API (useEffect)**, o conceito abordado (Dependências) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Fetch **Resposta Comentada:** - **Fundamentação:** No contexto de **Efeitos e Chamadas de API (useEffect)**, o conceito abordado (Fetch) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Estados de Rede **Resposta Comentada:** - **Fundamentação:** No contexto de **Efeitos e Chamadas de API (useEffect)**, o conceito abordado (Estados de Rede) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Ciclo de Efeitos **Resposta Comentada:** - **Fundamentação:** No contexto de **Efeitos e Chamadas de API (useEffect)**, o conceito abordado (Ciclo de Efeitos) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

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

🟢 Fáceis

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

🟡 Médios

  1. Navegação: Qual a diferença entre usar o componente <Link> e o hook useNavigate? Em quais situações você usaria cada um?
  2. Rota 404: Como configuramos uma rota que deve ser exibida quando o usuário digita uma URL que não existe no site?
  3. 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

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Conceito **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação com React Router**, o conceito abordado (Conceito) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Componentes **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação com React Router**, o conceito abordado (Componentes) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Navegação **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação com React Router**, o conceito abordado (Navegação) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Rota 404 **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação com React Router**, o conceito abordado (Rota 404) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Parâmetros **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação com React Router**, o conceito abordado (Parâmetros) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Proteção de Rotas **Resposta Comentada:** - **Fundamentação:** No contexto de **Navegação com React Router**, o conceito abordado (Proteção de Rotas) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios 16 - Planejamento do Projeto Final 🏆

🟢 Fáceis

  1. 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.
  2. Tecnologias: Enumere pelo menos 3 tecnologias do Frontend e 3 do Backend que você usará no seu TCC.

🟡 Médios

  1. 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.
  2. Segurança: Como você planeja proteger as informações sensíveis (senhas, segredos JWT) no seu projeto final?
  3. CORS: Por que você precisará configurar o CORS no seu servidor para que o projeto funcione?

🔴 Desafio

  1. 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?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Escolha do Tema **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escolha do Tema
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Projeto Final e Conclusão**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Tecnologias **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Tecnologias) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Arquitetura **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Arquitetura) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Segurança **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Segurança) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: CORS **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (CORS) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 6: Plano de Entrega **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final e Conclusão**, o conceito abordado (Plano de Entrega) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

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

  1. Instale o Postman ou Insomnia.
  2. Realize uma requisição do tipo GET para a API pública do GitHub: https://api.github.com/users/github.
  3. Analise a resposta (JSON). Identifique os campos login, id e public_repos.
  4. Instale o Docker Desktop e rode o comando docker run hello-world no terminal para garantir que a virtualização está ativa.
  5. 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 } ]

  1. 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.
  2. Escreva o JSON final que o Gateway entregaria para o Frontend, unindo as informações do usuário e seus pedidos.
  3. 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.

Projeto 03 - Contrato de API de Rede Social ⚡

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).

  1. Liste as 5 rotas principais (CRUD) para gerenciar postagens, indicando o Verbo, a URI e o Status Code de sucesso esperado.
  2. Crie um exemplo de JSON para uma postagem que contenha:
    • id
    • autor_id
    • conteúdo (texto)
    • data_publicacao
    • tags (lista de strings)
  3. 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).

  1. 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.
  2. Documente os campos de uma tarefa (ex: id, titulo, concluida).
  3. 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):

  1. Uma rota para listar todas as tarefas, permitindo um filtro opcional por status (ex: concluída ou pendente).
  2. Uma rota para buscar uma única tarefa pelo seu id.
  3. Uma rota para criar uma tarefa, recebendo titulo e descricao.
  4. 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.

  1. Função validarSenha(senha): Deve garantir que a senha tenha no mínimo 8 caracteres e contenha pelo menos um número.
  2. 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!).
  3. 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:

  1. Tabelas: Crie as tabelas Clientes e Filmes.
  2. Campos:
    • Clientes deve ter id, nome e email.
    • Filmes deve ter id, titulo e genero.
  3. Relacionamento: Crie uma terceira tabela Alugueis que ligue um cliente a um filme (incluindo a data_aluguel).
  4. 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:

  1. Campos Obrigatórios: titulo (mín. 10 char), data (deve ser futura), capacidade_maxima (número positivo).
  2. Campos Opcionais: descricao (máx. 500 char), link_inscricao (formato de URL).
  3. Sanitização: O título não deve conter espaços em branco sobrando no início ou no fim (trim).
  4. 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).

Projeto 09 - Sistema de Login (Simulado) 🔐

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

O Desafio

Crie uma API de simulação de login:

  1. Entrada: Receba um JSON com email e senha.
  2. Validação: Verifique se a senha tem mais de 6 caracteres.
  3. JWT: Use uma biblioteca (ou pseudocódigo) para gerar um token que contenha o id do usuário e sua permissão (ex: 'aluno').
  4. Expiração: Configure o token para ser válido por apenas 24 horas.
  5. 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:

  1. Roles: Defina três tipos: ADMIN, GESTOR e FUNCIONARIO.
  2. 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).
  3. 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:

  1. Helmet: Instale e configure o Helmet para proteger os Headers.
  2. CORS: Restrinja o acesso à API para que apenas o domínio http://localhost:3000 possa consultá-la.
  3. 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.
  4. 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:

  1. Componente FotoPerfil: Exibe uma imagem circular.
  2. Componente InfoUsuario: Recebe nome e bio via props e exibe na tela.
  3. Componente BotaoSeguir: Um botão simples que, por enquanto, apenas exibe um alerta ao ser clicado.
  4. 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:

  1. Inputs: Dois campos de texto (Nome e Telefone).
  2. Botão Adicionar: Quando clicado, deve validar se os campos estão preenchidos e adicionar o contato em um Estado de Array.
  3. Lista: Exiba todos os contatos adicionados abaixo do formulário.
  4. 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:

  1. Input: Campo para digitar o nome do usuário do GitHub.
  2. Botão Buscar: Ao clicar, deve disparar a busca.
  3. Loading: Enquanto a API não responde, deve aparecer o texto "Buscando repositórios...".
  4. Lista: Exiba o nome de todos os repositórios públicos encontrados.
  5. 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:

  1. Home (/): Uma página de boas-vindas com links para as outras seções.
  2. Dashboard (/app): Onde fica a funcionalidade principal (ex: a busca de repositórios).
  3. Sobre (/sobre): Uma página contando quem criou o projeto.
  4. 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

  1. Backend (Express): Uso obrigatório de rotas protegidas por JWT e validação de dados.
  2. Frontend (React): Componentização clara, uso de Hooks (useState, useEffect) e navegação com React Router.
  3. Integração: O Frontend deve consumir a sua própria API de forma assíncrona.
  4. UX/UI: Interface amigável, com tratamento de estados de carregamento e erro.
  5. 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 de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Introdução a Serviços e Microsserviços 🌐

  1. Qual é o conceito fundamental e objetivo principal de Introdução a Serviços e Microsserviços 🌐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução a Serviços e Microsserviços 🌐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução a Serviços e Microsserviços 🌐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução a Serviços e Microsserviços 🌐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução a Serviços e Microsserviços 🌐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução a Serviços e Microsserviços 🌐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução a Serviços e Microsserviços 🌐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução a Serviços e Microsserviços 🌐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução a Serviços e Microsserviços 🌐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução a Serviços e Microsserviços 🌐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Arquitetura de Microsserviços e API Gateway 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Arquitetura de Microsserviços e API Gateway 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Arquitetura de Microsserviços e API Gateway 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Arquitetura de Microsserviços e API Gateway 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Arquitetura de Microsserviços e API Gateway 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Arquitetura de Microsserviços e API Gateway 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Arquitetura de Microsserviços e API Gateway 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Arquitetura de Microsserviços e API Gateway 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Arquitetura de Microsserviços e API Gateway 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Arquitetura de Microsserviços e API Gateway 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Arquitetura de Microsserviços e API Gateway 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Modelagem de APIs RESTful 📡

  1. Qual é o conceito fundamental e objetivo principal de Modelagem de APIs RESTful 📡?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Modelagem de APIs RESTful 📡?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Modelagem de APIs RESTful 📡, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Modelagem de APIs RESTful 📡?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Modelagem de APIs RESTful 📡 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Modelagem de APIs RESTful 📡, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Modelagem de APIs RESTful 📡?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Modelagem de APIs RESTful 📡 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Modelagem de APIs RESTful 📡 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Modelagem de APIs RESTful 📡 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Documentação (Swagger) e Mock de APIs 📝

  1. Qual é o conceito fundamental e objetivo principal de Documentação (Swagger) e Mock de APIs 📝?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Documentação (Swagger) e Mock de APIs 📝?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Documentação (Swagger) e Mock de APIs 📝, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Documentação (Swagger) e Mock de APIs 📝?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Documentação (Swagger) e Mock de APIs 📝 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Documentação (Swagger) e Mock de APIs 📝, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Documentação (Swagger) e Mock de APIs 📝?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Documentação (Swagger) e Mock de APIs 📝 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Documentação (Swagger) e Mock de APIs 📝 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Documentação (Swagger) e Mock de APIs 📝 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Implementação de APIs (Controllers e Rotas) ⚙️

  1. Qual é o conceito fundamental e objetivo principal de Implementação de APIs (Controllers e Rotas) ⚙️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Implementação de APIs (Controllers e Rotas) ⚙️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Implementação de APIs (Controllers e Rotas) ⚙️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Implementação de APIs (Controllers e Rotas) ⚙️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Implementação de APIs (Controllers e Rotas) ⚙️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Implementação de APIs (Controllers e Rotas) ⚙️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Implementação de APIs (Controllers e Rotas) ⚙️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Implementação de APIs (Controllers e Rotas) ⚙️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Implementação de APIs (Controllers e Rotas) ⚙️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Implementação de APIs (Controllers e Rotas) ⚙️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Services e Regras de Negócio 🧠

  1. Qual é o conceito fundamental e objetivo principal de Services e Regras de Negócio 🧠?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Services e Regras de Negócio 🧠?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Services e Regras de Negócio 🧠, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Services e Regras de Negócio 🧠?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Services e Regras de Negócio 🧠 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Services e Regras de Negócio 🧠, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Services e Regras de Negócio 🧠?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Services e Regras de Negócio 🧠 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Services e Regras de Negócio 🧠 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Services e Regras de Negócio 🧠 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Repositories e Banco de Dados (PostgreSQL) 🗄️

  1. Qual é o conceito fundamental e objetivo principal de Repositories e Banco de Dados (PostgreSQL) 🗄️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Repositories e Banco de Dados (PostgreSQL) 🗄️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Repositories e Banco de Dados (PostgreSQL) 🗄️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Repositories e Banco de Dados (PostgreSQL) 🗄️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Repositories e Banco de Dados (PostgreSQL) 🗄️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Repositories e Banco de Dados (PostgreSQL) 🗄️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Repositories e Banco de Dados (PostgreSQL) 🗄️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Repositories e Banco de Dados (PostgreSQL) 🗄️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Repositories e Banco de Dados (PostgreSQL) 🗄️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Repositories e Banco de Dados (PostgreSQL) 🗄️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Boas Práticas e Validação de Dados ✅

  1. Qual é o conceito fundamental e objetivo principal de Boas Práticas e Validação de Dados ✅?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Boas Práticas e Validação de Dados ✅?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Boas Práticas e Validação de Dados ✅, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Boas Práticas e Validação de Dados ✅?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Boas Práticas e Validação de Dados ✅ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Boas Práticas e Validação de Dados ✅, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Boas Práticas e Validação de Dados ✅?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Boas Práticas e Validação de Dados ✅ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Boas Práticas e Validação de Dados ✅ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Boas Práticas e Validação de Dados ✅ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Segurança e Autenticação com JWT 🔐

  1. Qual é o conceito fundamental e objetivo principal de Segurança e Autenticação com JWT 🔐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Segurança e Autenticação com JWT 🔐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Segurança e Autenticação com JWT 🔐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Segurança e Autenticação com JWT 🔐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Segurança e Autenticação com JWT 🔐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Segurança e Autenticação com JWT 🔐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Segurança e Autenticação com JWT 🔐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Segurança e Autenticação com JWT 🔐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Segurança e Autenticação com JWT 🔐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Segurança e Autenticação com JWT 🔐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Controle de Acesso (RBAC) e Permissões 🛡️

  1. Qual é o conceito fundamental e objetivo principal de Controle de Acesso (RBAC) e Permissões 🛡️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Controle de Acesso (RBAC) e Permissões 🛡️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Controle de Acesso (RBAC) e Permissões 🛡️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Controle de Acesso (RBAC) e Permissões 🛡️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Controle de Acesso (RBAC) e Permissões 🛡️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Controle de Acesso (RBAC) e Permissões 🛡️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Controle de Acesso (RBAC) e Permissões 🛡️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Controle de Acesso (RBAC) e Permissões 🛡️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Controle de Acesso (RBAC) e Permissões 🛡️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Controle de Acesso (RBAC) e Permissões 🛡️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Refresh Token e Segurança Avançada 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Refresh Token e Segurança Avançada 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Refresh Token e Segurança Avançada 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Refresh Token e Segurança Avançada 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Refresh Token e Segurança Avançada 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Refresh Token e Segurança Avançada 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Refresh Token e Segurança Avançada 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Refresh Token e Segurança Avançada 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Refresh Token e Segurança Avançada 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Refresh Token e Segurança Avançada 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Refresh Token e Segurança Avançada 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Introdução ao Frontend Moderno (React) ⚛️

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao Frontend Moderno (React) ⚛️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao Frontend Moderno (React) ⚛️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao Frontend Moderno (React) ⚛️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao Frontend Moderno (React) ⚛️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao Frontend Moderno (React) ⚛️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao Frontend Moderno (React) ⚛️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao Frontend Moderno (React) ⚛️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao Frontend Moderno (React) ⚛️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao Frontend Moderno (React) ⚛️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao Frontend Moderno (React) ⚛️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Estado e Reatividade (Hooks) 🎣

  1. Qual é o conceito fundamental e objetivo principal de Estado e Reatividade (Hooks) 🎣?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Estado e Reatividade (Hooks) 🎣?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Estado e Reatividade (Hooks) 🎣, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Estado e Reatividade (Hooks) 🎣?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Estado e Reatividade (Hooks) 🎣 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Estado e Reatividade (Hooks) 🎣, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Estado e Reatividade (Hooks) 🎣?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Estado e Reatividade (Hooks) 🎣 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Estado e Reatividade (Hooks) 🎣 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Estado e Reatividade (Hooks) 🎣 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Efeitos e Chamadas de API (useEffect) 🌐

  1. Qual é o conceito fundamental e objetivo principal de Efeitos e Chamadas de API (useEffect) 🌐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Efeitos e Chamadas de API (useEffect) 🌐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Efeitos e Chamadas de API (useEffect) 🌐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Efeitos e Chamadas de API (useEffect) 🌐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Efeitos e Chamadas de API (useEffect) 🌐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Efeitos e Chamadas de API (useEffect) 🌐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Efeitos e Chamadas de API (useEffect) 🌐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Efeitos e Chamadas de API (useEffect) 🌐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Efeitos e Chamadas de API (useEffect) 🌐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Efeitos e Chamadas de API (useEffect) 🌐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Navegação com React Router 🚦

  1. Qual é o conceito fundamental e objetivo principal de Navegação com React Router 🚦?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Navegação com React Router 🚦?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Navegação com React Router 🚦, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Navegação com React Router 🚦?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Navegação com React Router 🚦 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Navegação com React Router 🚦, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Navegação com React Router 🚦?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Navegação com React Router 🚦 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Navegação com React Router 🚦 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Navegação com React Router 🚦 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Final e Conclusão 🏆

  1. Qual é o conceito fundamental e objetivo principal de Projeto Final e Conclusão 🏆?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Final e Conclusão 🏆?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Final e Conclusão 🏆, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Final e Conclusão 🏆?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Final e Conclusão 🏆 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Final e Conclusão 🏆, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Final e Conclusão 🏆?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Final e Conclusão 🏆 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Final e Conclusão 🏆 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Final e Conclusão 🏆 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Integração Avançada Frontend/Backend com WebSockets 🚀

  1. Qual o propósito principal de Integração Avançada Frontend/Backend com WebSockets 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Integração Avançada Frontend/Backend com WebSockets 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Integração Avançada Frontend/Backend com WebSockets 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Integração Avançada Frontend/Backend com WebSockets 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Integração Avançada Frontend/Backend com WebSockets 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Integração Avançada Frontend/Backend com WebSockets 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Integração Avançada Frontend/Backend com WebSockets 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Integração Avançada Frontend/Backend com WebSockets 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Integração Avançada Frontend/Backend com WebSockets 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Integração Avançada Frontend/Backend com WebSockets 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀

  1. Qual o propósito principal de Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Gestão de Estado de Aplicação Full Stack e Caching Distribuído 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Testes E2E de Ponta a Ponta Integrados 🚀

  1. Qual o propósito principal de Testes E2E de Ponta a Ponta Integrados 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Testes E2E de Ponta a Ponta Integrados 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Testes E2E de Ponta a Ponta Integrados 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Testes E2E de Ponta a Ponta Integrados 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Testes E2E de Ponta a Ponta Integrados 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Testes E2E de Ponta a Ponta Integrados 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Testes E2E de Ponta a Ponta Integrados 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Testes E2E de Ponta a Ponta Integrados 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Testes E2E de Ponta a Ponta Integrados 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Testes E2E de Ponta a Ponta Integrados 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Aplicação Full Stack Production-Ready 🚀

  1. Qual o propósito principal de Projeto Capstone: Aplicação Full Stack Production-Ready 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Aplicação Full Stack Production-Ready 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Aplicação Full Stack Production-Ready 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Aplicação Full Stack Production-Ready 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Aplicação Full Stack Production-Ready 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Aplicação Full Stack Production-Ready 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Aplicação Full Stack Production-Ready 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Aplicação Full Stack Production-Ready 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Aplicação Full Stack Production-Ready 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Aplicação Full Stack Production-Ready 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Configuração de Ambiente 🛠️

Antes de começar a codificar, é fundamental ter seu "cinto de utilidades" pronto. Siga os guias abaixo para configurar cada parte do ecossistema.

  • Backend --- Prepare seu ambiente para criar microsserviços robustos com Docker, Node.js/Java e ferramentas de teste de API. Configurar Backend

  • Frontend SPA --- Configure as ferramentas de build (Vite/NPM) e frameworks para criar interfaces modernas e responsivas. Configurar Frontend

Dica de Produtibilidade

Recomendamos o uso do Visual Studio Code como editor unificado para ambas as stacks. Isso facilita a alternância entre o código do servidor e o código do cliente.

Setup Backend ⚙️

Para desenvolver aplicações backend profissionais com microsserviços, você precisa configurar seu ambiente com as ferramentas certas.

1. Editor de Código (IDE)

Recomendamos o Visual Studio Code por sua leveza e ecossistema de extensões. - Baixar VS Code - Extensões Recomendadas: REST Client, Docker, GitLens, Prettier.

2. Docker 🐳

O Docker é essencial para rodar bancos de dados e serviços sem poluir sua máquina local. - Baixar Docker Desktop - Verificação: No terminal, digite docker --version.

3. Client HTTP (Testes de API) 📡

Para testar seus endpoints sem precisar de um frontend. - Opção 1: Postman - Opção 2: Insomnia - Opção 3: Extensão Thunder Client no VS Code.

4. Ambiente de Execução (Runtime)

Dependendo da stack escolhida: - Node.js: Baixar Node.js (LTS) - Java: Baixar JDK 17+ - Python: Baixar Python 3.10+

5. Console/Terminal 💻

  • Windows: Recomendamos o Windows Terminal com PowerShell 7 ou Git Bash.
  • Mac/Linux: O terminal nativo ou Zsh (Oh My Zsh).

Pronto!

Com essas ferramentas instaladas, você está pronto para construir seu primeiro microsserviço!

Setup Frontend SPA 🎨

O desenvolvimento de Single Page Applications (SPA) exige um ambiente focado em ferramentas de build e gerenciadores de pacotes.

1. Node.js e NPM/Yarn 📦

O ecossistema frontend moderno roda sobre o Node.js. - NPM: Vem instalado com o Node.js. - Yarn: Alternativa popular (npm install --global yarn). - Verificação: node -v e npm -v.

2. Frameworks e Bibliotecas 🧱

Neste curso, exploramos os conceitos base que se aplicam a: - React: npx create-react-app meu-app - Vue.js: npm create vue@latest - Angular: npm install -g @angular/cli

3. Extensões do VS Code para Frontend

  • ES7+ React/Redux/React-Native snippets (ou equivalentes para Vue).
  • ESLint: Para manter o código limpo e padronizado.
  • Tailwind CSS IntelliSense (se estiver usando Tailwind).

4. Debugging no Navegador 🏎️

  • Chrome DevTools: F12 ou Ctrl+Shift+I.
  • React Developer Tools: Extensão para Chrome/Firefox.
  • Redux DevTools: Essencial para gerenciamento de estado complexo.

5. Mocking de API (Opcional) 🎭

Caso queira desenvolver o frontend antes do backend estar pronto: - JSON Server: npm install -g json-server - MSW (Mock Service Worker): Para interceptação de chamadas de rede.

Dica de Performance

Utilize o Vite para criar seus projetos frontend. Ele é extremamente rápido e moderno: 

npm create vite@latest

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)

  • Definição Syllabus (16 Aulas)
  • Estrutura Backend-first com integração SPA
  • Configuração MkDocs Material

✅ Fase 2: Conteúdo Base (Concluído)

  • Criação das 16 Aulas (Markdown)
  • Criação dos 16 Quizzes (HTML)
  • Criação dos 16 Conjuntos de Exercícios
  • Criação dos 16 Slides (RevealJS)

✅ Fase 3: Projetos e UX (Concluído)

  • Definição dos 16 Projetos práticos
  • Documentação Swagger/OpenAPI integrada
  • Diagramação Mermaid de arquitetura de serviços

🚀 Fase 4: Lançamento e Manutenção

  • 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).

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.