Bem-vindo ao nosso projeto Gerenciador de Empresas! Este é um sistema simples que permite que os usuários se cadastrem, façam login e gerenciem empresas com facilidade. O projeto backend foi construído com NestJS, uma estrutura poderosa para Node.js que promove uma arquitetura escalável e organizada.
https://github.com/Rharan-Ru/monke-challenger-frontend
- CRUD Usuários
- CRUD Companias
- Autenticação JWT
Back-end: Node, NestJs, Swagger, TypeORM, MariaDB, JWT, Jest, Typescript
Para rodar esse projeto, você vai precisar adicionar as seguintes variáveis de ambiente no seu .env, você pode encontrar um exemplo no arquivo .env.example:
NODE_ENV=development
FRONTEND_URL=http://localhost:4200
DB_TYPE=mariadb
DB_HOST=localhost
DB_PORT=3306
DB_USERNAME=root
DB_PASSWORD=root
DB_DATABASE=challenge
SECRET_KEY=challenge
Clone o projeto
git clone https://github.com/Rharan-Ru/monke-challenger-backend.git
Entre no diretório do projeto
cd monke-challenger-backend
Verifique se o docker está instalado na sua máquina, primeiro de permissão e instale o docker caso nescessário, execute o comando na pasta root do projeto
chmod +x install_docker.sh
./install_docker.sh
Inicie o servidor com docker-compose
docker compose -f docker-compose-dev.yml up
Após iniciar o servidor, você pode acessar a documentação da API através do Swagger, que fornece uma interface interativa para explorar as rotas disponíveis.
-
Inicie o servidor (se ainda não o fez):
docker compose -f docker-compose-dev.yml up
-
Acesse a url do swagger
http://localhost:3000/api
Para rodar os testes, rode o seguinte comando
npm run test
Para ver a cobertura de testes utilize
npm run test:cov
Este projeto foi estruturado e pensado para garantir escalabilidade, organização e facilidade de manutenção. Abaixo estão as principais decisões técnicas tomadas ao longo do desenvolvimento:
Optei por uma estrutura de pastas inspirada na Clean Architecture para garantir uma organização clara e uma escalabilidade fácil. Esta abordagem facilita a localização dos códigos, permitindo modificações com mais simplicidade e sem comprometer a legibilidade do projeto. Além disso, a separação de responsabilidades promove uma base mais sólida, preparada para futuras abstrações ou integrações mais complexas, caso necessário.
Escolhi o TypeORM como ORM (Object-Relational Mapping) pela sua simplicidade e excelente suporte ao TypeScript. O NestJS possui integração nativa com o TypeORM, o que facilita a configuração e permite criar consultas e relações de forma intuitiva e eficiente. Isso agiliza o desenvolvimento e reduz a complexidade na manipulação dos dados.
Ao invés de usar uma única entidade de empresas (companies), optei por um modelo SaaS (Software as a Service), onde cada usuário pode criar e gerenciar múltiplas companies. Isso garante que os dados de cada usuário sejam isolados, permitindo que cada um utilize a aplicação sem interferir nos dados de outros usuários. Essa abordagem fortalece a segurança e flexibilidade do sistema, permitindo que ele seja escalável conforme o crescimento da base de usuários.
Optei por utilizar Jest para os testes do projeto, já que ele é nativamente suportado pelo NestJS. A integração é fácil e direta, o que torna o processo de criação de testes conveniente. Para um projeto simples como este, o Jest oferece a cobertura necessária para garantir a confiabilidade do código sem a complexidade de setups adicionais.
A dockerização do projeto foi uma escolha estratégica para simplificar o processo de deploy e garantir que o ambiente de desenvolvimento seja o mais consistente possível. Com o Docker, qualquer pessoa pode rodar o projeto sem se preocupar com o versionamento de dependências ou a configuração de serviços externos. Isso melhora a portabilidade e diminui os riscos de problemas de compatibilidade em diferentes máquinas.
Para evitar a criação de um monólito, separei o backend e o frontend em repositórios diferentes. Essa separação permite um fluxo de deploy mais simplificado e possibilita o uso de plataformas específicas para cada parte da aplicação. No caso deste projeto, o Railway foi utilizado para o backend e o Vercel para o frontend. Isso também oferece maior flexibilidade para escalar e manter cada parte da aplicação de maneira independente.