Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • garbus-wiki garbus-wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 35
    • Issues 35
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GarbUs
  • garbus-wikigarbus-wiki
  • Wiki
  • arquitetura

Last edited by Angelo Calebe Araujo da Rocha Jul 03, 2021
Page history
This is an old version of this page. You can view the most recent version or browse the history.

arquitetura

Página Inicial

Página da Arquitetura do Sistema

Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto, Como:

  • Segurança
  • Rotas de Backend (Arquitetura funcional)
  • Objects – Backend API
  • Methods – Backend API
  • Arquitetura Não Funcional
  • Diagrama de Pacotes / Componentes (Arquitetura de software)
  • Diagrama de Deploy
  • Documentação sobre aplicação de Design do Projeto
  • Análise dos principios SOLID
  • Code Review

Devem ser apresentados das seguintes formas:

  • Imagens ou Gifs
  • Diagramas ou Sistemas
  • Descrições ou Textos explicativos

Arquitetura

O projeto está dividido em 2 partes:

  • Frontend: É uma Progressive Web Application, ou seja, uma aplicação web que pode ser instalada, utilizando a tecnologia Service Worker, presente nos principais navegadores web do mercado. Desenvolvido em React.js com linguagem Typescript.
  • Backend: É uma RESTful API construída utilizando Spring, que é um dos frameworks Java mais populares do mercado.

Também estão sendo utilizadas as seguintes tecnologias como partes integrantes do projeto:

  • PostgreSQL: Banco de dados relacional open source com mais de 30 anos de desenvolvimento. Um dos mais utilizados no mundo. Utilizado no projeto como persistência de dados.
  • Hashicorp Vault: Uma ferramenta para armazenar senhas e outros segredos de forma segura, com forte criptografia e controle de acesso, e acessível de várias formas (REST API, linha de comando, bibliotecas para várias linguagens de programação). Utilizado no projeto para armazenar senhas e configurações.
  • ** API Google Maps**: API de acesso ao Google Maps.
  • Firebase: Uma plataforma do Google utilizada para desenvolvimento de aplicativos móveis e web. Possui vários recursos prontos para integração, como banco de dados, autenticação, analytics e notificações push. Utilizado no projeto para enviar e exibir notificações push.

Diagrama de componentes

A visão geral dos componentes do projeto pode ser visualizada na imagem abaixo.

Diagrama de implantação

A implantação do projeto é realizada utilizando containers Docker. O repositório garbus-orchestration contém a configuração do docker-compose, responsável pela implantação, que hoje é feita em uma única máquina. Para distribuir em vários hosts, algumas alterações seriam necessárias (provavelmente mudar para o Docker Swarm ou mesmo K8s).

Os componentes Frontend, Backend e Vault são acessíveis apenas pelo Nginx. Endereços:

  • Frontend: https://ages-garbus.duckdns.org
  • Backend: https://ages-garbus.duckdns.org/api/garbus/<rotas>
  • Vault: https://ages-garbus-vault.duckdns.org

Rotas do backend

As rotas do backend estão acessíveis no Postman e documentadas utilizando Swagger.

Run in Postman Swagger

Segurança

Controle de acesso

Há dois tipos de usuários:

  • Operador: Pessoal que faz a limpeza das lixeiras. Tem acesso apenas ao mapa e as lixeiras na aplicação web;
  • Gestor: Gestores da operação. Além do mapa, tem acesso a recursos de cadastro de usuários, zonas, prédios e lixeiras.

O controle de acesso é feito utilizando o conceito de roles. As rotas exclusivas para os gestores não são acessíveis pelos operadores.

Os usuários devem ter login e senha para entrar na aplicação. Os gestores são os responsáveis por criar logins. Ao criar o login, é gerada uma senha aleatória e provisória; Ao logar pela primeira vez, o usuário será obrigado a alterar a senha.

Há um recurso de redefinição de senha, que pode ser feito de duas formas:

  • Na aplicação web, o usuário clica em Esqueci a senha e informa o login. Uma senha provisória é enviada para o e-mail cadastrado, se houver;
  • Na parte administrativa da aplicação web (acessível apenas pelos gestores), o gestor pode redefinir a senha de qualquer usuário. Desta forma, usuários sem e-mail cadastrado também estão cobertos.

Da mesma forma que logando pela primeira vez, o usuário será obrigado a alterar a senha provisória gerada.

Detalhes de autenticação

O mecanismo de autenticação é JWT. Cada token tem 5 horas de duração (configurável no backend) e utiliza criptografia HS256 para validação.

Vault

As senhas e configurações utilizadas no projeto estão armazenadas em uma instância do Vault. As aplicações autenticam-se no Vault utilizando o método AppRole. Podem ser criados usuários para os desenvolvedores e/ou gestores, para fins de gerenciamento.

Ao criar uma instância do Vault, um root token é criado. Esse token dá acesso irrestrito ao cofre, então não é recomendado utilizá-lo a não ser que seja necessário. Também são geradas chaves (em uma quantidade configurável) para deslacrar o cofre (unseal). O Vault é inicializado lacrado, sendo necessárias essas chaves para que as informações salvas no cofre possam ser acessadas.

Acesso Web

A maior parte dos componentes do projeto é acessível apenas através do Nginx. Desta forma, há logs de acesso centralizados.

O acesso pelo Nginx é realizado por HTTPS, utilizando certificados do Let's Encrypt. Este é um requisito para utilizar o Service Worker, que habilita as funções de PWA (aplicativo instalável e notificações).

Clone repository
  • Backend
  • Gerenciamento do Projeto
  • Solução de Problemas: Prettier e quebras de linha
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • Workshops
  • arquitetura
  • banco_dados
  • configuracao
  • Home
  • horarios
  • instalacao
  • mockups
  • requisitos
View All Pages