|
|
|
| [Home](home) | [**Escopo**](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Gerência](gerencia) | [Código](codigo) | [BD](Banco de Dados) | [Qualidade](qualidade) | [Frontend](frontend) | [Backend](backend) | [Analytics](analytics)
|
|
|
|
| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :---------------: | :--------------------: | ------------: |
|
|
|
|
| [Home](home) | [**Escopo**](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Gerência](gerencia) | [Código](codigo) | [BD](Banco de Dados) | [Qualidade](qualidade) | [Frontend](frontend) | [Backend](backend) | [Analytics](analytics) |
|
|
|
|
| :----------: | :------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :---------------: | :--------------------: | ------------: |
|
|
|
|
|
|
|
|
# Arquitetura
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
| ... | ... | @@ -7,45 +9,48 @@ Esta seção da documentação visa apresentar os padrões arquiteturais gerais |
|
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
|
|
- [Arquitetura E2E](#Arquitetura-E2E)
|
|
|
|
- [Arquitetura de Infraestrutura](#Arquitetura-de-Infraestrutura)
|
|
|
|
- [Arquitetura E2E](#arquitetura-e2e)
|
|
|
|
- [Arquitetura de Infraestrutura](#arquitetura-de-infraestrutura)
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Arquitetura E2E
|
|
|
|
Esta subseção visa apresentar o padrão arquitetural front-back adotado.
|
|
|
|
|
|
|
|
A arquitetura utilizada no projeto é a _Model-View-Controller_, que permite a separação entre as responsabilidades de uma aplicação em três camadas principais que serão responsáveis por organizar o código entre modelos, lógica de negócios e interfaces de forma separada.
|
|
|
|
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.
|
|
|
|
|
|
|
|
#### Models
|
|
|
|
As _Models_ representam a camada de dados da aplicação, representando a lógica de negócios, acesso aos dados além de sua validação e manipulação. Uma de suas responsabilidades é gerenciar o comportamento dos dados e atualizar o banco de dados com as informações mais recentes ou alteradas.
|
|
|
|
### 🔧 Backend (NestJS)
|
|
|
|
|
|
|
|
#### Views
|
|
|
|
A camada de _Views_ é responsável por exibir os dados ao usuário final. Ela representa a interfaces do projeto, recebendo as interações do usuário e retornando respostas de acordo com o planejamento das interações.
|
|
|
|
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:
|
|
|
|
|
|
|
|
#### Controller
|
|
|
|
A camada de _Controllers_ age como um intermediário entre as camadas de _Models_ e _Views_, recebendo as interações do usuário e enviando para a fonte de dados ou solicitando dados ao modelo para que eles possam ser exibidos em tela.
|
|
|
|
|
|
|
|
No projeto Globo Aplausos, o usuário acessa o Frontend via plataforma web (_Views_) que contém componentes reutilizáveis e que se comunicam com as _Controllers_ do Backend para buscar ou atualizar os dados presentes nos modelos (_Models_) inseridos no banco de dados.
|
|
|
|
Essa estrutura permite manter a responsabilidade de cada parte bem delimitada, com fácil escalabilidade e manutenção.
|
|
|
|
|
|
|
|
## Arquitetura de Infraestrutura
|
|
|
|
Esta subseção visa apresentar o padrão arquitetural de infraestrutura adotado.
|
|
|
|
#### Diagrama em alto nível da arquitetura:
|
|
|
|
|
|
|
|
### 📱 Frontend (Expo + React Native)
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
|
|
#### Instâncias utilizadas:
|
|
|
|
- **AWS EC2.** É um serviço de computação em nuvem escalável sob demanda. Esta instância será utilizada para hospedar os containers Docker do Backend, Banco de dados, Cypress e demais Runners do GitLab (CI/CD).
|
|
|
|
A estrutura favorece a separação de responsabilidades e facilita a manutenção do código ao longo do crescimento do projeto.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Arquitetura de Infraestrutura
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
- **AWS ECR.** É um serviço de registro de contêineres que oferece hospedagem para implantar imagens e artefatos de aplicações. Esta instância será utilizada para armazenar as imagens Docker do projeto.
|
|
|
|
### 🖥️ Serviços Utilizados
|
|
|
|
|
|
|
|
- **AWS S3.** É um serviço de armazenamento de objetos. No projeto Globo Aplausos, a S3 será utilizada para armazenar as imagens de usuários e produtos que podem ser cadastrados pelo administrador.
|
|
|
|
- **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.
|
|
|
|
|
|
|
|
#### Vercel
|
|
|
|
### 🔁 Fluxo de Deploy
|
|
|
|
|
|
|
|
Vercel é uma plataforma de hospedagem e automação para o desenvolvimento de plataformas web, com foco na entrega contínua de projetos realizados em estruturas de Next.js. No caso do Globo Aplausos, o Vercel é utilizado como ambiente de produção do `Frontend`, que é atualizado a cada sprint com as alterações enviadas à branch principal do projeto.
|
|
|
|
- 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**.
|
|
|
|
|
|
|
|
|
|
|
|
#### Fluxo de Deploy
|
|
|
|
Nesta seção será apresentado o fluxo de deploy da aplicação do projeto Globo Aplausos.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
Observando a imagem acima, quando uma mudança nova é realizada e adicionada à branch _main_ do `Frontend` ou `Backend` o pipeline realiza os `jobs` específicos para realização do deploy da aplicação. No `Frontend`, o pipeline realiza o deploy para o Vercel, a partir da conexão realizada entre o repositório e a cloud, utilizando as configurações estabelecidas no ambiente e no arquivo `.vercel`. Para o Backend, o processo de deploy segue o mesmo padrão inicial, porém, em vez de mandar as mudanças para o Vercel, o runner do GitLab constrói uma imagem do Backend utilizando a `CLI` da ECR, envia a imagem para AWS que então é utilizada para gerar um novo container do Backend da aplicação. |
|
|
\ No newline at end of file |
|
|
|
A arquitetura do projeto garante escalabilidade, modularidade e uma integração contínua eficiente, promovendo entregas rápidas e seguras ao longo do desenvolvimento. |
