Por André Blos Aliatti
Depois de bastante estudo, refatoração e validação de base técnica, subi a primeira versão funcional do MedicFlow, uma aplicação web full stack para gestão clínica e prontuário eletrônico.
Mais do que “colocar um projeto no ar”, esse deploy representou uma mudança importante no meu processo de aprendizado. Até certo ponto, estudar backend, frontend, banco de dados e segurança parece uma coleção de assuntos separados. Quando a aplicação entra em produção, essas partes finalmente deixam de ser teoria isolada e passam a funcionar como sistema.
O MedicFlow nasceu com foco em arquitetura organizada, separação de responsabilidades e evolução gradual. A ideia não era simplesmente montar telas e endpoints, mas estruturar uma base que suportasse crescimento sem virar um projeto frágil logo nas primeiras mudanças.
O que foi publicado nesta primeira versão
Essa primeira entrega já coloca em produção um fluxo real de aplicação web, com backend, frontend e banco integrados.
Entre os elementos que já estão funcionando, estão:
- autenticação de usuário
- interface de login
- dashboard inicial
- estrutura de agenda e consultas
- gestão de pacientes
- integração entre frontend e API REST
- persistência em banco PostgreSQL
- versionamento de banco com Flyway
Ou seja, não é apenas um protótipo visual. Já existe uma base funcional com regras, persistência e comunicação entre camadas.
Stack utilizada
A primeira versão do MedicFlow foi construída com a seguinte stack:
- Backend: Java 21 + Spring Boot 3.2.5
- Banco de dados: PostgreSQL
- Migrações: Flyway
- Segurança: JWT com JJWT
- Frontend: React + TypeScript + Vite
- Arquitetura de API: REST com paginação e filtros
A escolha dessa stack não foi aleatória. Ela atende bem um tipo de aplicação que exige organização, segurança, persistência consistente e separação clara entre responsabilidades.
Arquitetura: mais importante do que “fazer funcionar”
Uma das decisões centrais no projeto foi não tratar backend como um bloco único de código.
A aplicação segue uma divisão em camadas e responsabilidades bem definida:
- Controller → entrada da API e exposição dos endpoints REST
- Service → regras de negócio
- Repository → acesso aos dados via JPA
- DTOs → separação entre modelo interno e contrato da API
Essa estrutura não existe apenas por formalidade. Ela ajuda a evitar um erro muito comum em projetos iniciantes: colocar regra de negócio em qualquer lugar, misturar acesso a dados com validação e criar classes difíceis de manter.
Quando essa separação é respeitada desde cedo, o sistema fica mais previsível, mais fácil de testar e menos doloroso de evoluir.
Controle de acesso e segurança
Outro ponto importante nessa primeira versão foi a implementação de autenticação e autorização com JWT.
O sistema já trabalha com perfis de acesso, como por exemplo:
- ADMIN
- MÉDICO
- e outros papéis planejados na evolução do projeto
Esse controle de acesso evita tratar segurança como “ajuste final”. Em sistemas reais, principalmente na área de saúde, segurança não é adereço. Ela precisa fazer parte da arquitetura desde cedo.
O que os prints mostram
1. Tela de login
A tela de login já representa a entrada real da aplicação, conectada ao backend e integrada ao fluxo de autenticação.
Ela deixa claro que o projeto não está restrito a endpoints testados por Postman. Já existe uma camada de interface funcionando como parte do produto.
2. Dashboard inicial
O dashboard mostra a aplicação já organizada como sistema de uso real: navegação lateral, visão geral do dia, consultas, agendamentos e pendências.
Esse tipo de tela é importante porque exige integração entre:
- backend
- frontend
- modelagem de dados
- status de negócio
- organização visual
É justamente nesse ponto que a ideia de aplicação full stack começa a fazer sentido na prática.
3. Infraestrutura em produção
O print do Railway mostra a aplicação distribuída em serviços, com backend, frontend e banco funcionando em ambiente cloud.
Isso é relevante porque deploy muda a natureza do projeto. Enquanto tudo roda localmente, muitos problemas ainda estão escondidos. Quando a aplicação vai para produção, entram em jogo variáveis de ambiente, CORS, conexão com banco, organização de serviços, configuração de build e vários detalhes que não aparecem em tutoriais simplificados.
Funcionalidades já implementadas
Nesta primeira versão, o MedicFlow já conta com:
- CRUD de pacientes
- gestão de consultas
- agenda inicial
- prescrição de medicamentos vinculada à consulta
- estrutura base para exames e evolução clínica
- paginação e filtros no frontend consumindo a API
Esses elementos já formam uma base coerente para continuar evoluindo o sistema sem precisar recomeçar a arquitetura.
Testes e consistência
Além da funcionalidade visível, a aplicação também já conta com testes para validar comportamento e reduzir fragilidade.
Entre os tipos de testes implementados, estão:
- testes unitários com JUnit e Mockito
- testes de integração com Spring Boot Test e MockMvc
- validação de regras de negócio
- testes de autenticação e autorização
Esse ponto importa porque colocar software em produção sem testes até pode parecer rápido no curto prazo, mas normalmente cobra um preço alto depois.
O que esse deploy representou tecnicamente
Esse deploy foi importante não só porque o projeto “subiu”, mas porque ele consolidou vários conceitos que, separados, parecem abstratos:
- arquitetura em camadas
- API REST
- autenticação com JWT
- consumo de API no frontend
- versionamento de banco
- deploy em cloud
- integração entre serviços
Na prática, esse tipo de projeto ensina mais do que estudar cada assunto isoladamente. Ele obriga a conectar decisões técnicas com comportamento real do sistema.
Próximos passos
A primeira versão do MedicFlow já está funcional em produção, mas ainda é uma base inicial.
Os próximos passos incluem:
- refinamento da segurança
- melhorias de performance
- evolução dos módulos clínicos
- expansão dos fluxos administrativos
- amadurecimento da experiência de uso
O objetivo não é transformar rapidamente o projeto em “produto final”, mas evoluí-lo com consistência técnica.
Conclusão
Subir a primeira versão do MedicFlow foi um marco importante porque tornou visível algo que no estudo isolado nem sempre aparece: software é integração de camadas, decisões e responsabilidades.
Não basta fazer tela.
Não basta fazer endpoint.
Não basta conectar banco.
O que realmente diferencia uma aplicação que pode evoluir de outra que trava cedo é a estrutura construída por trás.
O MedicFlow ainda vai crescer bastante, mas essa primeira versão já cumpre um papel importante: provar que a base está de pé.
Assinatura
André Blos Aliatti é desenvolvedor em construção, compartilhando sua jornada real na tecnologia, com foco em backend, frontend e projetos práticos.