AINET - Laravel Full-Stack Platform

Context

A project for the Internet Applications course, academic year 2024/25. I was responsible for the frontend and ended up covering part of the backend as well.

The problem

Two systems with different rules sharing the same people. An association member is not a store customer, but can be both at once — and what each one may see and do changes with the role. Modelling that without duplicating users or filling the code with conditions was the real problem. The store itself is familiar work.

My part

The complete frontend: the views, the forms, the purchase flow and the management screens. In the backend, I fixed what was needed for the frontend to behave correctly — mostly around permission enforcement and the relationships between entities.

Technical decisions

1. Permissions enforced on the server, reflected on the client

   The three access levels are checked in the backend, on every request. The frontend hides what the user cannot use, but hiding is convenience, not security. I built the views on the principle that the server is the authority: the client asks what it may show, it does not decide.

2. Business logic outside the controllers

   The framework makes it easy to push rules into the controllers and solve the problem in a day. That works right up until two parts of the application need the same rule and it exists in two slightly different places. Keeping the logic out cost more up front and avoided that kind of divergence.

3. One user model, with roles

   The obvious alternative was to keep members and customers as separate entities. It would have been faster to build and guaranteed trouble the moment the same person was both. A single user, with assigned roles, keeps identity unique and puts the complexity where it belongs: in permissions, not in duplicated data.

What went wrong

The team did not organise itself. We did not agree up front on who was doing what, or on what each part expected from the others, and the result all arrived at once, at the end, when the pieces had to fit together.

I ended up doing my part and some of what was missing. Not by choice — because as the deadline approached, the pieces that did not fit were the ones stopping the application from working, and somebody had to make them fit.

I learned that organising a team is not bureaucracy added on top of a technical project. It is part of the technical project. Two sentences agreed on day one — who does what, and what your part hands back to mine — would have saved weeks.

Outcome

A working application, with a published demo.

What I'd do differently

I would agree the interfaces between the parts before anyone wrote code, and integrate from day one instead of leaving it to the end. Conflicts that surface early are small and resolve in an afternoon; the same conflicts at the end arrive all together, with nowhere left to put them.