01-Apresentação da Disciplina e do Projeto

Apresentação da Disciplina e do Projeto do Semestre

Materiais desta aula

SlidesSlide AtividadeExercício/Atividade

01 - Apresentação da Disciplina e do Projeto do Semestre

Disciplina: Desenvolvimento Back-end II

Sumário

A disciplina Back-end II
Revisão: o que trazemos do Back-end I
Banco de dados relacional x não-relacional
O projeto do semestre: StockAPI

1. A disciplina Back-end II

Objetivo geral

Desenvolver soluções de software baseadas em Web Services com banco de dados relacional.

Objetivos específicos

Especificar documentação de API no padrão Open API 3.0
Implementar API REST com acesso a banco de dados e autenticação
Utilizar um banco de dados relacional
Entender a importância dos testes em soluções de software

Como o semestre está organizado

O semestre tem 20 encontros, divididos em 2 bimestres:

Bimestre	Foco	Avaliações
1º	Banco relacional (MySQL) + CRUD + autenticação	Encontro 6 (teórica) e Encontro 10 (prática)
2º	Postman: documentação (OpenAPI) + testes	Encontro 16 (teórica) e Encontro 20 (prática)

Cada encontro tem um exercício de fixação diferente do exemplo dado em aula — a ideia é praticar o raciocínio, não copiar um modelo pronto.

2. Revisão: o que trazemos do Back-end I

No primeiro semestre, construímos APIs REST com Node.js e Express, seguindo a arquitetura MVC (Model-View-Controller, adaptada para APIs):

requisição do cliente
        │
        ▼
      rotas          → decide qual controller atende a requisição
        │
        ▼
    controller        → aplica a lógica de negócio
        │
        ▼
  model / banco de dados

Estrutura de pastas usada no projeto do semestre passado (DevLog API):

controllers/
middlewares/
routes/
services/
.env

Autenticação com JWT

O fluxo de autenticação que já conhecemos:

Registro — o usuário cria uma conta; a senha é criptografada (bcrypt) antes de salvar
Login — o servidor confere a senha e, se estiver correta, gera um token JWT
Requisição autenticada — o cliente envia o token no header Authorization
Middleware de validação — a rota protegida só responde se o token for válido

Esse fluxo não muda neste semestre. A diferença é que os usuários, em vez de ficarem em um banco de documentos, vão ficar em uma tabela relacional.

3. Banco de dados relacional x não-relacional

Duas formas de guardar dados

	Relacional (SQL)	Não-relacional (NoSQL)
Estrutura	Tabelas, linhas e colunas	Coleções de documentos
Schema	Fixo, definido antes de usar	Flexível, pode variar entre registros
Relacionamentos	Chaves estrangeiras + `JOIN`	Geralmente embutidos no próprio documento
Exemplo usado no curso	MySQL	MongoDB

Por que relacional para uma loja?

O projeto deste semestre é uma API de loja (StockAPI). Esse domínio tem características que combinam muito bem com um banco relacional:

Estrutura previsível — produtos, categorias, clientes e pedidos têm um formato bem definido
Relacionamentos claros — um pedido tem vários produtos, e um produto pode aparecer em vários pedidos (relação N:N)
Consistência é essencial — um pedido não pode referenciar um produto que não existe no estoque

Um banco relacional garante essas regras de forma nativa, através de chaves estrangeiras — por isso ele é a escolha certa aqui.

Nota: em Back-end I, o conteúdo de MongoDB foi retirado do planejamento por falta de tempo. Isso não afeta este semestre — vamos aprender bancos relacionais do zero, com calma.

4. O projeto do semestre: StockAPI

Assim como o DevLog atravessou todo o Back-end I, a StockAPI vai atravessar todo o Back-end II. É uma API REST para controle de estoque e pedidos de uma loja.

A cada encontro, um pedaço novo é adicionado ao projeto:

Modelagem das tabelas (DER)
Conexão com o MySQL
CRUD de produtos e categorias
Relacionamentos entre tabelas (JOIN)
Autenticação JWT com usuários no banco relacional
Documentação da API no Postman
Testes funcionais no Postman

Entidades principais (prévia)

Estas são as entidades que vamos detalhar juntos a partir do Encontro 2:

produtos
categorias
clientes
pedidos
itens_pedido
usuarios

Repare que itens_pedido ainda não foi explicada — é uma peça que resolve o relacionamento N:N entre produtos e pedidos. Vamos chegar lá na atividade de hoje e formalizar no próximo encontro.

Para a próxima aula

02-Modelagem relacional da StockAPI. Vamos transformar as entidades de hoje em um Diagrama Entidade-Relacionamento (DER) oficial do projeto.

Douglas Legramante