Voxelytics frontend

[normanrz]

Steps to test:

• Get voxelytics and elasticsearch
• Set the WORKFLOW_URL env var to http://localhost:9000
• Set the DEFAULT_WEBKNOSSOS_URL env var to http://localhost:9000
• Set the WORKFLOW_TOKEN env var to a valid auth token in the above configured webKnossos instance
• Run vx voxelytics/connect/test/configs/segem_test_2d.yaml --cpu
• Open http://localhost:9000/workflows

fixes #6468

---

(Please delete unneeded items, merge only when none are left open)

• Merge together with Voxelytics routes #6416
• Ready for review

[philippotto]

didn't test yet and only skimmed the new modules, but looks good overall 👍 will try to test now.

[philippotto]

If you want to lazy-import a vx bundle, it might be useful to add these types to a new module. In general, we should reorganize some code a bit (e.g., this module currently imports the store which imports the sagas which imports a big part of the code base). However, this is rather out of scope for this PR.

[normanrz]

I think it makes more sense to refactor that in a coordinated effort. If moving these types in a separate file, we at least also need to move the vx-related functions from admin_rest_api.ts to a separate file.

[philippotto]

a comparison of the old and new bundle sizes would be interesting before we merge this.

[normanrz]

a comparison of the old and new bundle sizes would be interesting before we merge this.

6.6M vs 7.2M uncompressed (calculated with yarn build && du -csh public/bundle/*.{js,css})

Bundle splitting turns out to be quite difficult :-/

[philippotto]

a comparison of the old and new bundle sizes would be interesting before we merge this.

6.6M vs 7.2M uncompressed (calculated with yarn build && du -csh public/bundle/*.{js,css})
Bundle splitting turns out to be quite difficult :-/

I had a look at the devtools on https://master.webknossos.xyz vs https://vxfrontend.webknossos.xyz/ and there the difference is 381 kB vs. 380 kB for main.js (so, basically nothing) and 1.1 MB vs. 966 kB for vendors~main.js. So, this means bundle splitting would probably only be beneficial to separate the new vendors code into a new module. Is this also difficult? Either way, it's probably not really necessary, right now (given the numbers). Still, it would be good to know whether further vendor splitting might be doable without too much effort.

[philippotto]

🍭

[normanrz]

Still, it would be good to know whether further vendor splitting might be doable without too much effort.

It could be done, but we'd need to rework the code splitting config in webpack. We need to figure out how to assign stable names to the individual bundles (currently, hard-coded to vendors~main) or figure out dynamic imports in our system (currently, the vendors bundle is statically imported via HTML script tags).