DAE - Arquitetura Full-Stack & IA

Contexto

Projeto da unidade curricular de Desenvolvimento de Aplicações Empresariais, no 3.º ano da licenciatura. O modelo de dados foi dado pelo docente; o resto foi construído por nós.

O problema

Construir uma aplicação empresarial em Java com controlo de acessos por papéis e funcionalidades de inteligência artificial, com uma exigência que moldou tudo o resto: o ambiente tinha de ser reproduzível por qualquer pessoa, em qualquer máquina, sem depender de instalações locais e sem "no meu computador funciona".

A minha parte

A minha parte era o frontend. Acabei por fazer e corrigir também grande parte do backend.

Decisões técnicas

1. Containerização total, sem exceções

   Backend, base de dados, frontend e o modelo de inteligência artificial — cada um no seu contentor, ligados por rede interna. A alternativa era instalar dependências localmente e documentar o processo num ficheiro de instruções. Escolhi contentores porque um ficheiro de instruções desatualiza-se em duas semanas e um comando único não. O custo é um primeiro arranque lento e mais uma camada para depurar quando alguma coisa falha.

2. Modelo de IA local em vez de uma API externa

   Chamar uma API comercial teria sido mais rápido de integrar, mais barato em hardware e teria produzido melhores respostas. Corri o modelo localmente à mesma, por três razões: os dados nunca saem da infraestrutura, o que num contexto empresarial é frequentemente um requisito e não uma preferência; o custo por pedido é zero, o que muda a economia de qualquer funcionalidade usada com frequência; e a aplicação funciona sem ligação à internet. O custo é real e não o escondo — respostas mais lentas, qualidade inferior a um modelo comercial, e uma exigência de hardware que uma chamada HTTP não tem. Numa aplicação virada para o consumidor teria escolhido a API. Numa aplicação empresarial que lida com dados de clientes, repetiria esta escolha.

3. Emails intercetados em ambiente de testes

   A aplicação envia notificações por email. Em desenvolvimento, esses emails são capturados por um servidor de testes em vez de saírem para o mundo. É uma precaução pequena com uma consequência grande: nenhum endereço real recebe um email de teste, e continua a ser possível verificar exatamente o que teria sido enviado.

4. Aproveitar parte do backend e reescrever o resto

   Parte do backend já estava construída quando percebi que não servia — decisões de estrutura que não aguentavam os requisitos de permissões. Com prazo em cima, a escolha era entre deitar tudo fora e recomeçar, ou avaliar peça a peça. Escolhi a segunda: mantive o que estava correto e reconstruí o que não estava. Deitar tudo fora é mais rápido de decidir e desperdiça trabalho que servia; salvar tudo é mais confortável e arrasta os problemas até ao fim. O meio-termo custou mais tempo a decidir e foi o que permitiu entregar.

O que correu mal

Descobri tarde de mais que parte do backend não estava a servir. Não porque alguém o escondesse, mas porque eu só fui olhar quando precisei de o usar — assumi que estava a andar porque ninguém tinha dito o contrário.

Quando abri o código, encontrei estrutura que não suportava o que o sistema de permissões precisava, e já não havia tempo para recomeçar do zero. Tive de julgar cada parte separadamente e decidir o que salvava e o que refazia, com o prazo a correr.

A lição não é sobre código. É que num trabalho de equipa o progresso presume-se até se ver, e ver custa pouco quando é cedo. Se eu tivesse olhado para aquele código duas semanas antes, a decisão teria sido a mesma e o custo teria sido metade.

Resultado

Aplicação funcional, com demonstração publicada e o ambiente inteiro a arrancar por um comando único.

O que faria diferente

Rever o trabalho de todas as partes cedo e com regularidade, em vez de esperar pelo momento em que preciso delas. Não por desconfiança — porque descobrir um problema cedo custa uma conversa e descobri-lo tarde custa um fim de semana.