3 ms·
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 nu
by beck5 14y ago
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.
- shykes 14y agoHipache 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. [1] http://github.com/nodejitsu/node-http-proxy http://github.com/nodejitsu/node-http-proxy
- beck5 14y agoThanks 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.