What is the complexity and effort of making an application worker mode compatible? (Example: Nextcloud)

[SimJoSt]

A little background about me. I've been called a digital fireman or problem solver, dealing mostly with obscure issues that others don't want to solve. Mostly playing in the web hosting and development space, with some networking and Wi-Fi tech on the side.
Part of a non-profit hosting open-source software for people and groups that cannot do it themselves, supporting other non-profits this way.

My skills are advanced (+ motivation), but not high-level expert, and mostly around hosting, not actual development. So I don't write code from scratch but modify it to fix a bug from time to time.

With the intro out of the way, my question is as follows:

What is the complexity and effort of making an application worker mode compatible?

Meaning, are the examples of how to create a worker.php in the docs a typical use case of a real-world application or more reflective of a simple one?
My example would be Nextcloud, the open-source and self-hostable Google Suite alternative. Its code base is fairly large and has a long history of growth and change.

In nextcloud/server#16726 (comment) (direct link to my FrankenPHP comment), there was a discussion about switching to go for parts of the applications, which has been done for a notification service with Rust. While there is no plan to switch away from PHP fully, more modularity is being adapted to allow "apps" to be written in other languages.
In nextcloud/server#36290 (comment) (direct link to my FrankenPHP comment), there is a discussion around improving performance with RoadRunner. With the previous suggestion of using more Go, FrankenPHP bringing more benefits than just performance, and it being officially supported by the PHP foundation, I suggested it as an alternative.

Currently, I cannot gauge how much work it would be to adapt the code base for the worker mode.
Is it as easy as creating an additional file? Would other parts of the code base need to be changed? Does it depend?
Would it be possible to create the worker file as an outside dev, or would it require deep understanding of the code base itself, with all its possible weirdness?

Based on the answers, I am considering trying my own hand at it, finding some volunteers, or paying somebody to invest the time, so there is no dependency on the Nextcloud maintainers time and prioritization.

[AlliBalliBaba]

The example in the docs is actually how you would wrap an application (here is the Symfony runtime as an example.

How complex it is to make an existing application worker-compatible always depends on the application itself though. The more global and static variables an application relies on, the harder it is to make it worker mode compatible.

If you look at Symfony Runtime as an example, it ends up being a relatively small wrapper around the framework, since the runtime already decouples Symfony from any global state and Symfony generally relies on a lot of DI. Other worker implementations like the one for Laravel go through a lot of effort to reset global state, since Laravel relies on a lot of singletons, facades etc.

I would say to make an application worker mode compatible (especially an old one) you probably need to have quite a bit understanding of how that application handles state. Especially how it handles global state. An application that relies on a lot of 'good practice' (like DI) would probably be easier to integrate with a peristent model (like worker mode) or an async model.

I'm not familiar with the Nexcloud codebase, so it's hard to say how much work it would be (does it only have 1 entrypoint?).

[SimJoSt]

Thank you for the extensive answer. That matches with the feedback I got from @withinboredom during a chat in the Discord: #1634
This gives me a better understanding of what approach a push for worker mode support would mean. Not something myself or a random hired PHP developer can do easily, but better somebody already working on the code base.

The question about a single entry point is new to me and makes a lot of sense.
There are a few requests that are routed to a different PHP file, then all other requests. As far as I remember, it is only those two. But, they are equally important. One serves the web interface, the other one the syncing clients.

My hope is, that the open issue nextcloud/server#36290 to work on RoadRunner support will make the important changes, to also allow for FrankenPHP's worker mode to work on it.