Standalone web UI

[pmeier]

Our web UI is currently sits on top of the REST API and cannot be deployed as a standalone application. This architecture was chosen to avoid giving us a benefit over third-party UIs that have to sit on top of the REST API. Meaning, if the REST API we provide is sufficient for our web UI, it is also sufficient for third-party applications.

However, this requires HTTP communication between the web UI and REST API. Coupled with the fact that we are currently mixing requests from JS (document upload) and Python (everything else) we are also prone to running into CORS issues. See #268 for an example.

Meaning, deploying the Ragna web UI is harder than it needs to be. And the only reason for that is a constraint that we set for ourselves. I feel this was a mistake and we should fix it.

My proposal for this is to create an "backend engine" in Python that uses Ragnas Python API and handles the database connection etc. This engine would then be used by the REST API as well as the web UI to do the actual computation. Here is a picture I drew while discussing this with @blakerosenthal.

In this architecture, we can still deploy the REST API and web UI at the same time, but we now also have the ability to deploy the web UI as standalone. Plus, our original constraint is also somewhat achievable: if the engine is sufficient to drive our web UI and we expose all functionality we need also on the REST API, the REST API should also be sufficient for third-party web UIs.

The only blocker that I currently see is the whole auth workflow. I have plans (and a branch) to implement this properly and fixing #178 in the process. But that probably needs to happen before we have a go at this refactor here. Unfortunately, we are currently blocked by panel, i.e. holoviz/panel#6658 . I plan on working on this soon.