[sausheong]

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.

[seguer]

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?

[sausheong]

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.