by Paul Serby
My responsibility is to define and lead the technical direction of the company. Excessive change is as dangerous as stagnation. Choices require careful due diligence to ensure they fit our development requirements and the business needs of our customers. I was confident that everyone using the same language was going to give substantial productivity gain as well as a distinction in the market; I just had to sell the vision into my teams. They are all smart people, and I don't expect them to do what I say without questioning it. I wanted to make them part of the decision, giving them a chance to feedback, gaining their insight, gauging their enthusiasm and allowing them to point out potential blockers I'd not considered. There were some valid concerns, but they bought into it with passion and could all see how big this could be for us.
Our PHP stack had served us well. It could be horizontally scaled, but the number of Apache instances required to scale to a modest number of concurrent requests felt excessive. I/O in PHP blocks until the request completes, all the while consuming memory and load until the I/O operation returns. This limitation made it costly and more complicated for clients who wanted high peak traffic, such as that caused by TV and newspaper advertising. We believed there was a more elegant solution.
In late 2009 Ryan Dahl demoed Chrome's JS engine V8 wired-up to an event loop. He claimed it could handle vast concurrent I/O on a single process, precisely the problem we were trying to solve. After hearing this, building a Node.js web server and conducting benchmarks and load tests became the next milestone.
After building a simple web service for a small client in pure Node.js and MongoDB we were hooked. We took the plunge and agreed to build an upcoming Sun Perks project, a customer loyalty project for The Sun, purely in Node.js.
We chose Mocha for testing, Express as a webserver and Jade and Stylus for HTML and CSS preprocessors. As the Product Owner, I took responsibility for features and overall software design. I also provided core elements, such as validation, caching, persistence, and application security. Software Engineering assisted and built out domain features and further core modules. Frontend established Jade and Stylus versions of our standard HTML and CSS and the build tooling. Configuration management, deployment, logging, load balancing and scale testing were the responsibility for Technical Services.
The three metrics we use as stability indicators: number of alerts, support tickets and incident reports, remained mostly static. One challenge we face even today with the long-running nature of Node.js is the appearance of memory leaks. They are rare and generally slow-growing, and while they are laborious and time-consuming to debug, good practices and awareness help prevent them. All in all, they are considered a fair trade-off for the many gains we made.
Once we fully adopted Node.js, opportunities arose to tell our story. Others wanted the assurance that Node.js was running in production. New marketing opportunities opened up. We sponsored and gave talks at LNUG, and I was asked to deliver a keynote at the Great British Node Conference; invited onto panels at NodeStack Conf in San Franciso and to be a guest on the NodeUp podcast. Our sponsorship of the NodeUp podcast brought us one of our largest accounts, Riot Games, when they were looking for "UK's leading Node.js developers" to build products for them.