HAProxy isn't designed to serve thousands of different virtual hosts. If you have a handful of different domains, that's fine, you can use some ACLs on the HTTP "Host:" header to differentiate them; if you have thousands of apps, and need an easy way to reconfigure dynamically, Hipache is more appropriate.
- Support for persistent (keep-alive) connections. A small detail which bit me when I deployed using Haproxy: it sets the X-Forwarded-For header only for the first request. Subsequent requests on the same connection will not include that header.
I'm a bit late on the discussion, but one advantage that I can see is that Hipache adds the HTTP_X_FORWARDED_FOR header, something that the Haproxy author refuses to do (perhaps for good reason, I'm not sure).
To quote the github page [1], Hipache is "a distributed proxy designed to route high volumes of http and websocket traffic to unusually large numbers of virtual hosts, in a highly dynamic topology where backends are added and removed several times per second. It is particularly well-suited for PaaS (platform-as-a-service) and other environments that are both business-critical and multi-tenant".
Before building Hipache, dotCloud's network routing layer consisted of a large number of boxes running nginx, wrapped in a custom instrumentation and management layer which, among other things, generated configuration files of mind-boggling size several times per minute and propagated them across a fairly complex distributed system. If we had used haproxy, we would have had to adapt that ad-hoc instrumentation layer to haproxy - not a particularly pleasant prospect. Since dotCloud had reached a scale which mandated a redesign of the routing layer anyway, we killed two birds with one stone.
load balancing websockets has been a pain of mine on sharelatex.com and I will have a good play with this.
However one thing that jumps out at me is the low number of tests. There only appear to be a few Acceptance tests. For a serious bit of software like a load balancer I would expect to see a fair few unit tests.
Hipache is built on top of node-http-proxy [1], a nodejs library which implements a lot of the actual websocket logic. Most of the tests you have in mind are in that library. Hipache implements a management and automation layer on top of it, and although more tests are always good, in my experience full-stack integration tests are more important in that context. I am not the author, but I work at dotCloud and can tell you that Hipache was submitted to massive amounts of integration testing and load testing before even touching its first production deployment. Obviously there's a long way to go before being as battle-tested as squid or nginx, but we're not talking about a week-end hack project either.
Thanks for answering. I would still personally prefer to see some unit tests checking each function behaves as expected, this is not so much to prove that the thing works now but make sure it can be changed safely over the next few years so I can pull down the latest version with confidence.
e.g. getBackendFromHostHeader inside worker.js does a lot of things, if I were the author I would have it wrapped up in unit tests.
