# Análise - Saleor Commerce
Ferramenta dockerizada e separada por 7 containers (número razoável de containers):
- PostgreSQL (banco relacional);
- Redis (banco "volátil");
- Jaeger (ferramenta de terceiros para monitoramento de requisições para API);
- Celery (tarefas assíncronas);
- API (backend API em Django);
- Dashboard (página administrativa do lojista em React);
- Storefront (página de compra dos clientes em React).

## Inicialização dos containers
Estes dois últimos em React, após rápida análise junto a Silas, parecem bem escritos, utilizam ferramentas para melhoria de performance, mas são considerados na própria documentação pesados e talvez ocorra um problema de timeout no momento de subir os containers. Caso ocorra uma forma de aumentar o tempo limite é colocar o comando desta forma: ***COMPOSE_HTTP_TIMEOUT=300 docker-compose up***
Porém como é apenas um paliativo seria bom entender o que poderia ser feito para agilizar o "up" dos containers.

## Testes automatizados
Melhorar performance na execução de testes da API também é muito importante, pois está consumindo praticamente toda a memória da máquina. No caso presente com 8GB de RAM, executando apenas o sistema (Ubuntu + Docker Compose) fica com cerca de 1GB/1,5GB disponível inicialmente (a tendência com o tempo é reduzir o consumo provavelmente devido ao worker que termina de executar suas tarefas ao ser iniciado). Porém no momento de executar a rotina de testes está restando 100MB/200MB. Quando executado pela primeira vez e o navegador estava aberto com consumo próximo a 1GB a máquina travou e precisei reiniciá-lo através do botão da máquina.

Durante os testes simulei com containers desligados (Storefront, Celery, Jaeger) para verificar se havia alguma integração que pudesse justificar tal consumo, mas foi verificado que mesmo quando o Storefront estava desligado (2,5GB livres) a rotina de testes consumiu a memória até o valor supracitado. Ou seja, o consumo não é fixo, mas parece utilizar quase a totalidade de recursos que a máquina dispuser.

## Código do projeto
Existem 3 apps no código do projeto, a API (saleor), o Storefront (saleor-storefront) e o Dashboard (saleor-dashboard). Os apps API e Dashboard possuem locale com alguns termos em pt-br.

### Storefront
Utiliza o webpack para empacotar, minificar e dispor as páginas. Além de utilizar alguns plugins para facilitar desenvolvimento e melhorar performance na entrega de arquivos.

#### Página inicial da loja
Alguns aspectos oferecidos pelo front:
- Logo da loja centralizado superior;
- Lista de categorias no canto esquerdo superior editável;
- Perfil do usuário, carrinho e campo para busca no canto superior direito;
- Destaque através imagem e link para promoções no centro;
- Itens em destaque listados na sequência com preço original e preço promocional;
- Imagens representando categorias na sequência, com possibilidade para categoria em destaque;
- Redes sociais no abaixo;
- Possibilidade de link institucional, termo de responsabilidade, entre outros no rodapé.

#### Categorias
Possuem subcategorias, página própria com totalidade dos itens inclusos, filtros por atributos e ordenação customizada, além de indicar total de produtos na página. Observação: apenas um número de itens prévios é mostrado provavelmente para ter um ganho de performance em não carregar todos os itens na página sempre que a abrir.

As subcategorias possuem páginas similares às previamente retratadas, com o detalhe que são mais específicas para aquela subcategoria como os filtros por exemplo.

#### Produto
As páginas de detalhe do produto possuem as imagens referentes a este com uma destas ampliada ao centro da tela, campos de seleção de um atributo atrelado ao produto (exemplo, volume de um balde de tinta, tamanho de uma camisa), campo para quantidade e botão para adicionar ao carrinho (ação dinâmica). Abaixo possuem abas de descrição e atributos do produto. Ainda mais abaixo sugestões de outros produtos da mesma categoria (similares).

#### Fluxo de Compra
- Possui carrinho com possibilidade adicionar e remover dinamicamente itens em sua própria aba (inclusive anonimamente);
- Busca por nome do produto abrindo aba lateral dinâmica;
- Não possui remoção de apenas uma quantidade específica do item de forma dinâmica na aba do carrinho, mas possui na página do carrinho de forma dinâmica;
- Login e Logout dinâmicos;
- Permite compra anônima (dados necessários serão pedidos durante checkout), criação de usuário antes do checkout ou logar usuário antes do checkout.

#### Possui os steps no checkout:
- Endereço, para seleção e adição destes vinculados ao usuário logado (possui nome, sobrenome, nome da empresa [opcional], telefone [validação ao submeter step, necessário o código do país e do estado], primeira parte do endereço, segunda parte do endereço, cidade, CEP, país, estado/província);
- Envio, seleção do frete (com precificação) e tabela com subtotal e total da compra com exibição unitária dos itens e precificação dos mesmos;
- Pagamento, endereço de faturamento permite seleção do endereço pré-selecionado, mais opções de endereço supracitadas; opção de aplicar um voucher de cartão-presente ou código de desconto (validado ao submeter o step); seleção de forma de pagamento;
- Revisão, visualização de todos os dados preenchidos para confirmar compra;
- Página de confirmação de compra, aviso de notificação via email, possibilidade de acessar detalhes do pedido ou continuar comprando.

#### Detalhe do pedido
Resumo do pedido, contendo todos as informações relativas ao pedido, desde a forma de pagamento ao valor do frete e endereço de entrega (contendo todos os dados passados de entrega incluindo telefone e email).

Navegação entre os steps não perde os dados ao avançar ou retornar.
**Não estão implementados cartões de crédito ou integrados sistemas de pagamento (exemplo Pagseguro), ou pelo menos disponibilizados no ambiente de desenvolvimento.**
**Email não foi disparado de fato, foi printado como tarefa assíncrona no worker.**
**Não consegui localizar código de rastreio inputado no dashboard, nem mensagem enviado pelo lojista**

### API
Quase 3 mil testes foram criados, inclusive a um específico para o timeout descrito na inicialização.

### Dashboard
Ainda não foi analisado.

#### Faturar
Ao faturar itens do pedido levantou uma exceção relativo ao modelo ***Fulfillment*** no worker, necessário investigar.
É possível enviar o mesmo produto de localidades diferentes (continentes) e cancelá-los individualmente.
É possível estornar o pedido e enviar uma nota, mas ainda não sei se ambos entram no worker e são executados em horário específico para que a informação chegue ao Storefront para o usuário, pois não as encontrei.

#### Tradução
Posso estar esquecendo de algo, mas inputei a tradução de Category -> Categoria e não apareceu na página, necessário investigar melhor.

## Branch utilizada
A respeito da branch utilizada na montagem inicial foi a master pois não consegui acessar tags ou outras branchs com versões fechadas (exemplo: 2.10, 2.9...)