Backend vs. Frontend
As sites (excuse me, web apps) have gotten more complex, many backend-only ideas have found their way into the frontend. Early adopters of node.js found that “callback hell” is real on the server side as well. Modern client side frameworks like Angular and Ember take a backend idea — models from MVC — and use those to wrap and control the spaghetti that can result from too many callbacks.
Node.js is a great choice for performance on the backend. (It’s a fine choice on the frontend, too …if you call that a choice.) The reason it’s great isn’t because V8 beats C on benchmarks (it doesn’t) or because it has more efficient data structures than Java (it doesn’t). It’s great because it aligns with the way web apps are fundamentally bottlenecked. The main problem is always getting data from the backend and getting it to the user in a recognizable way.
What we want to build vs. what we actually built
Converting to Service-Oriented Architectures
Most existing applications aren’t adopting node.js to entirely re-write their systems. Most of the time, an existing piece needs to be scaled up, or the communication patterns between existing systems have become so complicated that it makes sense to wedge a service in between them to mediate communication. Frequently, the frontend is already doing this aggregation, and there are either performance, network resource, or redundancy reasons to do that work in the backend first.