Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm planning to setup an scalable architecture capable of providing web services on a REST interface where JSON will be sent as a result. The web services will be quite simple for a CRUD web 2.0 app.

Architecture

I think javascript (nodejs + mongodb) is a good choice for the following reasons:

  • Easy to find javascript developers
  • Good performance
  • Easy to scale
  • Shared logic/language or possible reuse of code between database query language, back-end and web-client.
  • There are testing and logging frameworks for node
  • By the examples I've seen node seems light in terms of the lines of code needed to implement web services.

Questions:

  1. I think of scaling a node app which supplies a web service as having a central node which will be routing/balancing charge to each of the node instances. Which will also help doing seamless updates, is there any piece of software already implemented which can fit that task?
  2. Please point all the disadavantages or other advantages you find in this back-end stack
  3. Any other good persistence choices other than MongoDB? Mainly this choice comes from the javascript query language and JSON schemas.
share|improve this question
2  
Flame me if you like, but I can't help but feel confounded about this NodeJS craze. Besides the ability to pass JSON objects directly from client to server without translation (some may think this a bad thing as translation is your best validation) then I only see bad with it. You might as well commit to writing your server side code in Lisp. –  maple_shaft Feb 10 '12 at 18:32
1  
@maple_shaft: what's wrong with LISP? Paul Graham makes a pretty for server-side LISP: paulgraham.com/avg.html –  kevin cline Feb 10 '12 at 18:56
    
I would love to do a full LISP implementation, but I'm in a hurry, I would need to vastly improve my LISP skills first. –  eliocs Feb 10 '12 at 19:03
1  
@maple_shaft node.js is awesome because of the open source community, not the technology itself. Also hook us up with the bad things you see and we'll convert you –  Raynos Feb 10 '12 at 19:14
1  
@maple_shaft Web services in Node.JS are fast, easy, and have a very small footprint. One silly example: Apache allocates 8MB for a new connection, Node allocates 8kb. I've got live production services in the wild using Node, and love working in it. Currently developing a full-stack e-commerce site in Node, and it's coming together beautifully. –  Fosco Feb 10 '12 at 23:17
show 2 more comments

3 Answers

up vote 3 down vote accepted

Easy to find javascript developers

It's plenty easy to find mediocre JS developers. The good ones are rare. Especially a full stack front-end/node combo.

Shared logic/language or possible reuse of code between database query language, back-end and web-client.

Certainly possible but don't overvalue this too much. You need some rock solid infrastructure to make this happen.

There are testing and logging frameworks for node

There are testing and logging frameworks for everything. Even C.

However node does

  • Have solid performance
  • Easy scalability
  • make it easy to write web services

One recommendation I would give is you swap out that "Router" with a decent elastic load balancer

I think of scaling a node app which supplies a web service as having a central node which will be routing/balancing charge to each of the node instances. Which will also help doing seamless updates, is there any piece of software already implemented which can fit that task?

It's called an ELB. Do not re-invent that wheel (and if you do make it open source o/)

Please point all the disadavantages or other advantages you find in this back-end stack

This would involve knowing specific application requirements and features. It's a sensible structure, it's a sensible stack.

Any other good persistence choices other than MongoDB? Mainly this choice comes from the javascript query language and JSON schemas.

There are a whole bunch of noSQL solutions. Go explain your exact application to a noSQL expert and get his opinion. Offer him coffee.

Other then that the only main thing you forgot is in memory cache (Redis) attached to every node instance.

The other main thing you forgot is how to actually architecture the application inside the nodejs box. Overall your system level architecture seems decent. I'd totally recommend nCore for your node.js application infrastructure.

share|improve this answer
    
Raynos good answer overall, but please keep the tone & language professional at all times. –  Yannis Rizos Feb 10 '12 at 18:47
1  
The good/mediocre developer ratio will be pretty low for every popular language. It's only higher for communities that contain mostly early adopters. –  kevin cline Feb 10 '12 at 18:59
1  
@kevincline My personal opinion of the JavaScript/Node market (I'm knee deep in it) is that relatively compared to Rails/PHP/.NET/Java etc it's hard to find the good guys. The main illustration point was that there are lots of JavaScript developers and the good/mediocre ratio in the JS world is horrible. It's worse then PHP. Were talking 99.9% mediocre/0.1% good –  Raynos Feb 10 '12 at 19:12
1  
@kevincline Agreed, and also while developers are harder to find and more expensive for less popular languages, you would probably need to pay more for good developers in popular languages too. –  maple_shaft Feb 10 '12 at 19:12
1  
@Raynos: JavaScript is pretty powerful stuff, and magnifies the differences between the best and the rest. Less expressive languages do the opposite. –  kevin cline Feb 10 '12 at 20:13
show 3 more comments
  1. scalable
  2. REST
  3. CRUD
  4. web 2.0
  5. nodejs
  6. mongodb

A lot of hot keywords that don't really mean much. You could have simply said "I'm planning on building a webservice."

I personally don't have a problem with using JS - it's a good language, but I don't think 'finding developers' is a good reason to choose the language - good programmers can code in any language.

I recommend you check out couchDB. It's a single piece of software that, here, can serve the role of both node and mongo. It will scale better individually than Node and mongo scale together, and it's relatively easy to use if you can write a map/reduce function.

BUT, it sounds to me like you're putting the cart before the horse. You don't need to worry about scalability until scalability becomes a problem, and scalability is a good problem to have. I would recommend you write everything in the language that you know best and can produce the fastest in, and worry about scaling when you need to scale.

share|improve this answer
    
"You don't need to worry about scalability until scalability becomes a problem". Avoid premature optimization. –  S.Lott Feb 10 '12 at 22:56
    
Yeah I agree, worrying too much for scalability at the start will only slow my development, my initial structure will much simpler but I just wanted to know, what if scalability comes an issue. I have definitely learned a lot from all the answers, I feel safe giving node a chance :). –  eliocs Feb 11 '12 at 9:40
add comment

33 & 1/3rding that you should not worry about scale until you need to worry about scale. Personally I would not bet my farm on node at this point unless I had some capable C hackers available to fix it -- it is just too young to ride and not be able to rebuild the engine if you needed to IMHO. I'd also be leery of mongodb -- it is fast, but at a pretty bad cost in terms of data integrity. CouchDb is probably a better choice if you want to stay on *nix. RavenDb is compelling if that isn't a requirement. Either of those options could probably run the whole app without node.

In any case, the mantra to repeat isn't webscale, it is Minimum Viable Product.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.