Decouple the front and backends

[Xophmeister]

Currently the webapp functions as a monolithic front and backend through one service. It would be better if they were decoupled into separate services: That is, a backend that exposes, say, a RESTful API and a frontend service that just serves the client (either a single page app, or the more traditional, multi-route app). This would have the following benefits:

• Strict enforcement of single responsibilities (i.e., the frontend would contain no code that manipulates the application state, other than calling the API directly).

• Similar to the above, this would enable the removal of legacy technical debt (e.g., the way in which POST and PUT handlers return a URL string that is picked up by the frontend for redirection; or the way PUT is semantically abused).

• Better scalability: multiple frontend and backend services could be run simultaneously and load-balancing can be performed between their different hosts.

• Potential for multiple frontend clients (e.g., mobile apps).

As a note on scalability: The scheduler would need to be extracted from the API backend, so that multiple schedulers aren't running concurrently. One thus reaches the logical conclusion of microservices, which further enforce single responsibility and maximise scalability.

[piyushahuja]

"sort-of-done, in the sense that there are now separate front and backends. I don't know if all the old frontend stuff has been removed from the backend; if not, it may be worth getting rid of that. The last note is perhaps also worth pursuing (extracting the scheduler from the API server)"