pgr0ss

Your syntax is definitely simpler. One reason we did it the way we did was to get compiler checking for operators. We've tried to follow idioms in different client libraries, and for the statically compiled languages, we've tried to make it so if it compiles, it will work.

Since the field comes first (orderId().startsWith()), if you try to call an operator on a field that does not support it, it will not compile.

Thanks for writing redis-node-client!

For pure proxies, there are definitely more appropriate tools. However, this gave me a chance to play with node.js. And I may develop it into a more full featured proxy.

I haven't seen the new continuations stuff in node. I will have to check it out.

BLPOP looks great. I will check it out.

I've thought a little about scaling to multiple frontends. I thought multiple response queues might be the easiest. Along with a request number, the node server could tell the backend which response queue to use.

I shell out to redis-cli purely for ease of development. I was already familiar with the cli, so I used it. I will definitely switch to a real redis library if I continue developing.

And finally, I used the term spike to mean a non-production quality programming exercise to prove out the solution at a high level. See http://c2.com/xp/SpikeSolution.html for more details.

You could still handle file uploads and other complex requests traditionally, and only use a queuing solution for the most important traffic. Then, at least part of the site would stay up during upgrades even if corners of the site went down.