Thanks for the suggestion, it's a good one. A few cases a message queue can be advantageous -- (1) persistence (2) a few responders can work on the same request in parallel (3) adding/removing responders dynamically according to the load.

These are not common/generic use cases but would be useful under particular circumstances.

* I could be wrong with (3) -- I'm not very experienced in reverse proxies.

You're correct on 3; I actually did this in a large system I wrote and worked on at my last job.

It wasn't quite dynamic (it required an engineer to set new values for how many workers you wanted..) but we could do this via a GUI.

For (1) what do you do with the persistence? A web request, in general, is not important after a few seconds.

For (2) how does Polyglot accept multiple responders for a single request, and how would it join the responses?

Thanks for the confirmation.

The implementation today is as a task queue which removes the request from the queue once a responder acknowledges, but it could be a pub-sub model, where a number of independent responders can work on the same message in parallel, and only 1 responder need to return a response. In this case, persisting in the queue is useful.

An alternative is to chain the responders where one responder can leave a message in the queue for another responder, and the final responder returns the response.

Polyglot is still experimental though, and the current implementation is a prototype.

The main problem with that, is that reverse proxying is push based, message queues are pull based.

What makes this a problem? The initial request to Polyglot is also "push".

The rest of the web works on "push" too; pull in this case would only help if you don't care that a request could take a long time (seconds) to resolve.

I didn't see mention of it, but what happens if a message is not responded to? How does Polyglot handle time outs?

That's not implemented yet I'm afraid, I haven't figured out a good mechanism to timeout the messages.