Nada melhor para provar que aprendemos algo do que quando colocamos em prática. Pensando nisso, sempre desejei desenvolver um projeto de portfólio onde eu pudesse criar do zero resolvendo um problema real: realizar um estudo de caso, definir arquitetura, modelar o banco de dados e implementar as práticas que, ao meu ver, eram as melhores.

Há alguns anos surgiu essa oportunidade: uma amiga abriu uma cafeteria/lanchonete, coisa fina, e ela uniu o seu talento a uma oportunidade de negócio. Porém, controla tudo por planilha e anotações num caderno de entrada/saída que fica próximo ao balcão.

Então, conversando com ela, decidi unir o útil ao agradável: vamos construir um ERP sob medida que atenda a este nicho específico e que resolva um problema real. Ao final do processo, ela terá uma solução e eu terei um projeto de portfólio que decidi deixar público no meu GitHub, bem documentado e com o código aberto sob a licença Apache 2.0. Assim, qualquer pessoa desenvolvedora poderia assumir esse projeto para manutenções e estudos de caso, ou até mesmo alguém com uma necessidade parecida poderia baixar e rodar uma instância para si, por que não?

Implementar dessa forma me permite duas coisas: a primeira é ter um case real, pois geralmente projetos de portfólio que saem da nossa própria cabeça são simples e vagos, o que os torna pouco efetivos para resolver um problema real (o famoso software que ninguém usa); a segunda é a constância, pois ter um compromisso nos deixa mais focados para entregar algo e, como complemento, decidi fazer isso de forma pública.

Então vos apresento o NTO-ERP, acrônimo para Nascimento, que é o meu sobrenome, mais a palavra ERP. Nada original, mas foi o máximo que consegui.

Para este projeto, cujo objetivo seria virar uma vitrine pessoal, decidi escolher a stack com a qual já estou habituado.

Vou montar o backend com Java e Spring Boot, explorando tanto quanto for possível o ecossistema do Spring e seguindo o padrão REST de nível 3, o chamado Glory of REST. A implementação levará em conta a separação de domínio e regras de negócio, além dos princípios do 12-Factor App.

A segunda decisão foi o banco de dados. Conheço e já trabalhei com alguns como Oracle DB, MySQL, SQL Server e o PostgreSQL, pelo qual sempre me interessei. Até comecei a trabalhar com o MySQL, mas, por questões de licenças futuras, optei por usar o PostgreSQL utilizando o Flyway como sistema de controle de versão para o banco. Para conectar o banco à API, usaremos o Spring Data JPA. Para testes unitários, teremos o JUnit com Mockito, documentação com o Swagger e, para autenticação e segurança, o Spring Security. Cada tópico desse será tratado separadamente lá na frente.

Para o frontend, pensei em fazer de duas formas: em Angular utilizando as bibliotecas do PrimeNG ou em Flutter, onde a ideia seria criar um app para instalar num tablet que poderia se tornar móvel ao se deslocar da bancada. Porém, para manter a simplicidade, optei mesmo pela versão web com Angular, pois é a tecnologia que mais domino. Terei o cuidado de torná-lo responsivo e fluido tanto na tela de dispositivos móveis quanto no acesso web para utilizar ferramentas de controle de gestão, que poderiam facilmente ser acessadas por um desktop. Mais uma vez, brilha aqui a UX e a responsividade da escolha web.

A decisão sobre hospedagem ficou sendo uma escolha via VPS, pois, além de ser mais em conta, posso realizar a configuração manual de toda a minha infraestrutura e utilizar tecnologias como Docker e Kubernetes para gerenciar pods de microsserviços. Será uma experiência inédita para mim.

A ideia por trás disso tudo é documentar e ir acompanhando o desenvolvimento de um projeto real, que pode servir de apoio e inspiração para muita gente ou apenas para mim mesmo quando olhar para trás e ver o trabalho que deu construir um portfólio que vai além de uma Pokédex.

Convido você a acompanhar comigo e dar um estrela em nosso repo no GitHub:

Front: https://github.com/jonathannto/nto-front
Back: https://github.com/jonathannto/nto-api