[seguer]

If the goal is the ability to have certain routes processable by different languages/systems you could achieve this with reverse proxying (from eg. nginx) [1].

That way you can leverage any existing language frameworks and run them as standard HTTP responders. No need to work with a queue (and add it to the stack).

You can still limit the HTTP methods each proxy responds to as well [2].

[1]: http://nginx.com/resources/admin-guide/reverse-proxy/

[2]: http://stackoverflow.com/questions/8591600/nginx-proxy-pass-...

[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?

[CMCDragonkai]

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

[seguer]

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?