Most of my enterprise experience is bound to the Microsoft stack (.Net, SharePoint 2007 & 2010, SQL Server, IIS, Windows 2003, 2008, 2008 R2, the list goes on and on)
Pretty much of this change ever since i took my part time degree and i was brought back to hardcore software development, design and documentation. C++, C, php, rdms, 3NF, data structures & abstraction, algorithms, big O notation, etc.
I sat down and gave it a thought, the very existence of IT in most businesses are mostly for complimenting a business. We can leave Facebook, twitter, google and yahoo out of the picture, as they had caught on a market niche while their respective industry are in their infancy.
In the last project that i was involved in, i've opened up my mindset, i told myself, not to listen to microsoft all the time. I said no to ajaxcontrol toolkit, i said no to grid view binding to datasets. This time i wan to go hardcore and be able to know exactly what i am doing and how is it being done.
Enter: jQuery. There is no need for me to introduce this excellent javascript framework, but what it did for me was more than being a javascript framework. It allow me to be exposed to the open source communities on IRC, mailing lists and several forums. Underscore.js, less.js and Zurb foundation soon found their way into my IDE.
Soon enough, i've heard and tried a few node.js one page applications. The concept was clear and easy. The one language that most, if not all web developers are familiar with: Javascript. Using it for your user interface, server application and even database, one language to rule them all.
Author Ryan Dahl initially insisted that node be a 1 process thingy, lately, i believed due to many feedback and Joyent's direction, now they provide process forking.
My main roadblock for implementation in production is the stability, better debugging capabilities & easier fail-over. There are ways to implement fail over, but due to the fact that it is still under very rapid development, breaking API changes & deprecation caused a few sample apps that i created having problems.
I will look forward to v1.0 and implement it on our production servers.
Is there any particular reason you will want to use nodejs and what type of application you will want to write in node.
ReplyDeleteHaving a single language throughout the UI, App & db tier is a strong point. And it's performance thus is amazing.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThe first reason is valid. But performance wise, surely it cannot be faster than compiled languages.
ReplyDeleteWhile it may faster than other interpreted languages, but the productivity will be hampered by its reactor pattern (http://en.wikipedia.org/wiki/Reactor_pattern)
Asynchronous IO is also not exclusive to nodejs as we have tornado/twisted in python and eventmachine in ruby. If that is not enough, nginx is also a well known solution for the C10K problem. (Also noted that nginx and tornado/eventlet achieved this without using reactor pattern. It is implemented using coroutine. Meaning you do not need to code like javascript, add handler to every IO, to have the benefit of non-blocking IO)
Although I have to admit Asynchronous IO is a first class citizen in nodejs where every libraries are designed with NIO in mind.
Lastly, thread model had work well enough to prevent IO block (even if you have a single core CPU, you will benefit from multithreading). Erlang (threading model based on actor pattern) can spawn 10k processes cheaply. Spawning 20,000 processes only takes 9.2s on a machine with 2.40GHz Intel Celeron with 512MB ram running ubuntu. You did mention the need for failover, then you will find that failover is as easy in erlang, by setting up linked processes.
There is also an recent article by Ted dziuba on node http://teddziuba.com/2011/10/node-js-is-cancer.html, while he is a famous troll, there is truth in his article. It is not a dig at node.js, but reactor framework that does not know how to yield CPU, a CPU-bound progress will block out every incoming requests.
Besides, using nodejs to serve requests is taking for granted what web server middlewares like apache and nginx been doing for years, manage lifecycle, run as daemon, handle gzip, handle SSL, handle headers, handle static files. All PROVEN. Now try running nodejs as a service, you probably need using upstart or init.d, also it may not even stable enough for critical apps, you also need 3rd party nodejs library to handle gzip, ssl, static file etc. After adding them all, it doesn't seem so fast anymore.
I always maintain, use nodejs if you have a really STRONG REASON, or risk sacrificing in productivity, without getting much in return.
It's true that nodejs is not the only Event Loop modeled platform, but it takes time and money to train teams to pick up the language. Nodejs uses javascript which is like what i've mentioned in the first point, where having a common language is a good thing.
DeleteWhen i was talking about the performance, i wasn't really talking about how fast it can perform a set of instruction compared to other compiled languages. Since it runs in V8 vm, it would definitely be slower than C, etc. But what it intend to solve; writing high performance network application, yet using a familiar language. It really value adds to me. I do not have to spend time/money to hire specialized developers doing erlang or python, etc. If the project finishes, i can still "re-use" them for other projects or purposes.
Using nodejs to serve static content is actually a bad move, as LinkedIn engineering team had shared. They uses CDN for such.
With node, it requires a javascript-competent developer to easily write a specialized network application that scales easily above C10k. That's something worth investing in, the author of Node was initially very against the idea of spawning another process to make more use of multi-core CPUs. His intention i believe, is to have each nodejs process run specialized procedures, that way it's meant to be a interconnected cluster of specialists, which i think, is a sound way to scale to "google-scale". But that, i have yet to see or verify.
Anyway, you can check out nodejs github repo on the list of powered-by, it's pretty impressive.