After a long time without (hardcore) web development, I find myself in the seat of an intern trying to give some live to a static web application intended to handle thousands of data records stored somewhere in the cloud.
The final work is hard to predict at the moment, and the reason for that is the challenge of having to take every decision concerning the architecture of the website.
Let's go back to the beginning.
Scenario:
- intranet application / front-end layout provided
- data services via a public API
- stateless user session control
- back-end routing management
Firstly, the fact that it is an intranet application gave me that feeling of 'oh, boy, I'd better do this right !' but it's just a website. The second thing that should not be considered harmless is the used of a public API for managing data. The latter can be as dangerous as querying the database with root privilege. Third, to add a level of anxiety, all users will have access to the application without any user information being store at the server nor the client side. At last, all the different user interfaces have to be nicely routed!.
Then of course, It seems as It all fits beautifully into an MVC (Model View Controller). Every UI will have its own controller and view, and the data sets will be matched with one or various API calls very easily.
For Fucks Sakes !, the MVC is like having three freaking levels of complexity and every day they complicate the whole model.
I will continue, my goal is DRY (Don't Repeat Yourself) and stick to the principals; Controllers provide, Models produce, Views consume.
Language chosen: PHP (mother of god!)