-
Notifications
You must be signed in to change notification settings - Fork 6
Description
This is an old topic:
https://groups.google.com/d/msg/openruko/kSJxjqeawhc/lGJ926XiuyoJ
We have started it :
https://github.com/Filirom1/apiserver/commits/hipache
https://github.com/Filirom1/hipache/commits/openruko
And I dont' know if it's a good idea.
httprouting and Hipache use node-http-proxy opensourced by the PaaS company : nodejitsu.
Hipache depends on Redis, which is a great tool with a small footprint. But it's one more component to install. Heroku/Logplex too depends on Redis: openruko/logplex#4
If a compare Hipache with httprouting :
- Load-balancing across multiple backends : OK with httprouting
- dead-backend-detection but now it's easy with node-http-proxy to react on a bad dyno response : http-party/node-http-proxy@3b86a7a. And this job is done by rukorun and the heartbeat
- Multi-process architecture : done in 5min with cluster-master
- Memory monitoring : ouch this a nodejs problem or a node-http-proxy problem. BTW cluster-master could restart node gracefully periodically. That solve the problem
- Dynamic configuration : configuration is read in PostgreSQL instead of Redis
- WebSocket : done
- SSL : slow in nodejs SSL termination #9
- Custom HTML error pages : interesting but would it works in the Heroku way : Custom HTML error pages #11
- Wildcard domains support : Good : Custom domains #10
And I would like to add performance #8
Moreover there is a lot of features to be implemented to become a true clone of Heroku, that are not in Hipache. I fear that it will be harder to implement in Hipache than in httprouting.