Why Javascript on the Server Matters
by February 10, 2015

Filed under: Application Performance Management, Industry Insights

AppNeta no longer blogs on DevOps topics like this one.

Feel free to enjoy it, and check out what we can do for monitoring end user experience of the apps you use to drive your business at www.appneta.com.

It’s almost passé to write about the advantages of node.js, especially if you’re touting the benefits of event loops for web services the performance differences between V8 and other interpreters like Ruby. Node can handle tons of connections without breaking a sweat. Event loops are great for shuttling data between a DB and a frontend. V8 is fast, and you get to write Javascript.

Writing Javascript is more important than it may initially seem. Because of the different requirements of the frontend and the backend, different languages have been the norm for a long time. These differences, however, only force the teams who maintain them further apart. Standardizing on Javascript helps more teams focus on the same thing: creating stellar applications that deliver phenomenal user experiences.

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.

Just frameworks continue to swap ideas, each web app has specific requirements that the whole team ends up solving for their particular domain. Some of these are simple, such as how to format numbers or dates. Some are more complex: here at AppNeta, we have defined rules about how many points a timeseries graph should contain. By standardizing on Javascript, you can simply share libraries that implement these rules, eliminating bugs that come from partial updates to business rules. As frameworks continue to evolve, this will get ever easier, allowing even things like auth to be shared (like Meteor does).

Performance Matters

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

Because Javascript has this long history of request-callback-present, node.js is already mature for its age in doing what it needs to do: get data from a data store, organize it, and push it closer to the user. On TraceView’s host monitoring pages, our backend has endpoints that aggregate host metrics by host. The frontend looks at the users screen, and loads the data for endpoints that are actually visible (a necessary optimization for accounts that may have 1000s of hosts). By thinking about which level of aggregation each layer in the system provides, the web stack becomes much simpler to manage. Writing everything in Javascript removes yet another point of friction to thinking in full-stack terms, which ultimately makes life better for users.

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.

In particular, API access ends up being a 2nd class citizen in many products. Fundamentally, if the backend is built to serve a desktop UI, most of the aggregation logic will live in the frontend code, leaving the API team to re-write that code. Moving that aggregation back into a backend service lets the API team use the same services as the desktop team. Creating this sort of “backend frontend” — a near-the-edge service that various UIs can interact with, written in Javascript — takes advantage of the same sort of patterns originally written for frontend clients.

Converting to Services?

Make sure you know how to avoid these 6 pitfalls of microservices Download article