Feature request: Turn KitchenOwl deployment into a monolith

[beatbrot]

What's the feature 🧐

Currently, hosting KitchenOwl yourself requires you to use two containers. One serving the backend and one serving the Web UI.

This approach has some downsides:

• Setup is not as straightforward as it could be, since multiple containers are required
• Contributing features that require changes in backend and frontend must be coordinated across two repositories
• Versions of both containers must stay compatible. There may very well be incompatible combinations of both containers.

I propose the following:

• We unify the repositories by moving all the code of the backend into a "backend" directory in this repository
  • We might loose git history when not doing complex migration logic. This is doable, but though. I saw this work though and I am willing to do this work
  • As an intermediate step, we could use git submodules to include the backend repo into a folder of this repository.
• We let the wsgi serve the WebUI as static file effectively letting tombursch/kitchenowl take over the functionality of ``tombursch/kitchenowl-web`
  • To avoid breaking existing users, we could turn the kitchenowl container into a noop in newer versions.

I know this is a big change and in the end, it's your call. But in my opinion, this change would greatly simplify development and deployment.

Extra information and references

No response

[TomBursch]

I agree that for self-hosting, unifying both is easier. However, having them separate gives me some more control on the main server, where at some point I want to automatically scale frontend/backend containers separately on demand.

It would be best to have tombursch/kitchenowl be the all-in-one container, keep tombursch/kitchenowl-web, and add tombursch/kitchenowl-backend.

We could also create a new repository with both as submodules and its own build actions. Although, I guess the best solution is to merge both, which will include a lot of work.

Some thoughts I have:

I also had some weird issues with using uWSGI as an HTTP server before, that's why I switched to the wsgi protocol on the backend port 5000.

Versions of both containers must stay compatible. There may very well be incompatible combinations of both containers.

This can occur anyway (with slower updates in the app stores or someone manually updating the app on their devices) and the website/app will let you know if they're incompatible and request you to update either.

[beatbrot]

I agree that for self-hosting, unifying both is easier. However, having them separate gives me some more control on the main server, where at some point I want to automatically scale frontend/backend containers separately on demand.

Just out of interest: The "main server" is app.kitchenowl.org?

It would be best to have tombursch/kitchenowl be the all-in-one container, keep tombursch/kitchenowl-web, and add tombursch/kitchenowl-backend.

I like that idea! Makes the common case easy and would still allowed a more complex horizontally scaling solution.

We could also create a new repository with both as submodules and its own build actions. Although, I guess the best solution is to merge both, which will include a lot of work.

I gotta say, I think merging would really be cleaner. Also, I think it wouldn't be too hard. If loosing the GPG signature of your commits would be acceptable to you, I could even open a PR that would merge the repos if you want :) Otherwise, I could try to create a script that you would run so that the commits can be signed by your key. Both variants would take me some weeks though.

I also had some weird issues with using uWSGI as an HTTP server before, that's why I switched to the wsgi protocol on the backend port 5000.

Hmm yeah, we must fix that of course. But I guess there HAS to be some way to get this to work, right? Others must've encountered the same problem.

Thanks for taking your time to respond to my issue!

[Timoses]

I agree that the current situation is not ideal. Especially the discrepancy between versions. What frontend version is compatible with which backend version?

It would be best to have tombursch/kitchenowl be the all-in-one container, keep tombursch/kitchenowl-web, and add tombursch/kitchenowl-backend.

A lot of large-scale projects opt for commands passed to a container to run what is needed. Hence, there's only one container image which is always compatible and can be started as the required component via command given to the container. E.g. docker run kitchenowl frontend or docker run kitchenowl backend.

[TomBursch]

Things left to do:

• Merge Turn KitchenOwl into a monorepo #356
• Notify all community projects of this change
• Update docs docs: Single container install instructions #373
• Update Weblate
• Update f-droid

[beatbrot]

Just saw the beta release. Thanks for actually shipping this wild request :) And thanks for all the years of support. I really love to use KitchenOwl :)