Arquitetura de Software
O estilo arquitetural adotado no projeto Pet Fast é baseado em camadas, distribuindo recursos através da utilização do estilo cliente-servidor. As camadas utilizadas são descritas em duas pastas:
A estrutura geral de cada componente é uma pasta contendo o nome do componente, armazenando um arquivo index.js e um arquivo style.css. No entanto, uma pasta chamada estabelecimento dentro de componentes se apresenta como uma exceção a estrutura padrão vigente, contendo dois arquivos .js e dois arquivos .css.
A tabela abaixo relaciona cada componente utilizado a sua respectiva responsabilidade:
| Nome do Componente | Responsabilidade |
|---|---|
| AddProducts | Componente para cadastro de produtos |
| AddSection | Componente para incorporação de uma nova seção de produtos |
| Birds | Componente utilizado para renderizar todos os produtos para pássaros |
| Carrinho | Componente utilizado para retornar ao usuário o total a ser pago no carrinho, captar o endereço de entrega e realizar a finalização da compra |
| Cats | Componente utilizado para renderizar todos os produtos para gatos |
| CompraFinalizada | Componente que mostra tela de confirmação de compra efetuada com sucesso e encaminha para o acompanhamento dos pedidos |
| consumerProfile | Componente que retorna informações de perfil do usuário. Além do mais, possibilita o deslogamento da conta e a exclusão da conta |
| Dogs | Componente utilizado para renderizar todos os produtos para cachorros |
| estabelecimento* | Componente utilizado para cadastro de estabelecimentos. Responsável pela renderização das informações do estabelecimento e dos produtos do estabelecimento |
| Header | Componente utilizado para renderizar o cabeçalho da home do site, possibilitando a navegação para outras páginas |
| HeaderLoja | Componente utilizado para renderizar o cabeçalho da tela da loja, possibilitando a navegação para outras páginas |
| Home | Tela de início do site |
| homeLoja | Tela de início da loja |
| Login | Componente para realização do login no site como usuário |
| LoginEstabelecimento | Componente para realização de login no site como estabelecimento |
| Lojas | Componente utilizado para renderizar informações da loja |
| menu | Componente responsivo utilizado para navegação para as telas de perfil, início e carrinho (mobile) |
| navbar | Componente responsável pela navegação entre as seções de produtos |
| OptionRegistration | Componente de seleção de registro de usuário ou registro de estabelecimento |
| pedidoEmAndamento | Componente que renderiza todos os pedidos vigentes, contendo detalhes de cada pedido |
| pedidos | Componente que mostra o total do valor dos pedidos |
| Rabbit | Componente utilizado para renderizar todos os produtos para coelhos |
| storeOrders | Componente que renderiza todos os pedidos recebidos de alguma loja |
| storeProfile | Componente que renderiza informações do perfil da loja, possibilitando o deslogamento do site e a exclusão da conta |
| UserRegistration | Componente responsável pelo registro dos usuários (não estabelecimento) |
A imagem a seguir representa o diagrama de pacotes referente aos componentes da tabela:
Para o backend, foi criado o componente app.js a fim de definir as rotas e integrar o sistema ao banco de dados. Na pasta routes, encontram-se os componentes responsáveis pela manipulação dos dados dos usuários, produtos, lojas, pedidos e compra. Vale ressaltar que a integração do backend com o frontend ocorre através da API Axios.
A tabela abaixo relaciona cada componente utilizado a sua respectiva responsabilidade:
| Nome do componente (.js) | Responsabilidade |
|---|---|
| app | Integra o sistema ao banco de dados MongoDB, inclui as rotas e inicializa o framework Express |
| carrinho | Componente utilizado adição e exclusão de produto(s) para compra, a partir das informações de usuário e produto |
| lojas | Componente utilizado para armazenar informações sobre o cadastro da loja, bem como nome, endereço, animais atendidos, contato e site |
| lojasInfo | Componente utilizado para o gerenciamento das lojas (adição, remoção e atualização) das informações |
| pedido | Componente utilizado para verificação de pedidos |
| produtos | Componente utilizado para o gerenciamento dos produtos de determinada loja (adição, remoção, verificação e atualização) |
| produtoInfo | Componente utilizado para atribuir o produto ao usuário e a loja |
| usuario | Componente utilizado para gerenciamento (adição, remoção, atualização e verificação) de usuários |
A imagem a seguir representa o diagrama de pacotes referente aos componentes da tabela:
Atualmente o projeto segue uma arquitetura em camadas e de cliente-servidor, recomendamos que essas arquiteturas sejam mantidas pois são as mais apropriadas para o desenvolvimento WEB, no entanto, algumas alterações nas organizações de pastas são recomendáveis para melhorar a escalabilidade do projeto.
Segundo o conceito de Single-responsibility principle cada componente deve ter apenas uma função, no estado atual a pasta de Routes está sendo usado para mais funcionalidades do que o necessário, portanto, para o Backend, recomendamos a reorganização do código para um modelo com Controller, Model e Routes. sendo a responsabilidade de cada um as seguintes
| Módulo | Responsabilidade |
|---|---|
| Routes | Módulo que define as rotas para cada funcionalidade do sistema. |
| Controller | Módulo que interage com o front-end realiza a lógica e regras de negócio das requisições |
| Model | Módulo que manipula e modela a estrutura do banco de dados. |
| App | Ponto de partida do Back-end. É nesse arquivo que é feita a conexão com o MongoDB. Esse arquivo inicia o App Express e inclui o arquivo de rotas. |
Para o front-end recomendamos uma reorganização na pasta de componentes, outra melhoria seria a troca dos arquivos chamados "index.js" e "style.css" para suas funções verdadeiras pois isso melhora a legibilidade do código além disso seria bom a exclusão de um dos arquivos "assets" (há um dentro de public e outro dentro de src) pois pode ser confuso qual utilizar.
Exemplo de reorganização de pastas:
-
Decorator: Esse padrão é útil pois ele cria um modelo padrão que pode ser incrementado com novas funcionalidades e aparências distintas, para esse projeto ele será útil pois ele possui duas principais instancias, a do usuário loja e a do usuário comprador. Os desenvolvedores podem criar telas básicas para ambos com funcionalidades gerais e incrementar suas funções conforme necessidade do usuário.
-
Observer: Para um site de compras é essencial o uso de notificações para compradores e lojistas e o o padrão Observer é muito útil para isso pois ele observa um evento e quando ele acontece envia uma notificação para todos os observadores.
Utilizamos a ferramenta lighthouse embutida no navegador Google Chrome para realizar os testes de performance na aplicação.
Observação: como na data de entrega do trabalho o backend da aplicação não estava funcionando (como pode ser visto no canal do grupo em questão no teams), decidimos fazer os testes usando o backend mockado, ou seja, os resultados aqui mostrados não coincidirão com os resultados que seriam obtidos usando o lighthouse na aplicação final, com backend e banco de dados.
Primeiramente o lighthouse foi utilizado no modo de navegação, que analisa o carregamento de uma única página.
Esse modo tem como casos de uso: Obter uma pontuação do Lighthouse Performance e todas as métricas de desempenho. Avaliar os recursos de um Web App Progressivo. Analisar a acessibilidade imediatamente após o carregamento da página.
Limitações do modo de navegação: Não é possível analisar envios de formulários ou transições de aplicativos de página única. Não é possível analisar o conteúdo que não está disponível imediatamente no carregamento da página.
Rodando o lighthouse no modo de navegação (padrão), com o dispositivo sendo como mobile, foram coletadas as seguintes métricas:
- First Contentful Paint (Primeira pintura de conteúdo): 2,3 s
- Largest Contentful Paint (Maior pintura de conteúdo): 5,0 s
- Total Blocking Time (Tempo total de bloqueio): 490 ms
- Cumulative Layout Shift (Mudança cumulativa de layout): 0,014
- Speed Index (Índice de velocidade): 2.3 s
Calculando a média dessas métricas usando cada uma seus respectivos pesos, chegamos no resultado final de 67 pontos de performance (sendo o máximo 100).
Já rodando o lighthouse no modo de timespan, que analisou a performance com as interações do usuário durante um curto período de tempo (dessa vez como desktop, e não mobile), os resultados se mostraram um pouco mais promissores.
Casos de uso no modo de timespan:
Medir as mudanças de layout e o tempo de execução do JavaScript em um intervalo de tempo, incluindo interações. Descobrir oportunidades de performance para melhorar a experiência para páginas de longa duração e SPAs.
Limitações do modo de timespan:
Não fornece uma pontuação geral de desempenho. Não é possível analisar métricas de desempenho baseadas em momentos (por exemplo, maior pintura de conteúdo). Não é possível analisar problemas de estado da página (por exemplo, sem categoria de acessibilidade).
De 24 pontos totais, nesse modo, a aplicação recebeu 18, o que dá 75% dos pontos totais.
As métricas utilizadas foram:
- Total Blocking Time (Tempo total de bloqueio): 80 ms
- Cumulative Layout Shift (Mudança cumulativa de layout): 0,007
- Interaction to Next Paint (Interação para a próxima pintura): 40 ms
Nesse sentido, essas são algumas medidas que podem ser tomadas para melhorar a performance da aplicação segundo o diagnóstico do lighthouse no modo de navegação:
- Eliminar recursos de bloqueio de renderização
- Reduzir JavaScript não utilizado
- Minificar Javascript (minificar é o processo de remover espaços em branco e qualquer código que não seja necessário para criar um arquivo de código menor, mas perfeitamente válido)
Alguns possíveis problemas com relação à segurança foram encontrados na aplicação, a seguir está a lista deles e algumas sugestões de como resolvê-los.
-
Ataque de Força Bruta
Como não há um numero máximo de tentativas na hora de logar com uma conta, uma pessoa mal intencionada pode procurar fazer o login na conta de outra pessoa através do uso de força bruta sem que nenhum mecanismo o detenha ou atrapalhe.
Sugestão de resolução:
Após um número X de tentativas erradas (5, por exemplo), permitir que haja mais uma tentativa apenas a partir de um certo tempo. Se continuarem as tentativas erradas, aumentar esse tempo ou mesmo bloquear a conta temporariamente.
-
Senha fraca
Segundo um teste, foi preciso apenas um caractere para criar uma senha para uma conta no PetFast. Permitir que um usuário consiga criar uma senha tão fraca é uma porta de entrada para que invasores consigam usar um ataque de força bruta e entrar em uma conta alheia.
Sugestões de resolução (quanto mais sugestões forem acatadas, mais segura a aplicação ficará nesse ponto):
- Colocar um número mínimo e um número máximo de caracteres para a criação de uma senha (Exemplo, 6 e 14).
- Colocar como requisito para a criação de uma senha a presença de pelo menos um número e uma letra.
- Colocar como requisito para a criação de uma senha a presença de pelo menos uma letra maiúscula e uma letra minúscula.