Hi,
The documentation for the Job Workers states that a worker polls periodically for jobs from the broker. Why was this approach picked over a WebSocket approach? Is polling not, even if it supports long polling, much more resource intensive as a WebSocket connection where the broker can send jobs to registered clients.
That means If a large portion of workers call periodically for jobs, a lot of CPU, memory and network resources are wasted if the broker has no jobs to offer.
For me that sounds not really reactive in the sense of the reactive manifesto, which prefers a more non-blocking, message driven approach. Would it not make much more sense if a worker can register for jobs and if the broker has jobs to offer, that it pushes it to the worker. So the worker and the broker will waste no resources if nothing is to do.
I think one approach that will not really work with WebSockets is the gRPC client generation approach. I understand that it’s a huge benefit that for gRPC clients can be generated for every major language.
Maybe there are other aspects I haven’t considered yet?
Best regards,
Christian