/s3-fullstack-teste-backend-brunotiberio

Projeto fullstack, desenvolvido na S3 do M6 para a Kenzie Academy Brasil como um teste técnico. Para executar, leia a documentação

Primary LanguageTypeScript

Agenda - Teste Técnico Fullstack S3

Sumário


Resumo

Voltar ao topo

Essa aplicação foi desenvolvida para o teste técnico realizado na sprint 3 do módulo 6 para a Kenzie Academy Brasil no intuito de revisar e treinar testes técnicos para o mercado de trabalho.

O objetivo dessa aplicação é servir como um backend para o projeto fullstack de uma Agenda.

Frontend

Backend

Tecnologias usadas nesse projeto:

1. Desenvolvedor

Voltar ao topo


2. Diagrama de entidades e relacionamentos

Voltar ao topo

ERD


3. Preparativos

Voltar ao topo

3.1. Instalando Dependências

Clone o projeto em sua máquina local e instale as dependências do projeto com o comando:

yarn install

ou

npm install

3.2. Variáveis de ambiente

Voltar ao topo

Crie um arquivo .env no diretório raiz do projeto, copiando o exemplo do .env.example:

cp .env.example .env

3.2.1 Configurando banco de dados

Voltar ao topo

Atribua suas variáveis de ambiente às credenciais do seu PostgreSQL à um database da sua escolha

  • POSTGRES_USER=seu_nome_de_usuário_psql
  • POSTGRES_PWD=sua_senha_psql
  • POSTGRES_DB=nome_do_database

Variável PORT:

  • Não é necessário atribuir uma porta, porém, recomendamos fortemente que seja atribuído a porta 4000 para que o frontend funcione junto com o backend

Variável SECRET_KEY:

  • A SECRET_KEY está no .env.exemplo, basta copiar e colar na variável. Isso foi feito para facilitar a configuração do avaliador, porém, em ambiente de produção, não é recomandado que a SECRET_KEY fique em local visível.

3.3. Execute as migrações para realizar a persistência de dados

Voltar ao topo

yarn typeorm migration:run -d src/data-source.ts

3.6. Rodando a API localmente

Voltar ao topo

Agora que tudo está instalado e configurado, rode a aplicação usando o comando:

yarn dev

Aguarde o processamento e sua aplicação já estará disponível para uso em https://doc-fullstack-m6.vercel.app ou http://localhost:4000/ .


4. Rotas

Voltar ao topo

Documentação da API

Observação: Rode a aplicação como descrito no passo 3

O consumo pode ser feito tanto pelo deploy do frontend (links logo abaixo), pelo Insonmia e pelo clone do repositório do frontend.

É possível acessar à documentação completa para poder utilizar a API.

Nessa mesma documentação é possível adquirir informações sobre os requests, chaves necessárias do request e outras informações importantes para a utilização da API.

Interfaces e Entities desenvolvidas:

  • Users (CRUD completo)
  • Login (POST)
  • Contacts (CRUD completo)

5. Histórico de desenvolvimento

Voltar ao topo

5.1. Objetivo

Voltar ao topo

O Objetivo principal dessa aplicação é a validação dos meus conhecimentos nos seguintes tópicos:

  • Javascript;
  • NodeJs;
  • Express;
  • TypeScript
  • Solucionar demandas;
  • Criar um projeto fullstack com API restfull;
  • Utilizar Frameworks ou bibliotecas (Opcional)

5.2. Decisões de desenvolvimento

Voltar ao topo

5.2.1. Ordem de desenvolvimento

Voltar ao topo

  1. Inicialmente, decidi por começar pela análise do teste proposto, com isso, pude observar e pesquisar quais eram as tecnologias, frameworks e libs que poderiam ser usadas no desenvolvimento.
  2. Iniciei pelo backend, criando a arquitetura do servidor
    1. Interfaces e Entities;
    2. Middlewares
    3. Services e Controllers
    4. Routes
    5. Error e tratamentos
  3. Depois, trabalhei no frontend da aplicação.
  4. Por fim, fiz os demais fix necessários do código e a documentação da API

5.2.2. Interfaces e Entities

Voltar ao topo

Foram criados, no total, 2 entities:

  • User: Onde é feito o CRUD do usuário será o responsável por logar e administrar seus contatos;
  • Contacts: Aqui está o CRUD que pode ser feito pelo usuário devidamente logado;

5.2.3. Middlewares e Schemas

Voltar ao topo

Nessa arquitetura, há duas pastas importantes:

  • Middlewares: Onde ficam armazenados os arquivos funcionam como um serviço intermediário ao services e controllers. São utilizados quando é necessário fazer algum tipo de verificação constante no código, evitando o retrabalho:
    • authToken.middleware: Verifica se o usuário está logado;
    • error.middleware: Usado para repassar ao cliente as mensagens de erro;
    • userIsHimself.middleware: Verifica se o usário logado é dono da requisição;
    • verifyUsernameAvailability.middleware: Verifica se o username está disponível para uso;
    • yupValidate.middleware: Usado para o tratamento dos Schemas de validação feitas pelo YUP;
  • Schemas: Onde ficam os arquivos utilizados pela biblioteca YUP para verificar possíveis erros de requisição nas rotas, gerando uma camada de proteção maior na API.

5.2.4. Pontos não cobertos

Voltar ao topo

  • De todos os feedbacks de erro, o único que não consegui cobrir (está retornando Internal Server Error) é caso em um Update ou List usando um ID.
  • Por questões de tempo, não consegui desenvolver os testes da aplicação pois tive que revisar muita informação relacionada a NodeJS, Express e TypeScript, por isso, decidi por focar na finalização de uma aplicação de qualidade

6. Agradecimentos

Voltar ao topo

Quero agradecer pela oportunidade de fazer o teste técnico e espero ter conseguido cumprir com boa parte daquilo que foi solicitado

Shalom!

Voltar ao topo