CODEWITHSUNDEEP
node.jsexpress
Ross
Ross

Reputation: 14425

Connecting between multiple node.js apps

I would like to know how best to connect multiple node.js apps which all run as http servers.

For example: I have an express node.js app called MasterApp. This should handle authentication, user accounts, landing page, etc. But I also wish to have other apps which do specific area of the website like, say, a Wiki and a chat room.

So effectively my set could look something like below:

          Web
           ^
           |
        MasterApp
         ^     ^
         |     |
ServiceApp1   ServiceApp2...

One possible solution would be to turn the smaller apps into modules and include them in the MasterApp – but I have reasons not to do this. One being I want to maintain uptime on the MasterApp while ServiceApp1 and ServiceApp2 in experimental and/or in development.

Another solution, which seems sensible, would be to create a proxy in MasterApp with node-http-proxy which forwards requests after an authentication layer to ServiceApp1, ServiceApp2... Is this an advisable solution? Or is it ill-advised?

Or it there another solution, something that I am missing. Or, am I on the right track to use a proxy but perhaps HAProxy should be used instead, keeping the proxy external to node (although I like the idea of being able to dynamically configure node-http-proxy).

Thanks

Upvotes: 0

Views: 650

Answers (2)

errordeveloper
errordeveloper

Reputation: 6910

You should try to design it with message-passing instead, for example ZeroMQ can be used to facilitate a highly scalable architecture.

Upvotes: 0

Dobes Vandermeer
Dobes Vandermeer

Reputation: 8820

Assuming your application using AJAX on the client-side to access your server, it'll be easiest to run some kind of proxy. You could set it up so that you use node-http-proxy initially and later put an nginx proxy in front if you find that node-http-proxy is too slow.

Running the other modules in-memory would of course run the fastest but as you pointed out it does mean the master process would be affected by bugs in the other one.

What you are talking about is similar to Service Oriented Architecture which is becoming popular due to its modularity from the operations perspective. By breaking the application up into separate services which each have their own database, HTTP server, and so on you can upgrade, scale, manage, and monitor the components independently which can be advantageous. It does come at a cost in performance (especially latency) and uses more resources but has a kind of robustness to it. Read more: http://en.wikipedia.org/wiki/Service-oriented_architecture

With a service-oriented arhitecture you do have to figure out how to handle some central issues like authorization and authentication. Sometimes you'd have a proxy in front of all the services that acts as a gatekeeper and validates user credentials before passing requests to the appropriate service, or the services themselves can validate the credentials by passing them along to another backend service or using a shared piece of code (usually something involving HMAC).

Upvotes: 2

Related Questions