cefet_web

Server-side parte 6

Bancos de dados, Formulários, Arquiteturas REST
e o Jardim Zumbi 🧟

Roteiro

Acesso a bancos de dados
Envio de formulários
Arquitetura REST
Entrando no Jardim Zumbi

Bancos de dados

Acesso aos dados armazenados

Revisão de SGBDs
MySQL
Acesso via driver
Acesso via ORM/ODM

SGBDs relacionais

Fazem armazenamento, recuperação, manutenção e concorrência de dados
Baseados na normalização de relações e tuplas
Mantém propriedades ACID em suas transações
Tradicionalmente usados para aplicações como:
1. Gerenciadores de conteúdo (CMS)
2. Gerenciadores de relação com cliente (CRM)
3. Carrinhos de compra
Interface com aplicações via SQL

SGBDs NoSQL

Movimento surgido em ~2005 de popularização de formas de armazenamento não-relacional
Divididos em 4 modelos de dados:
1. Chave-valor
2. Documentos
3. Família de colunas
4. Grafos
Modelos “orientados a agregados” são próprios para sharding
- Em ~2005 precisávamos ter bastante escalabilidade horizontal das aplicações Web
Interface com aplicações frequentemente não usa SQL

Conexão da aplicação com SGBDs

Aplicação conecta ao banco de 2 formas:
1. “Diretamente” por meio do driver do SGBD
2. Camada de mapeamento para objetos (ORM/ODM)
  - Ideia: manter estilo de programação OO “sem restrições” do modelo de dados
Passos:
1. Aplicação abre uma conexão (ou pool) ao inicializar
2. A cada requisição, submete consultas ao SGBD

Um pool de conexões visa evitar overhead de abertura de conexões ao reutilizá-las quando se tornam ociosas.

MySQL

É um dos SGBDs relacionais mais populares
Criado na Suécia na década de 1990
Gratuito, open source, adquirido pela Oracle em 2009
Criadores originais criaram o MariaDB quando foi comprado pela Oracle
Há drivers feitos pela comunidade Node.js para o MySQL
- Vamor usar o pacote mysql2 (para versões MySQL > 5)
Também há ORMs comuns, como o pacote sequelize

Primeiros passos (connection vs pool)

Usando 1 conexão:

import mysql from 'mysql2/promise'
const db = mysql.createConnection({
  host: 'localhost',
  database: 'nome-do-db',
  user: 'me',
  password: 'secret',
  port: 3306

  // configuração das conexões
  multipleStatements: true,





})

Usando um pool de conexões: ✅

import mysql from 'mysql2/promise'
const db = mysql.createPool({
  host: 'localhost',
  database: 'nome-do-db',
  user: 'me',
  password: 'secret',
  port: 3306

  // configuração das conexões
  multipleStatements: true,

  // configuração da pool
  waitForConnections: true,
  connectionLimit: 10,
  queueLimit: 0
})

// chamada assíncrona com await para FAZER UMA CONSULTA
// para conseguirmos non-blocking I/O - woot woot
const [result] = await db.execute('SELECT * FROM meals')      // db.query(...) ou db.execute(...) <-- melhor
console.log(`First meal is: ${result[0].mealName}`)

Fazendo consultas

As consultas são feitas por meio do método:
```
// só faz consulta
db.query(query)
// consulta e armazena plano de execução ✅
db.execute(query)
```
- query é uma string contendo uma consulta SQL
- retorna uma promessa que resolve com um vetor dos elementos:
  1. result, um vetor em que cada elemento é um registro do resultado da consulta (para SELECTs)
  2. fields, contém metadados adicionais dos resultados
db.execute(...) faz a consulta e armazena o plano de execução para agilizar próximas solicitações dessa mesma consulta

Exemplos de consultas: refeições dos Hobbits

Um SELECT:

