The big pitch of Node.js (that i can see) is the use of eventing, like in browser based javascript.
This is quite a nice model, but isn't the be all and end all.
If your application is frequently blocking on IO (database, file, network), then an event based model could be very useful for you.
I've built a few apps like this over the years, in plain spring and in grails and they've performed quite nicely in that role.
I've quite happily had jetty running 50k concurrent long running connections with a minimal thread pool (20) and minimal resource use.
I've tended to use jetty 6 continuations, or servlet 3 continuations which work in a very similar way.
You can use Tomcats NIO for the same purpose, however I prefer the style of either the Jetty or Servlet 3 continuations.
To do this you do have to construct the eventing system, however its pretty easy to do, and you can tie it into spring integration or camel with quite a small amount of effort to give you configurable routing of your messages/ events.
In addition, you can only use tomcat NIO in grails development mode in grails 2 (see
http://jira.grails.org/browse/GRAILS-7018)
Lastly there's Atmosphere. (
http://www.grails.org/plugin/atmosphere) This seems quite feature complete and seems to work well enough, but I haven't put a huge amount of time into it, so I can't recommend it.
So, in summary, yes you can build an event based system if you want to in grails/ spring and it will perform very very well.
Personally I don't recommend using websockets just yet. The spec is still incomplete and has plenty of bugs to be shaken out. Most desktop browsers currently have it disabled for now due to security concerns.
That said, if you use atmosphere, your server code won't have to change if you so want to use it.
Now, I realise that I've blended event and message based systems together here, but with a Grails app you aren't constrained to staying with the request model, or messaging, or being forced to have everything use events.
You could build any of them, all even, without too much trouble. Have an event based API for your heavy/ long lived load with a messaging back end to pass work off to a bigger back end server but with a normal controller for serving the homepage. Whatever takes your fancy.. ;-)
David.
Locked
