monolithic node app VS multiple node instances and/or proxying

[Jason Grima]

I'm fairly new to node, but quite experienced at development (PHP, Java, C, asp, .Net, VB - I've been round the block a few times).

I'm in the early stages of planning the redevelopment of a web-app servicing several thousand active users per day and currently NodeJS is looking to be a good platform choice. 

The existing application is written in PHP and whilst it's serviceable, it has a mess of output code and business logic mashed together, and is build in a poorly implemented MVC style. We've been looking to redevelop it for some time, with an objective of improving throughput, and separating the business logic from the templates to make the application more modular and enable the development of a some companion mobile apps. 

So to my question: What approach is Node better suited to? 

• a single monolithic runtime
  
• multiple instances on a single machine - I've seen the new "Cluster" module, which certainly looks interesting, but is listed as experimental... 
• multiple instances on multiple machines with proxying/vhosting
• some other configuration

I've seen some examples of load balancing between processes on a single server, load balancing between servers, using a primary node instance as a routing controller, using a single node instance for everything, multiple http servers in a single js app, and it all seems pretty straight forward, but I'm not sure of the pros/cons of the different approaches, so I'm after recommendations and best practices (if there are any) rather than just blundering forward.

I know risky to ask an open ended opinion-based question of developers, but I'm looking for a start point from any developers who've actually done medium-scale applications with NodeJS.

Thanks.

[Aria Stewart]

> On 30 Sep 2014, at 21:05, Jason Grima <blakj...@gmail.com> wrote:

> So to my question: What approach is Node better suited to?
> • a single monolithic runtime
> • multiple instances on a single machine - I've seen the new "Cluster" module, which certainly looks interesting, but is listed as experimental...
> • multiple instances on multiple machines with proxying/vhosting
> • some other configuration

Yes, it is better suited to these! ;-)

It's actually good for all of those.

> I've seen some examples of load balancing between processes on a single server, load balancing between servers, using a primary node instance as a routing controller, using a single node instance for everything, multiple http servers in a single js app, and it all seems pretty straight forward, but I'm not sure of the pros/cons of the different approaches, so I'm after recommendations and best practices (if there are any) rather than just blundering forward.

Multiple http servers in a single app is an unusual and purpose-specific configuration.

You cluster -- whether with cluster or another load balancer -- when you need to scale past a single process. Cluster's got some changes coming in 0.12, but the API should be stable. A load balancer in another process is probably better for now. If you actually need to scale past a single process.

Multiple machines, of course, let you scale past a single box's limits, and can let you start working on redundancy.

All of the clustering options mean you have to manage state synchronization if your requests aren't stateless, like any app. This will be natural to you coming from PHP, where each request throws away its data at the end, and you synchronize with a database, cache or session store.

Aria