Hipache (light) version without Redis?

[aionescu-zz]

Any plans to make a "lightweight" version of Hipache that wouldn't require Redis?
E.g. for cases where virtual hosting that doesn't change that much, so a simple config file without the overhead of Redis would be more than enough?

Thank you very much.

[emblicaorg]

Hi!
I think that could ruin the main idea of using hipache as proxy :D
Redis is very powerful and doesn't have much of overhead except space in disk.

Hipache is a fork from project https://github.com/nodejitsu/node-http-proxy if you want to have same kind of features but more lightweight that can be answer for your question.

If you mean that you don't want to restart server every time you make new configuration, hipache doesn't provide yet support for that without redis because redis is the core component of hipache. You can make same kind of features with Nodejitsus node-http-proxy with just little hacking.

I'm not developing hipache myself but I've been familiar with it because I'm working with it. Main developers should correct me if I'm wrong.

[aionescu-zz]

I think that could ruin the main idea of using hipache as proxy

Sorry but that makes no sense to me. Node apps need a proxy, one that can compete with the stuff it's trying to replace. The node-http-proxy doesn't seem to be usable out of the box to me, at least not a real alternative to a simple, lightweight and production reliable Apache HTTPD configured as proxy with vhosting (something that every admin can quickly maintain).

Redis is very powerful and doesn't have much of overhead except space in disk.

I don't want to argue about the merits of Redis, but as an extra "component" in the system,
it has an installation overhead (e.g. production environments where there's no available build - e.g. SPARC Solaris)
It will have upgrade and and maintenance overhead, as well as config and security overhead - things the admins will have to master in addition to the other stuff.

I simply can't replace Apache HTTPD sitting in front of some apps with something else, if that replacement is a much higher overhead for the rest of the team(except me) that will have to use and maintain it.

You can make same kind of features with Nodejitsus node-http-proxy with just little hacking.

Sorry but I can't afford to "hack" production systems, especially not infrastructure :).

Instead of upgrading existing running production web applications, I would like to rewrite some of them from scratch but based on Node (as a first step). For this, Node needs to play nice with the rest of the existing systems. As such, one of the problems so far seems to be the Apache HTTPD proxy, and so far comparing only the features, only Hipache seems to come close.

[emblicaorg]

I meant that hipache is proxy for really fast changing, dynamic environments and thats why there is redis as one of the components.

You didn't specify what are the features that you need for. If you need something like apache then I recommend nginx. If you need something that can be used in very dynamic environment then I recommend hipache, you lose that advantage of dynamic configuring if you use just plain-text configuration files.

[jpetazzo]

Hi @aionescu,

When developing Hipache, we had (at least) three goals:

• dynamic reconfiguration (i.e. add/remove virtual hosts and back-end servers without restarting or reloading the whole configuration),
• configuration (and reconfiguration) through a well-defined interface (hence the choice of Redis),
• support for WebSocket.

If you don't want WebSocket nor dynamic reconfiguration, you can use almost any other web server (including but not limited to Apache and Nginx). They have been around for muuuuch longer than Hipache, and run under virtually any kind of environment.

If you are looking for a WebSocket proxy, but don't need the dynamic reconfiguration, you could have a look at recent versions of Nginx (see http://nginx.com/news/nginx-websockets.html). That will work very well, and it should be supported on your platform, even if it is quite exotic.

Last but not least, if you really want Hipache for some reason, it means that you need a fairly recent version of Node.js as well. I'w willing to make a bold assumption: if your platform runs a recent version of Node.js, it probably also runs Redis!

Now, if you really-really-really want to run Hipache without Redis, you need to change lib/cache.js, and more specifically getBackendFromHostHeadeder (https://github.com/dotcloud/hipache/blob/440e33b2a31f56102d252909d7c92ad1a937a41a/lib/cache.js#L119).

I'm marking this ticket as closed, unless you have further questions, of course.

Best regards,

[aionescu-zz]

@jpetazzo and @emblica
Thank you all for your responses!

I'm looking to use WebSockets in one webapp that should replace an existing Java webapp in an existing infrastructure: Apache HTTPD as proxy in front of some Tomcat instances and some other legacy webapps.
If it turns out to work reliably than further webapps might be migrated to Node.

For some unknown reason, the ApacheHTTPD authors seem refuse to include any WebSockets extension. Extensions existing in the wild don't really seem to work correctly so far :(.

Nginx was evaluated, but refused by the admins because of the very bad performance of the Tomcat instances give with it :(.

To me Hipache seem like the only alternative because:

• for Node, it seem the only solution that could change config while running (Apache HTTPD can do this too with several modes without a Redis like solution)
• it wasn't an "extra component" but just a "node app" so much easier to get it in the "landscape" :) (well except the Redis part :) ).

Also hopefully Hipache works without problems with Tomcat, but I don't know that yet, hence my other question #19

Sad fact: Node webapps look nicer, easier and faster to develop, but the deployment in existing infrastructure seems like a PITA so far for me :(.

Thank you very much.