Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features.
Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitioned into services, it's easy to write a single service in Go, and go is a nice language for writing services.
That being said, Node is particularly well suited for consuming services. You'll necessarily have lots of client code written to consume and use these services from your webapp. So whenever you write a batch job or notification system or anything else that is primarily server side consumption of services or glue between services, node.js is a natural fit.
The other natural advantage of Node is that your business logic can run on both the server and the client. Your standard client-side web app (angular, backbone, ember etc.) has the bulk of the business logic in the client-side models. On the server side, the corresponding models are mostly just shims to the database, but they will also contain some business logic. If your code is written in Node.js, you just instantiate the client side model to be access the business logic.
Your point on server-side business logic is spot on. I feel somewhat spoiled now after working on isomorphic JavaScript: any time I need to add rules to a legacy application that requires me to write the same code in two languages I get quite frustrated. DRY, what?
And to your list of isomorphic view frameworks I'd add React [0], which allows you to render server-side with almost no additional effort.
Hmmm, I couldn't find any simple examples. Basically, all it means that you're running Backbone.js on the server as well. If you're just using Backbone.js models & collections it's pretty straightforward.
But if you Google for running Backbone.js on the server, you get links for people running Backbone.js views (as well as models and collections) on the server. That's a little more involved, but the work has been done for you by frameworks such as rendr.
I'm only familiar with Backbone. If your models are written in Ember or Angular or (?) instead of Backbone, I can't help you but would be very interesting in knowing how myself...
Comments
Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features.
Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitioned into services, it's easy to write a single service in Go, and go is a nice language for writing services.
That being said, Node is particularly well suited for consuming services. You'll necessarily have lots of client code written to consume and use these services from your webapp. So whenever you write a batch job or notification system or anything else that is primarily server side consumption of services or glue between services, node.js is a natural fit.
The other natural advantage of Node is that your business logic can run on both the server and the client. Your standard client-side web app (angular, backbone, ember etc.) has the bulk of the business logic in the client-side models. On the server side, the corresponding models are mostly just shims to the database, but they will also contain some business logic. If your code is written in Node.js, you just instantiate the client side model to be access the business logic.
The other killer feature for node.js has already been mentioned: combining both server and client side rendering with https://github.com/rendrjs/rendr or https://github.com/wvl/highbrow.
Your point on server-side business logic is spot on. I feel somewhat spoiled now after working on isomorphic JavaScript: any time I need to add rules to a legacy application that requires me to write the same code in two languages I get quite frustrated. DRY, what?
And to your list of isomorphic view frameworks I'd add React [0], which allows you to render server-side with almost no additional effort.
[0]: https://facebook.github.com/react
slightly off-topic but I am pretty interested in learning about SOA architecture using Node.js apps. Can you refer any guides/links ?
Hmmm, I couldn't find any simple examples. Basically, all it means that you're running Backbone.js on the server as well. If you're just using Backbone.js models & collections it's pretty straightforward.
But if you Google for running Backbone.js on the server, you get links for people running Backbone.js views (as well as models and collections) on the server. That's a little more involved, but the work has been done for you by frameworks such as rendr.
A good starting place might be: https://github.com/rendrjs/rendr-examples
I'm only familiar with Backbone. If your models are written in Ember or Angular or (?) instead of Backbone, I can't help you but would be very interesting in knowing how myself...