[TCC] Arquitetura de Software Distribuído
Bom senhores, venho compartilhar convosco minha conquista, acabei de concluir minha pós-graduação em Arquitetura de Software Distribuídos.
Foi um bom curso que me ajudou a enxergar com mais profundidade a complexidade por trás de grandes softwares, e me ensinou a ter um olhar mais crítico quanto à tecnologias, arquitetura e dentre outros. Óbvio que teve matérias (e professores) e ruins, mas de forma geral, foi realmente muito bom.
Vou deixar abaixo a descrição do que eu fiz, e venho pedir encarecidamente a quem puder, que me adicione no LinkeIn e dê um like na publicação original (só para me dá uma ajudada no engajamento rs'): https://www.linkedin.com/feed/update/urn:li:activity:7093240029619077121/
Pois bem, trata-se de uma plataforma integrável para lidar com planos de assinatura e clientes. A ideia central é que a plataforma funcionasse de modo independente aos outros sistemas empresariais, mas que pudesse (caso necessário) se comunicar com os mesmos. O funcionamento é simples, cadastrar clientes, colaboradores, itens, planos e então executar a venda de assinaturas. A vertente de assinaturas vem em crescente, pois a mesma fideliza o cliente, e gera uma renda fixa para a corporação (um pouco mais de estabilidade e segurança no mundo V.U.C.A, parece um sonho não?).
Mas, introdução feita, vamos falar de coisa boa.
O projeto em si, possui quatro premissas:
- Verba orçamentária baixa;
- Equipe reduzida;
- "O prazo era para ontem";
- Precisa estar disponível via web e mobile;
Com base nisso, a decisão arquitetural foi trabalhar com um modelo mais tradicional, onde temos uma aplicação backend (API Rest) e uma aplicação cliente (Web & Mobile).
A stack selecionada foi:
Backend:
- NestJS;
- REDIS;
- Postgres;
- Docker;
- Bull Jobs;
- TypeORM;
Frontend:
- Angular2;
- Ionic;
- PrimeNG;
- Capacitor;
No backend foi aplicado técnicas e conceitos como: Autenticação com JWT, autorização (Claims-based), mapeamento relacional com ORM, migrations, processamento em segundo plano com banco em memória (Bull + REDIS), documentação com Swagger, monitoramento de API (Swagger Status) e dentre outros.
No frontend foi aplicado conceitos e técnicas de componentização, PWA, SPA, responsividade e programação reativa (com Websocket).
Embora o projeto tenha atingido seu objetivo, vale ressaltar que enquanto arquiteto, havia melhores decisões a ser tomada sobre o mesmo. Contudo, devido as restrições impostas, as mesmas não seriam possíveis.
Conforme detalho no relatório entregue à banca, algumas mudanças que eu faria:
- Segregar o projeto WEB do Mobile;
- Utilização de uma autenticação federada de algum serviço CLOUD;
- Retirar endpoints específicos para operar em modelo de microsserviços;
Ainda assim, foi possível obter uma boa performance da aplicação devido ao uso do banco em memória (REDIS) e da biblioteca Bull, que possibilitou o processamento em segundo plano, diminuindo sobrecargas. Somando essa técnica ao uso de programação reativa com Websocket, o tempo de resposta para operações mais demoradas se tornou imperceptível, pois o backend notifica o cliente quando o processamento termina, tornando as operações não-bloqueantes.
O código fonte do projeto se encontra: https://github.com/M4D-MAESTRO/proj-integrador-pos
O relatório pode ser lido em: https://onedrive.live.com/edit.aspx?resid=BF376131D9BEF8C5!2661&ithint=file%2cdocx&wdo=2&authkey=!AP02m2JeL3MvKQQ