const [result, fields] = await db.execute('SELECT name, time FROM meals')
result.forEach(meal => console.log(`${meal.time} - ${meal.name}`)

Saída:
- 07:00 - Breakfast
- 09:00 - Snd Breakfast
- 11:00 - Elevensies
- 13:00 - Luncheon
- 16:00 - Afternoon Tea
- 18:00 - Dinner
- 20:00 - Supper
Além do SELECT, vejamos também INSERT, DELETE e UPDATE…

Inserindo um registro

Também é usado o método db.execute(query, params), mas há duas diferenças:
- Segundo argumento por onde passamos valores para a consulta
- Resolução da promessa: result.affectedRows tem o número de registros afetados na operação e result.insertId o código de auto-incremento do registro (se houver)

Exemplo de INSERT:

const nomeDaRefeicao = 'Tea'
const [result] = await db.execute('INSERT INTO food (id, name) VALUES (NULL, ?)', [nomeDaRefeicao])
console.log(`Comidas inseridas: ${result.affectedRows} com id ${result.insertId}`)

Daria pra concatenar o valor de parâmetro na string de consulta (em vez do ?), mas deve-se tomar cuidado com ataque SQL-injection. Faça como mostrado, ou concatene usando db.escape(nomeDaRefeicao).

Excluindo um registro

Análogo à inserção de registro. Exemplo:

const [result] = await db.execute('DELETE FROM food WHERE id=?', [foodId])
console.log(`Comidas excluídas ${result.affectedRows}`)

Se quiser montar a consulta, ficaria: ```js const foodId = db.escape(req.params.foodId) const [result] = await db.execute(DELETE FROM food WHERE id=${foodId})

Atualizando um registro

Análogo à inserção e exclusão de registro, porém…
O 2º argumento da callback possui result.changedRows com o número de registros alterados.

Exemplo:

const [result] = await db.execute(`
  UPDATE food
  SET name="bad"
  WHERE name LIKE '%?%'`, ['elvish'])
console.log(`Comidas alteradas: ${result.changedRows}')

Tratamento de erros

Usando o pacote mysql2/promises devemos proteger as chamadas de db.query/execute:
1. ⬇️ Em blocos try/catch, se usando async/await
2. Registrada em .catch(...) ou 2º argumento de .then, se promessas ⬇️

try {
  const [result] = await db.execute('...', [...])
  // faz coisas com result

} catch (erro) {
  console.error(erro)
  erro.mensagemAmigavel = 'Erro ao ...'
  throw erro
}
db.execute('...', [...])
  .then(([result]) => {
    // faz coisas com result
  })
  .catch(erro => {
    console.error(erro)
    erro.mensagemAmigavel = 'Erro...'
    throw erro
  })

Operações em Transações

Transações

Quando há uma sequência de operações que devem ser atômicas (executa todas ou nenhuma), podemos usar o conceito de transação dos SGBD relacionais

const transaction = await db.getConnection()
try {
  await transaction.beginTransaction()
  await transaction.query('SET FOREIGN_KEY_CHECKS = 0;')
  await transaction.query('TRUNCATE TABLE `zombies`.`person`;')
  await transaction.query('TRUNCATE TABLE `zombies`.`zombie`;')
  await transaction.query('SET FOREIGN_KEY_CHECKS = 1;')
  await transaction.query("INSERT INTO `zombies`.`zombie` ...")
  await transaction.query("INSERT INTO `zombies`.`person` ...")
  await transaction.commit()

} catch (error) {
  await transation.rollback()
} finally {
  await transaction.release()
}

Envio de Formulários

Recebendo info no servidor

Relembrando <form>
Métodos GET/POST
Tipo de conteúdo

O Elemento HTML `<form>...</form>`

Um formulário é um conjunto de campos de dados (i.e., entrada/escolha) que pode ser enviado a um servidor Web. Exemplos:
- Ao se cadastrar no Facebook (ou qualquer site)
- Ao preencher e enviar um questionário
- Ao editar seu perfil em algum site
Além de enviar os dados, podemos também configurar os campos com algumas restrições (e.g., campo obrigatório)

Formulário e Botões

Um form agrupa inputs para, posteriormente, serem enviados a um servidor (por exemplo, para cadastrar um usuário):

<form action="cadastrar-usuario.php"> <!-- que "página" receberá os dados -->
  <label>Nome: <input name="nome" type="text"></label>
  <label>E-mail: <input name="email" type="email"></label>
  <label>Senha: <input name="senha" type="password"></label>

  <button type="submit">Enviar</button> <!-- veja no próximo -->
  <button type="reset">Limpar</button>  <!-- slide -->
</form>

Exemplo de formulário

Envio de dados de formulário

<form action="/" method="GET" enctype="application/x-www-form-urlencoded">
  ...
</form>

Quando um <form> é submetido, o navegador envia requisição do tipo method="TIPO" para action="ENDERECO" contendo todos os campos preenchidos
- Campos: <input>, <select>, <textarea>
- Atributos:

action ~ URL para onde os dados serão enviados

method ~ GET: dados são colocados na querystring da URL ~ POST: dados enviados no corpo da requisição

enctype ~ application/x-www-form-urlencoded codifica dados “URL-friendly” ~ multipart/form-data para upload de arquivos

Exemplo: O que é, o que é?

O que é terrível, verde, come pedras e mora debaixo da terra??

Exemplo do monstro verde

Conheça o Incrível Monstro Verde</style> que Come Pedras e Mora Debaixo da Terra

O terrível monstro verde (etc. etc.) está com fome e você deve dar comida para ele. Ele acaba de ir para a superfície e para que ele não comece a comer pessoas, você deve dar a ele seu segundo alimento preferido: pedras.

Para isso, você deve ir até onde ele está e enviar algumas pedras para ele. Atualmente, ele está neste endereço: https://terrivel.cyclic.app/monster. Para dar comida a ele, você deve encomendá-las a partir de um formulário html.

Formulário com `GET` e com `POST`

::: figure . height: 90%; width: 270px;

Grota do monstro

:::

<form action="https://terrivel.cyclic.app/monster" method="GET">
  <input name="nome" type="text">
  <input name="num_pedras" type="number" step="1" min="0">
  <input name="corCeu1" id="corCeu1" type="color">
  <select name="tipo_pedras">
    <option value="marroada">Marroada</option>
    <option value="ametista">Ametista</option>
  </select>
  <input name="tipo_pedras_sortidas" type="radio" value="não" checked>não
  <input name="tipo_pedras_sortidas" type="radio" value="sim">sim

  <button type="submit">alimentar monstro</button>
  <button type="submit" formmethod="POST">alimentar monstro</button>
</form>

Dados são enviados usando atributo name
Botões submit podem alterar o <form>:
1. formaction
2. formmethod
3. formenctype

Para receber os dados

Em uma aplicação Express:

// método GET
app.get('/monster', (req, res) => {
  // pega valores da querystring
  // via req.query.NAME
  //
  res.render('monster', {
    nome: req.query.nome,
    num_pedras: req.query.num_pedras
    corCeu1: req.query.corCeu1,
    tipo_pedras: req.query.tipo_pedras,
    /*...*/
  })
})
// método POST
app.post('/monster', (req, res) => {
  // pega valores do corpo da requisição
  // via req.body.NAME
  //
  res.render('monster', {
    nome: req.body.nome,
    num_pedras: req.body.num_pedras
    corCeu1: req.body.corCeu1,
    tipo_pedras: req.body.tipo_pedras,
    /*...*/
  })
})

Requisições enviadas via GET e POST

GET /monster HTTP/1.1
Host: terrivel.cyclic.app?nome=Fl%C3%A1vio+Coutinho
  &num_pedras=5&tam_pedras=3.5&corCeu1=%2384d6d7
  &corCeu2=%233572e3&tipo_pedras=espinela
  &tipo_pedras_sortidas=n%C3%A3o

GET /monster HTTP/1.1
Host: terrivel.cyclic.app
    
nome=Fl%C3%A1vio+Coutinho&num_pedras=5&tam_pedras=3.5
&corCeu1=%2384d6d7&corCeu2=%233572e3...

GET vs POST

Característica	GET	POST
Visibilidade	Dados visíveis ao usuário	Dados “ocultos”
Segurança	Menos seguro	Mais seguro
Restrição de tamanho	Tamanho da URL (~2048)	Sem restrição
Restrição de tipo de dados	Apenas ASCII	Sem restrição
Botão voltar	Ok	Dados serão ressubmetidos
Ad. aos favoritos	Ok	Não é possível
Histórico do navegador	Parâmetros são salvos	Parâmetros não são salvos

Outros métodos (além de GET/POST)

Formulários HTML permitem métodos GET e POST
Mas podemos querer enviar também DELETE, PUT e outros

No Express, podemos usar:

Instalar pacote method-override: npm i method-override

Configurar middleware:

app.use(methodOverride('_method', { methods: ['GET', 'POST'] }))

Em links e formulários, usar ?_method=XXX. Exemplos:

<a href="/people/?_method=DELETE" class="link-danger">Excluir</a>

<form action="/people/eaten?_method=PUT" method="POST">
 ...
</form>

Arquitetura REST

Usando HTTP para entidades de dados

Relembrando HTTP
Definição
Exemplos
Negociação de conteúdo

Relembrando o HTTP

Protocolo para comunicação entre cliente e servidor
Modelo de requisição e resposta
Gere recursos na web, que podem ser:
1. Páginas
2. Imagens
3. Scripts
4. Folhas de estilo
5. Fontes
6. Vídeo etc.
Operações sobre recursos feitas pelos verbos HTTP (GET, POST…)
Recursos identificados por URLs
Prevê possibilidade de caching de recursos
É totalmente stateless

Ideia do REST: dados como recursos

Os dados são vistos como um recurso HTTP (assim como uma imagem, uma página HTML etc.)
- Cada informação exposta pelo banco de dados tem uma URL
- Operações (buscar, excluir, atualizar etc.) são realizadas na informação usando verbos HTTP (GET, DELETE, POST, PUT etc.)
Stateless (sem estado)
- Nenhum contexto é armazenado após o atendimento de uma requisição
“Cacheável”
- Clientes podem guardar as respostas, se interessante
Uniformidade de interface
- As operações e as URLs são padronizadas e fáceis de infereir

Uma API REST

API: conjunto de métodos públicos de um programa

API REST: conjunto de métodos públicos expostos por meio de um web service na arquitetura REST

::: figure .floating-portrait-container.push-right ::: Proposto por Roy Fielding em 2000 (tese de doutorado)
Abordagens: purista ou “inspirada”
Como fazer?
1. Identifique os recursos de dados do banco
2. Identifique as operações sobre recursos que são permitidas
3. Implemente os métodos para cada recurso, respondendo possivelmente em vários formatos (.html, .json, .xml)

Exemplo de API REST (1/5)

Vamos criar uma API REST de acesso ao banco de dados de um cemitério zumbi fictício
Devemos identificar os recursos de dados e as operações sobre eles
Veja o banco de dados:

Exemplo de API REST (2/5)

Recursos:
1. Zumbi (na URL /zombies/)
2. Pessoa (na URL /people/)
  - Por exemplo: jardim-zumbi.com/people/
Operações:
1. Listar todas as pessoas (e.g., GET /people/)
2. Listar todos os zumbis (e.g., GET /zombies/)
3. Ver detalhes de um zumbi (e.g., GET /zombies/8)
4. Converter pessoa em zumbi (e.g., POST /zombies/brains/)
5. Matar uma pessoa completamente (e.g., DELETE /people/4)

Exemplo de API REST (3/5)

Usando express, podemos definir as rotas usando verbos HTTP: Vamos definir o método que lista todas as pessoas:
```
app.get('/people/', async (req, res) => {
  const [result] = await db.execute('SELECT * FROM person')
  res.render('list-of-people', { pessoas: result })
})
```
- Omitido aqui: (a) tratamento de erros, (b) paginação (se tiver) e ( c) negociação de conteúdo (se tiver)

Exemplo de API REST (4/5)

A rota para listar todos os zumbis é análoga. Vamos agora mostrar o detalhamento de um zumbi:

app.get('/zombies/:id', async (req, res) => {
  const id = db.escape(req.params.id)   // pega o parâmetro "id" no caminho da rota (eg, 4 em /zombies/4)

  try {
    const [result] = await db.execute(`SELECT * FROM zombie WHERE id=${id}`)
    if (result.length === 0) {
      throw new Error(`Ninguém conhece um zumbi com id ${id}.`)
    }

    res.render('detail-of-zombie', { zumbi: result[0] })

  } catch (error) {
    res.send(404, "Zumbi inexistente")

  }
})

Omitido: negociação de conteúdo (se houver)

Exemplo de API REST (5/5)

O método para excluir um Zumbi:

app.delete('/zombies/:id', async (req, res) => {
  const id = req.params.id
  const [result] = await db.execute(`DELETE FROM zombie WHERE id=?`, id)
  res.redirect('/zombies/') // ou 'back' para voltar à mesma URL de antes
})

Omitido: tratamento de erros, negociação de conteúdo

Negociação de conteúdo

Negociação de conteúdo (na MDN)

É a ideia de servir diferentes representações de um mesmo recurso sob uma mesma URL
Por exemplo: mesmo recurso porém em idioma, formato ou codificação diferente
Há diversos cabeçalhos HTTP de requisição que servem esse propósito:
1. Accept
2. Accept-Charset
3. Accept-Encoding
4. Accept-Language
O cliente especifica um ou mais deles e o servidor então escolhe qual representação enviar na resposta

Exemplo de negociação de conteúdo

A Star Wars API (https://swapi.dev) tem diferentes representações para um mesmo recurso:

Formato ~ HTML ou JSON ~ Via cabeçalho Accept: text/html ou Accept: application/json

Língua ~ Inglês ou Wookie ~ Via parâmetro de query string format=wookiee

Testando usando o comando curl:

$ curl -H "Accept: application/json" https://swapi.dev/api/people/1

Respondendo HTML e JSON

Uma API REST costuma responder apenas em JSON
Mas podemos usar negociação de conteúdo para transformar o back-end servir como uma API REST também

No Express, fazemos assim:

app.verbo('caminho', async (req, res) => {
  const [dados] = await db.execute(...)
  const contexto = {
    dados
  }

  res.format({  // <-- res.format recebe um objeto cujas props. são callbacks
    html: () => res.render('view', contexto),
    json: () => res.send(dados)
  })
})

Padrão REST e modelo de maturidade

Padrão de rotas REST

Cada entidade que admita todas as operações CRUD:

GET /entidade ~ Lista todos os membros da entidade

POST /entidade ~ Cria nova entidade

GET /entidade/:id ~ Detalhes da entidade com certo id

HEAD /entidade/:id ~ Apenas cabeçalhos da resposta

DELETE /entidade/:id ~ Exclui a entidade com certo id

PUT /entidade/:id ~ Atualiza campos da entidade com certo id

Devem ser usados códigos de status do HTTP nas respostas. Exemplo:
- 200 Ok
- 201 Created
- 204 No content
- 400 Bad Request
- 401 Unauthorized
- 404 Not Found
- 405 Method Not Allowed

Modelo de maturidade de Richardson (🌐)

Modelo de 4 níveis para avaliar sua API Rest:
1. Exportar API sobre HTTP
2. Exportar recursos em vez de métodos
3. Uso adequado dos verbos HTTP
4. Exportar hipertexto para possibilitar descoberta API

Maioria atende até (2), mas devemos buscar (3) tornar as APIs auto-navegáveis. Exemplo de resposta para GET /account/12345:

HTTP/1.1 200 OK

{
  "account": {
    "account_number": 12345,
    "balance": {
      "currency": "usd",
      "value": 100.00
    },
    "links": {
      "deposits": "/accounts/12345/deposits",
      "withdrawals": "/accounts/12345/withdrawals",
      "transfers": "/accounts/12345/transfers",
      "close": "/accounts/12345/close"
    }
  }
}

Entrando no …

Jardim Zumbi 🧟

Fictício

Atividade de hoje
Roteador no Express
Redirecionamento
Mais sobre templates
Mensagens flash

Atividade de hoje 🧟

O é um simulador de jardins-infestados-por-zumbis-de-noite-mas-que-de-dia-as-pessoas-frequentam
O programa já possui quase todas as funcionalidades implementadas, exceto:
1. A rota e a lógica de banco para excluir uma pessoa
2. A rota e a lógica de banco para adicionar uma pessoa
3. Fazer negociação de conteúdo para listagem de pessoas
Seu trabalho é implementar essas funcionalidades faltantes
- Crie um fork do repositório cefet-web-zombie-garden e clone-o
- Suas alterações devem ser feitas no arquivo router/people.js, que descreve as rotas que começam com /people/

Roteador do Express (na documentação)

Quando uma aplicação Express cresce, ela possui muitas rotas e é importante organizar

Podemos usar Routers para representar cada parte do fluxo

// routes/zombies.js
import express from 'express'
const router = express.Router()

router.get('/', cb)       // lista todos zumbis
router.post('/', cb)      // cria novo zumbi
router.delete('/:id', cb) // exclui
router.put('/:id', cb)    // atualiza



export default router
// app.js
import express from 'express'
import index from './routes/index.js'
import people from './routes/people.js'
import zombies from './routes/zombies.js'
const app = express()

// roteador é um middleware
app.use('/', index)
app.use('/people', people)
app.use('/zombies', zombies)
// ...

Registramos o roteador com o prefixo /zombies (todas suas rotas o possuem)

Layout e templates parciais no handlebars (1/2)

É super comum aplicações web repetirem alguns pedaços em várias páginas: Exemplo:
- O cabeçalho
- O menu
- Barra lateral
- Rodapé

Usando handlebars no Express, podemos ter: (a) um layout e (b) templates parciais

Exemplo: layout.hbs:

<!DOCTYPE html>
<html>
<head>...</head>
<body>
  <!-- inclui 2 partials -->
       
      
  } <!-- "buraco"
                 do body -->
</body>
</html>

Exemplo: index.hbs:

<main>
  <h1>Título</h1>
      
  <div>
    <!-- ...-->
  </div>
</main>

Exemplo: header.hbs:

<header>
  <img src="..." alt="..">
  <nav>...</nav>
</header>

Layout e templates parciais no handlebars (2/2)

Para os layouts, o nome layout.hbs é usado por padrão

É possível definir outro arquivo ao renderizar:

res.render('nome-da-view', { layout: 'nome-do-layout'})

…ou…

app.set('view options', { layout: 'nome-do-layout' }) // mesmo layout para todas views

E para os templates parciais, precisamos especificar sua pasta:

import hbs from 'hbs'
const __dirname = new URL('.', import.meta.url).pathname
  
hbs.registerPartials(`${__dirname}/views/partials`, console.error)

Mensagens flash

Aplicações web interativas costumam apresentar feedback das ações
Podemos usar “mensagens flash”
- Mensagem será mostrada apenas 1x na próxima renderização
- Usa recurso de sessão de usuário

Como usar no Express:

import session from 'express-session'
import flash from 'connect-flash' // habilita req.flash(nome, valor)
app.use(session({ secret: 'lalala', resave: false, saveUninitialized: true }))
app.use(flash())

app.post('/zombies', (req, res) => {
  // ...faz coisas...
  req.flash('sucesso', 'Zumbi nasceu')
  // req.flash('erro', 'Erro ao criar')
    
  req.redirect('/zombies')
})

app.get('/zombies', (req, res) => {
  // ...faz coisas...
  res.render('zombie-list', {
    zombies: [...],
    sucesso: req.flash('sucesso'),
    erro: req.flash('erro')
  })
})

Referências

Documentação do node-mysql
Seções 5.2 do livro “Node.js in Action”
REST vs RESTful: diferença
REST APIs must be hypertext-driven: Roy fielding xingando programadores

cefet_web

Server-side parte 6

Bancos de dados, Formulários, Arquiteturas RESTe o Jardim Zumbi 🧟

Roteiro

Bancos de dados

Acesso aos dados armazenados

SGBDs relacionais

SGBDs NoSQL

Conexão da aplicação com SGBDs

MySQL

MySQL

Primeiros passos (connection vs pool)

Fazendo consultas

Exemplos de consultas: refeições dos Hobbits

Inserindo um registro

Excluindo um registro

Atualizando um registro

Tratamento de erros

Operações em Transações

Transações

Envio de Formulários

Recebendo info no servidor

O Elemento HTML <form>...</form>

Formulário e Botões

Envio de dados de formulário

Exemplo: O que é, o que é?

Exemplo do monstro verde

Formulário com GET e com POST

Para receber os dados

GET vs POST

Outros métodos (além de GET/POST)

Arquitetura REST

Usando HTTP para entidades de dados

Relembrando o HTTP

Ideia do REST: dados como recursos

Uma API REST

Exemplo de API REST (1/5)

Exemplo de API REST (2/5)

Exemplo de API REST (3/5)

Exemplo de API REST (4/5)

Exemplo de API REST (5/5)

Negociação de conteúdo

Negociação de conteúdo (na MDN)

Exemplo de negociação de conteúdo

Respondendo HTML e JSON

Padrão REST e modelo de maturidade

Padrão de rotas REST

Modelo de maturidade de Richardson (🌐)

Entrando no …

Jardim Zumbi 🧟

Fictício

Atividade de hoje 🧟

Roteador do Express (na documentação)

Layout e templates parciais no handlebars (1/2)

Layout e templates parciais no handlebars (2/2)

Mensagens flash

Referências

Bancos de dados, Formulários, Arquiteturas REST
e o Jardim Zumbi 🧟

O Elemento HTML `<form>...</form>`

Formulário com `GET` e com `POST`