AINET - Plataforma Full-Stack Laravel

Contexto

Projeto da unidade curricular de Aplicações para a Internet, ano letivo 2024/25. Fiquei responsável pelo frontend e acabei por cobrir também parte do backend.

O problema

Dois sistemas com regras diferentes a partilhar as mesmas pessoas. Um sócio da associação não é um cliente da loja, mas pode ser as duas coisas ao mesmo tempo — e o que cada um pode ver e fazer muda conforme o papel. Modelar isso sem duplicar utilizadores nem encher o código de condições era o verdadeiro problema. A loja, em si, é trabalho conhecido.

A minha parte

O frontend completo: as vistas, os formulários, o fluxo de compra e os ecrãs de gestão. No backend, corrigi o que era preciso para o frontend se comportar como devia — sobretudo na aplicação de permissões e nas relações entre entidades.

Decisões técnicas

1. Permissões aplicadas no servidor, refletidas no cliente

   Os três níveis de acesso são verificados no backend, em todos os pedidos. O frontend esconde o que o utilizador não pode usar, mas esconder é conveniência, não segurança. Construí as vistas a partir do princípio de que o servidor é a autoridade: o cliente pergunta o que pode mostrar, não decide.

2. Lógica de negócio fora dos controladores

   A framework torna fácil enfiar as regras dentro dos controladores e resolver o problema num dia. Funciona até ao momento em que duas partes da aplicação precisam da mesma regra e ela existe em dois sítios ligeiramente diferentes. Manter a lógica fora custou mais no início e evitou esse tipo de divergência.

3. Um só modelo de utilizador, com papéis

   A alternativa óbvia era ter sócios e clientes como entidades separadas. Teria sido mais rápido de construir e garantia de problemas assim que a mesma pessoa fosse as duas coisas. Um só utilizador, com papéis atribuídos, mantém a identidade única e põe a complexidade onde ela pertence: nas permissões, não na duplicação de dados.

O que correu mal

A equipa não se organizou. Não combinámos ao início quem fazia o quê nem o que cada parte esperava da outra, e o resultado apareceu todo de uma vez, no fim, quando foi preciso juntar as peças.

Acabei a fazer a minha parte e uma parte do que faltava. Não por escolha — porque à medida que o prazo se aproximava, as peças que não encaixavam eram as que impediam a aplicação de funcionar, e alguém tinha de as fazer encaixar.

Aprendi que a organização de uma equipa não é burocracia que se acrescenta a um projeto técnico. É parte do projeto técnico. Duas frases combinadas no primeiro dia — quem faz o quê, e o que é que a tua parte me vai devolver — teriam poupado semanas.

Resultado

Aplicação funcional, com demonstração publicada.

O que faria diferente

Combinaria as interfaces entre as partes antes de alguém escrever código, e integraria desde o primeiro dia em vez de deixar para o fim. Conflitos que aparecem cedo são pequenos e resolvem-se numa tarde; os mesmos conflitos no fim aparecem todos ao mesmo tempo e já não há onde os pôr.