Usuário e equipe técnica acompanham o mesmo fluxo.
Esquema conceitual do fluxo
Contexto
Projeto autoral desenvolvido a partir de um cenário corporativo recorrente: solicitações informais tornam o atendimento difícil de acompanhar e de priorizar.
Objetivo
Organizar o ciclo do chamado sem transferir complexidade para quem precisa de suporte.
Problema e solução
O ponto de partida
Pedidos espalhados, pouca visibilidade sobre o status e ausência de histórico confiável reduzem a capacidade da equipe de operar com previsibilidade.
A resposta
Uma aplicação web com perfis de acesso, fluxo de chamados, histórico e dados operacionais centralizados em uma API protegida.
Arquitetura
Estrutura pensada para evoluir.
Backend REST em Java 21 e Spring Boot 4, em camadas de controllers, services e repositories. O acesso é protegido por Spring Security com JWT; dados são persistidos com JPA em PostgreSQL e evoluem por migrations do Flyway. O cliente usa React, TypeScript, Vite, React Router e TanStack Query. Os serviços podem ser executados juntos com Docker Compose.
Java 21
Spring Boot 4
Spring Security
JWT
PostgreSQL
Flyway
React
TypeScript
Vite
TanStack Query
Tailwind CSS
Docker Compose
Testcontainers
Destaques de engenharia
Segurança
Autenticação stateless com JWT e senhas protegidas com BCrypt
RBAC, CORS explícito e checagem de propriedade do recurso
Dados
PostgreSQL, JPA e Flyway para uma evolução versionada do esquema
DTOs e validação de entrada para manter o contrato da API explícito
Qualidade
Testes com JUnit e Testcontainers usando infraestrutura próxima da real
Histórico de alterações e regras de fluxo concentrados no domínio
Infraestrutura
Docker Compose para subir frontend, API e banco no mesmo ambiente
Decisões e trade-offs
Flyway
Versiona o banco junto do código e reduz divergências entre ambientes.
Testcontainers
Valida a integração com PostgreSQL em testes, sem simular a infraestrutura principal.
JWT
Mantém a API stateless e permite aplicar as regras de acesso em cada requisição.
Docker Compose
Cria um caminho reproduzível para executar os serviços localmente.
Trade-off
A solução permanece como uma aplicação em camadas, com módulos integrados no mesmo backend. Para este domínio, isso concentra a complexidade operacional e mantém o fluxo mais simples de testar e evoluir; serviços separados fariam sentido apenas com necessidades claras de escala ou independência.
Minha participação
Arquitetura e implementação do backend e da API REST
Modelagem do fluxo de chamados, regras de acesso e persistência
Interface web em React e TypeScript
Migrations, testes de integração e ambiente conteinerizado
Resultados e capacidades
Fluxo de atendimento centralizado e rastreável
Base para dashboards, SLA e evolução de regras operacionais
Ambiente local reproduzível para desenvolvimento e testes
