Integrating the new Web Apps in the Monorepo

To work around the issue of having to deal with CORS and similar evils, I’m thinking about integrating the new web apps with the operaton/operaton mono repo.

This should also lead to the “it just works” experience in a minimal setup where a user only has one “operaton” to deploy to have all features enabled.

Additionally, this should lead to easier testing between front- and back-end.

Is there consent to stay with this mono-repo approach and include the new web apps similar to the old?

(There still will be a standalone version which can deployed independently, as well as a toggle to turn off the web apps)

I’m undecided here. The mono-repo eases the integration of course, but tightens frontend builds with the regular builds, slowing them down again. The lifecycle of the frontend is also different from the backend, the frontend should be tied to the REST API only, which does not change frequently. Let us hear some more thoughts.

I’m slightly leaning towards keeping the monorepo. Several of our components depend on the web apps, which in turn depend on components in the repo (although these are soft dependencies). I cannot really imagine what the workflow would look like if we had to make feature changes to both the web apps and the backend. If they were in two repositories, we would have to run parts of the ‘backend’ tests, build artefacts of all the required components, run the front-end tests, package the front-end, and then run the end-to-end (E2E) tests with Wildfly, Tomcat, Quarkus and Spring Boot to test everything together. While these build steps could be automated in GitHub Actions with some context switches, testing on a local machine would require a substantial guide for developers and, in my opinion, raise the entry threshold.

Packaging the distributions would also be more complicated. If we want to continue delivering everything as one Docker container with only one running process, we would need to embed the front end in our Java distributions anyway.

I understand the concerns about build time, but there are already flags in place to skip the front-end build. If we continue to make proper use of Maven profiles, I don’t foresee a significant impact.

I’m leaning toward keeping the monorepo, but separating things with Maven profiles and different CI builds so the frontend doesn’t slow everything down. Path filters in CI would help too (does anyone know if that’s doable with GitHub Actions?).

If we split repos, we’d need strict API contract management between FE and BE, otherwise drift will be a constant problem. Overall, I think the monorepo + better separation would keep development simpler.

Thank you @javahippie and @ungerts for your feedback. So let us go with the mono-repo.
@paul Please go ahead after release of 1.0.0-beta-5.

1 Like

All right, will do :+1:t3: