Skip to content

GitLab

Last edited by pablo.alles
Page history

arquitetura

Home Escopo Processo Design/Mockups Configuração Arquitetura Gerência BD Qualidade Frontend Backend Analytics

Arquitetura

Esta página centraliza informações sobre o arquitetura do projeto e a infraestrutura da AWS utilizada para execução do projeto.

Sumário

Diagrama de deploy

Abaixo, é possível visualizar o diagrama de deploy do projeto:

Como é possível ver, além das tecnologias de Frontend e Backend, utilizam-se os serviços da AWS abaixo para execução da aplicação:

  • Bucket S3: para hospedar as imagens dos estabelecimentos cadastrados na aplicação.
  • Repositório ECR: para hospedar as imagens dos containers (Backend, PostgreSQL, e GitLab Runner).
  • SES: para permitir o envio de e-mail para os usuários, em caso de recuperação de conta ou notificação sobre atualizações dos estabelecimentos cadastrados.
  • 1 Instância EC2 (t2.small): 1 instância para hospedar a API Backend, o banco de dados PostgreSQL e o Runner do Gitlab, e o servidor nginx, containerizados.

No dia 27/03/2024, foi realizada uma estimativa dos custos para manter a infraestrutura do projeto por 1 semestre na AWS utilizando a calculadora da AWS, considerando os quatro serviços citados acima. Neste dia, o custo financeiro estimado a cada mês e ao final do semestre foram:

  • Custo Mensal: 12,99 USD
  • Custo Semestral: (12,99 USD * 6) = 77,94 USD
  • Custo Anual calculado pela AWS: 155,89 USD

Para este custo mensal, os detalhes de estimativa de cada serviço considerados foram:

  • Amazon EC2
    • Região: US East (Ohio)
    • Custo inicial: 0,00 USD
    • Custo mensal: 12,05 USD
    • Tipo de locação: Instâncias compartilhadas
    • Sistema operacional: Linux
    • Carga de trabalho: Uso constante
    • Quantidade de instâncias: 1
    • Tipo de instância: t2.small
  • Amazon Elastic Container Registry
    • Região: US East (Ohio)
    • Custo inicial: 0,00 USD
    • Custo mensal: 0,50 USD
    • Quantidade de dados armazenados: 5 GB por mês
  • Amazon Simple Email Service (SES)
    • Região: US East (Ohio)
    • Custo inicial: 0,00 USD
    • Custo mensal: 0,20 USD
    • Mensagens de e-mail enviadas do EC2: 1000 por mês
    • Mensagens de e-mail enviadas do cliente de e-mail: 1000 por mês
  • Amazon Simple Storage Service (S3)
    • Região: US East (Ohio)
    • Custo inicial: 0,01 USD
    • Custo mensal: 0,24 USD
    • Armazenamento S3 Standard: 10 GB por mês
    • Como os dados serão movidos para S3 Standard? Solicitações PUT, COPY, POST, LIST para S3 Standard
    • Número mensal de solicitações PUT, COPY, POST, LIST para S3 Standard: 1000
    • Número mensal de GET, SELECT e todas as outras solicitações do S3 Standard: 1000
    • Dados retornados pelo S3 Select: 3 GB por mês
    • Dados verificados pelo S3 Select: 3 GB por mês
    • Tamanho médio de objetos do S3 Standard: 5

Diagrama de deploy - versão 2

Durante a Sprint 4 do projeto, quando foi implementada a história de usuário US04 - Recuperar a Conta, a equipe encontrou algumas dificuldades em configurar o envio de e-mail utilizando o Amazon SES, dado que este por padrão iniciava no modo Sandbox. Diante disso, optamos por utilizar o serviço SMTP da ferramenta Mailtrap, que era de fácil configuração e possuia um limite de uso grátis que supriria adequadamente as necessidades da POC desenvolvida durante o semestre.

Diante disso, o diagrama de deploy foi ajustado para incluir o Mailtrap, conforme abaixo:

OBS.: Ressalta-se que no código implementado na API Backend do projeto as configurações de email estão parametrizáveis por variáveis de ambiente, não estando atrelado a nenhuma tecnologia específica. Diante disso, para passar a utilizar o SES ou outra tecnologia em um ambiente produtivo, é muito simples.

Ambientes utilizados

Durante a Sprint 2 (segunda Sprint de desenvolvimento de código no projeto) percebeu-se a necessidade de existir um ambiente de desenvolvimento para testar e validar as alterações sendo integradas no projeto, antes da entrega das mesmas no ambiente produtivo. Isso porque, durante esta Sprint, não era possível subir as alterações recém-feitas mas ainda não validadas no ambiente produtivo, pois este mesmo ambiente era utilizado pelos stakeholders ao acessar o aplicativo.

Assim, segmentou-se os containers executando na instância EC2 da AWS em dois ambientes distintos:

  • Ambiente produtivo: onde é executado o código validado e entregue aos stakeholders ao final da última Sprint.
  • Ambiente de staging: ambiente de desenvolvimento, o qual é atualizado a cada commit na branch develop durante um ciclo de desenvolvimento. É o ambiente a ser utilizado para testes anteriores ao code freeze durante a Sprint.

Para ersta segmentação, duplicou-se os containers do PostgreSQL e da API Backend do projeto e criou-se duas redes internas do Docker, como pode ser visto na imagem abaixo. As duas redes customizadas são compartilhadas com o container do nginx, enquanto o container do GitLab Runner fica em uma rede isolada.

Além disso, cada um dos ambientes poderia ser acessado a partir de URLs diferentes, configuradas por meio do Cloudflare:

Arquitetura geral da aplicação

Backend

Conforme descrito na página sobre o Backend do projeto, optou-se por uma abordagem de arquitetura em camadas no desenvolvimento da API Backend, cujas camadas podem ser vistas no diagrama abaixo:

Frontend

Conforme descrito na página sobre o Frontend do projeto, optou-se por trabalhar com o framework React Native que fornece suporte tanto para iOS quanto para Android tendo os seguintes elementos descritos na imagem abaixo que controlam o fluxo de informações que aparecem nas interfaces do aplicativo:

Com isso, como podemos ver temos as telas que são apresentadas ao usuário e os elementos dentro dessas telas seriam os componentes (botões, inputs, cards, etc), representados pelos component1, component2, component3 e component4 na imagem. A partir das telas, representadas por screen1 e screen2, o usuário interage com as funcionalidades do aplicativo, cuja navegação é definida pelo sistema de roteamento, representado pelo routing. Para conexão com o backend apresentada anteriormente no diagrama de deploy, utilizou-se o Axios que é um cliente HTTP baseado em promessas para Node javascript assim realizando o compartilhamento de informações com o banco de dados através do backend na AWS.