Experience Working with NODE.JS FrameWork
It’s all about the Now.
A server side platform. An open source runtime environment. Used by LinkedIn, Yahoo! and PayPal. A platform that helped drop page load times and, according to PayPal development team, reportedly doubled the number of requests it handled per second. Today Node Js. is brought out to be one of the most useful application tools that provides “event driven architecture, optimizes an application capability and is able to handle thousand of concurrent connections with minimal overhead on a single process.” It’s a hot new commodity that we all want to get our hands on, or do we?
Introducing…
It’s really hard to find a professional in Node js… It’s so new that it’s limitations and security holes haven’t yet been discovered. However, HR departments already demand more experience than the platform has existed. So what’s the fuss about?
Unlike backend languages, Node js is all about non-blocking I/O operation that helps in ‘push technology’. It’s getting popular among developers to have 2-way connectivity i.e., both client and server can initiate communication and exchange data. The upside is to process multiple parallel requests (connections) on a single-thread by using non-blocking I/O calls. Node assigns separate threads for each connections using fewer resources and is able to switch between them with less delay. That makes it incredibly attractive for many ultra large websites. Node.js brings it best when the application is heavy data-driven (ajax based), especially if the app is a Single Page App with many requests per second that demands quick JSON responses. Such setup helps in processing on client-side; community loves it for developing Real time apps like Stock Exchange or Twitter-esque sites.
Same goes for the Java frameworks that are coming out for Node js. One of the cool things about Express, for instance, is it runs as the web server itself. It’s really different from Php and others as it loads your whole application in memory and then it sits as the server waiting for http request to come through and then responds to it. It never touches your file system, it just sits in your memory – which is why it s so blazingly fast.
The challenge
Whereas Node js is great for short quick demands on the server/chats… it’s not so great for the web apps that require a lot of memory from your computer. It’s not as efficient for anything that involves relational database and not a good fit for CPU intense apps like Language Translator etc. CPU intensive computations dramatically slow down Node js responsiveness.
And the flip side of it’s non blocking I/O operation: Node.js may not be used to fetch/deliver large sized files like video/combined assets.
EXAMPLE
Finally, end-end JS/HTML implementation in a single programming language is a sweet deal due to the ability to easily port logic across. It’s faster, lighter, more scalable. Which also means that very few UI developers lean towards learning Node js.
At this point “to learn or not to learn” is the matter of whether you’re a Java/C++ developer and whether your application is right for the Node js implementation (read: heavy data-driven and not memory greedy.) Or at least for HR department sake – until now becomes then.