| ... | ... | @@ -18,100 +18,99 @@ Esta seção da documentação visa apresentar os padrões arquiteturais gerais |
|
|
|
|
|
|
|
O projeto **Pagges** adota uma arquitetura baseada no padrão **Model-View-Controller (MVC)**, promovendo a separação clara entre a camada de apresentação, lógica de negócio e persistência de dados.
|
|
|
|
|
|
|
|
# 🔧 *Backend*
|
|
|
|
## 🔧 Backend
|
|
|
|
|
|
|
|
A estrutura do backend foi construída utilizando o framework **NestJS**, com foco em modularidade e escalabilidade. A organização de pastas está dividida da seguinte forma:
|
|
|
|
|
|
|
|
|
|
|
|
Essa estrutura permite manter a responsabilidade de cada parte bem delimitada, com fácil escalabilidade e manutenção.
|
|
|
|
Essa estrutura permite manter a responsabilidade de cada parte bem delimitada, com fácil manutenção e escalabilidade do sistema.
|
|
|
|
|
|
|
|
#### Tecnologias:
|
|
|
|
### 🧰 Tecnologias Utilizadas
|
|
|
|
|
|
|
|
<a href="https://docs.nestjs.com/first-steps">
|
|
|
|
<p align="center">
|
|
|
|
<a href="https://docs.nestjs.com/first-steps">
|
|
|
|
<img src="https://img.shields.io/badge/nestjs-%23E0234E.svg?style=for-the-badge&logo=nestjs&logoColor=white"/>
|
|
|
|
</a>
|
|
|
|
|
|
|
|
<a href="https://www.prisma.io/">
|
|
|
|
<a href="https://www.prisma.io/">
|
|
|
|
<img src="https://img.shields.io/badge/Prisma-3982CE?style=for-the-badge&logo=Prisma&logoColor=white"/>
|
|
|
|
</a>
|
|
|
|
|
|
|
|
<a href="https://docs.docker.com/">
|
|
|
|
<a href="https://docs.docker.com/">
|
|
|
|
<img src="https://img.shields.io/badge/docker-%230db7ed.svg?style=for-the-badge&logo=docker&logoColor=white"/>
|
|
|
|
</a>
|
|
|
|
</p>
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
# 📱 *Frontend*
|
|
|
|
## 📱 Frontend
|
|
|
|
|
|
|
|
O frontend foi desenvolvido utilizando **Expo com React Native** e segue uma organização baseada em responsabilidades, focada em componentes reutilizáveis, separação de lógica, interface e dados:
|
|
|
|
|
|
|
|
|
|
|
|
A estrutura favorece a separação de responsabilidades e facilita a manutenção do código ao longo do crescimento do projeto.
|
|
|
|
Essa estrutura favorece a manutenção e escalabilidade do projeto conforme novas funcionalidades são incorporadas.
|
|
|
|
|
|
|
|
#### Tecnologias:
|
|
|
|
|
|
|
|
### 🧰 Tecnologias Utilizadas
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="https://img.shields.io/badge/React_Native-20232A?style=for-the-badge&logo=react&logoColor=61DAFB"/>
|
|
|
|
</p>
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Arquitetura de Infraestrutura
|
|
|
|
#### Diagrama em alto nível da arquitetura:
|
|
|
|
|
|
|
|
### Diagrama em alto nível da arquitetura:
|
|
|
|
|
|
|
|
|
|
|
|
A infraestrutura do projeto foi construída utilizando **Docker** para orquestração dos serviços, **AWS EC2** para hospedagem do backend e **AWS ECR** para armazenamento das imagens Docker. O frontend é hospedado via **Vercel** com deploy contínuo.
|
|
|
|
A infraestrutura do projeto foi construída utilizando **Docker** para conteinerização dos serviços, **AWS EC2** para hospedagem do backend e **AWS ECR** para versionamento e distribuição das imagens Docker.
|
|
|
|
|
|
|
|
### 🖥️ Serviços Utilizados
|
|
|
|
|
|
|
|
- **AWS EC2:** Instância configurada para rodar containers Docker do backend, banco de dados e testes automatizados.
|
|
|
|
- **AWS ECR:** Armazenamento centralizado de imagens Docker utilizadas nas instâncias.
|
|
|
|
- **Docker:** Utilizado para conteinerizar o backend e seus serviços auxiliares.
|
|
|
|
- **AWS EC2:** Instância configurada para rodar os containers Docker que executam o backend, banco de dados e testes automatizados.
|
|
|
|
- **AWS ECR:** Repositório de imagens Docker utilizado para armazenar e versionar builds da aplicação.
|
|
|
|
- **Docker:** Ferramenta de conteinerização utilizada para empacotar a aplicação backend e suas dependências.
|
|
|
|
|
|
|
|
### 🔁 Fluxo de Deploy
|
|
|
|
|
|
|
|
- Alterações na branch `main` disparam o pipeline do GitLab CI/CD.
|
|
|
|
- O backend é empacotado em uma imagem Docker e enviado ao **ECR**.
|
|
|
|
- A nova imagem é utilizada para atualizar o container rodando na instância **EC2**.
|
|
|
|
|
|
|
|
- O backend é empacotado em uma imagem Docker e enviado ao **AWS ECR**.
|
|
|
|
- A nova imagem é utilizada para atualizar o container rodando na instância **AWS EC2**.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
# Boas práticas no desenvolvimento
|
|
|
|
### O que são códigos de status HTTP ?
|
|
|
|
## 📋 Boas práticas no desenvolvimento
|
|
|
|
|
|
|
|
Sempre que você clicar em um link ou digitar uma URL e pressionar Enter, seu navegador envia um pedido ao servidor web para o site que você está tentando acessar. O servidor recebe e processa a solicitação, e depois envia de volta os recursos relevantes juntamente com um cabeçalho HTTP.
|
|
|
|
### O que são códigos de status HTTP?
|
|
|
|
|
|
|
|
### Sobre as classes de código de status HTTP
|
|
|
|
Sempre que uma requisição é feita a um servidor web, ele retorna um cabeçalho HTTP com um **código de status**, que indica o resultado da operação. Esses códigos são agrupados em cinco classes:
|
|
|
|
|
|
|
|
Os códigos de status HTTP são divididos em 5 “classes", que são:
|
|
|
|
- **1xx –** Informativo
|
|
|
|
- **2xx –** Sucesso
|
|
|
|
- **3xx –** Redirecionamento
|
|
|
|
- **4xx –** Erro do cliente
|
|
|
|
- **5xx –** Erro do servidor
|
|
|
|
|
|
|
|
* **100**s: Códigos informativos indicando que a solicitação iniciada pelo navegador continua.
|
|
|
|
* **200**s: Códigos de sucesso retornados quando o pedido do navegador foi recebido, compreendido e processado pelo servidor.
|
|
|
|
* **300**s: Códigos de redirecionamento retornados quando um novo recurso foi substituído pelo recurso solicitado.
|
|
|
|
* **400**s: Códigos de erro do cliente indicando que houve um problema com o pedido.
|
|
|
|
* **500**s: Os códigos de erro do servidor indicam que a solicitação foi aceita, mas que um erro no servidor impediu o cumprimento da solicitação.
|
|
|
|
### Códigos mais utilizados
|
|
|
|
|
|
|
|
### Os mais utilizados
|
|
|
|
| Código | Significado | Descrição |
|
|
|
|
|--------|------------------------------|---------------------------------------------------------------------------|
|
|
|
|
| 200 | OK | A requisição foi bem-sucedida. |
|
|
|
|
| 201 | Created | Um novo recurso foi criado com sucesso. |
|
|
|
|
| 204 | No Content | Requisição bem-sucedida, mas sem conteúdo a retornar. |
|
|
|
|
| 400 | Bad Request | Requisição malformada pelo cliente. |
|
|
|
|
| 401 | Unauthorized | Autenticação necessária para acessar o recurso. |
|
|
|
|
| 403 | Forbidden | Acesso ao recurso negado, mesmo autenticado. |
|
|
|
|
| 404 | Not Found | O recurso requisitado não foi encontrado. |
|
|
|
|
| 405 | Method Not Allowed | Método HTTP não permitido para o recurso. |
|
|
|
|
| 500 | Internal Server Error | Erro genérico no servidor. |
|
|
|
|
| 502 | Bad Gateway | Gateway ou proxy recebeu resposta inválida do servidor de origem. |
|
|
|
|
|
|
|
|
* **200**: "**OK**". Este é o código que é entregue quando uma página web ou um recurso age exatamente da maneira que é esperado.
|
|
|
|
* **201**: “**Created**”. O servidor cumpriu o pedido do navegador e, como resultado, criou um novo recurso.
|
|
|
|
* **204**: “**No content**”. Este código significa que o servidor processou a solicitação com sucesso, mas não vai devolver nenhum conteúdo.
|
|
|
|
* **400**: "**Bad Request**". O servidor não pode retornar uma resposta devido a um erro no lado do cliente. Veja o nosso guia para resolver este erro.
|
|
|
|
* **401**: “**Not authorized**”. Isto é devolvido pelo servidor quando o recurso alvo não possui credenciais de autenticação válidas.
|
|
|
|
* **403**: “**Forbidden**”. Este código é devolvido quando um usuário tenta acessar algo que não tem permissão para visualizar. Por exemplo, tentar chegar ao conteúdo protegido por senha sem entrar no sistema pode produzir um erro 403.
|
|
|
|
* **404**: “**Not Found**”. Esta é a mensagem de erro mais comum de todas elas. Este código significa que o recurso solicitado não existe, e o servidor não sabe se ele alguma vez existiu.
|
|
|
|
* **405**: “**Method Not Allowed**“. Isto é gerado quando o servidor de hospedagem (servidor de origem) suporta o método recebido, mas o recurso de destino não suporta.
|
|
|
|
* **500**: “**Interal Server Error**”. Este é um código genérico que significa simplesmente “erro interno do servidor”. Algo correu mal no servidor e o recurso solicitado não foi entregue.
|
|
|
|
* **502**: “**Bad Gateway**”. Este código de erro tipicamente significa que um servidor recebeu uma resposta inválida de outro, tal como quando um servidor proxy está em uso. Outras vezes uma consulta ou pedido demorará muito tempo, e por isso é cancelado ou morto pelo servidor e a conexão com a base de dados quebra.
|
|
|
|
### Principais métodos HTTP usados no backend
|
|
|
|
|
|
|
|
### Methods – Backend API
|
|
|
|
- **GET:** Requisita dados do servidor (leitura).
|
|
|
|
- **POST:** Envia dados para criação de um novo recurso.
|
|
|
|
- **PUT:** Atualiza um recurso existente (ou cria, se não existir).
|
|
|
|
- **PATCH:** Atualiza parcialmente um recurso.
|
|
|
|
- **DELETE:** Remove um recurso do servidor.
|
|
|
|
|
|
|
|
Nas requisições, especificamos o que chamamos de método HTTP ou verbo. Na versão 1.1 do protocolo HTTP(que é a que todos usamos atualmente) temos 9 verbos diferentes. Os mais utilizados são:
|
|
|
|
|
|
|
|
**GET**: Essa é a requisição mais comum de todas. Através dessa requisição nós pedimos a representação de um recurso: que pode ser um arquivo html, xml, json, etc.
|
|
|
|
|
|
|
|
**POST**: O método POST é utilizado quando queremos criar um recurso. Quando usamos POST, os dados vão no corpo da requisição e não na URI.
|
|
|
|
|
|
|
|
**PUT**: Requisita que um recurso seja "guardado" na URI fornecida. Se o recurso já existir, ele deve ser atualizado. Se não existir, pode ser criado.
|
|
|
|
|
|
|
|
**DELETE**: Exclui o recurso especificado.
|
|
|
|
|
|
|
|
**PATCH**: Serve para atualizar partes de um recurso, e não o recurso todo.
|
|
|
|
---
|
|
|
|
|
