Daphne web UI

[aristotelis96]

This is a first approach to a Daphne UI. It consists of two sub-projects, an API written in python (Flask) and a frontend web ui implemented with Angular. You can read more about how to use or extend the UI in the README files.

The UI contains a main panel used for executing Daphne and an additional "Experiments" tab which contains a few examples that were demonstrated during EuroPar2023 workshop. Users can select to run a Daphne script from the UI, the available scripts displayed can be configured through src/tools/web-ui/backend/config.json (read more backend/README.md).

One major thing missing is testing (both the API and the Angular app), however I believe we can merge it for now and work on this later if we decide to extend it.

I am opening this as a pull request to open a discussion about the location of the UI within the Daphne project.
Please feel free to provide any additional comments or feedback before merging this.

[auge]

I think it's a bad idea to merge it in.
Such tools shall IMHO be put in a separate git repository.

just my 0.02.

KR, Benjamin

[pdamme]

Hi @aristotelis96! First of all, thanks for the awesome work on the Euro-Par demo and the web interface! Such tools on top of the DAPHNE system are great contributions to the project as they can help to demonstrate and disseminate DAPHNE. And it is a great idea to open-source these tools, along with the main system.

Thanks also for initiating the discussion on where to put the code of the demo/web UI. I partly agree with @auge that the main DAPHNE repo may not be the best place for tools on top of DAPHNE. Maybe a sibling repo in daphne-eu would be more suitable, but there are a few pros and cons (no claim of completeness):

Reasons to include tools in the main repo:

1. Better visibility of the tool.
2. Users get everything DAPHNE-related in one "bundle".
3. Contributors of the tool get credit on the main repo (better visibility and incentive for contributions).
4. Easier for developers working on both the main system and the tool.

Reasons to host tools in separate repos:

1. The main DAPHNE system should be generic and easily (re)usable, to my mind. Tools may be tailored to a specific occasion (e.g., a concrete demo at a conference/workshop), or contain other specifics. For instance, this PR contains some VEGA-specific pieces (which is fine for a demo), but most people don't have access to VEGA (which limits the reusability).
2. A tool may be written for a specific version of DAPHNE. If it is included in the main repo, the tool should be updated regularly to adapt to changes in the main system. This requires someone (e.g., the people who contribute the tool) to take care of it. A tool in a separate repo could specify the concrete DAPHNE version (perhaps through a git sub-module), and only be updated when required.
3. Including tools can introduce more dependencies (e.g., Node.js in this case). Even though these dependencies may be required only for the specific tool, explaining to a user/developer what is needed for what could get more complicated. (And DAPHNE already has quite a lot of dependencies.)
4. Including tools in the main repo could complicate the directory structure (including separate/scattered instructions on getting started and dependencies).

Again, tools on top of DAPHNE are definitely a benefit for the project, but we need to decide where to put them. Any opinions and comments are welcome.

[pdamme]

These are just my initial thoughts on the integration of the web interface into the overall project. I haven't looked into the source code in detail yet, though ;) .

[aristotelis96]

Thank you @auge and @pdamme for your feedback! Based on your comments, I also think that maybe it's best to move this into a separate repository under @daphne-eu. We can leave this PR open for now (so others can join the discussion and make any additional improvements :) ) and I can push the final version on the new repository later.

[corepointer]

What about the repo name daphne-eu/web-ui or daphne-eu/daphne-web-ui? Anything's possible ;-)

[corepointer]

Since there was no more discussion about it, I (finally) proceeded with moving this to its own repo and added a submodule as this feature is mentioned in the result highlights of the project.