Node.js is a big win at PayPal

; Date: Tue Dec 17 2013

Tags: Node.js »»»» Enterprise Node »»»» Production use

In my book Node Web Development (see sidebar), I spent the first chapter trying to sell the reader on using JavaScript on the server.  That's because the typical server side languages do not include JavaScript, meaning everyone has to be scratching their head and wondering why they should use JS on the server.  I suggested that, theoretically, one big win will come because the front end coding and back end coding will both be in the same language, JavaScript, which will make it possible for front engineers to talk with server engineers in the same language.  Or perhaps even be the same person.

A blog post from PayPal validates that theory very well.

The author of that post says they, PayPal, is looking for "full-stack engineers" who can code both front- and back-end stuff.  He even described the boundary between browser and server code as "artificial."

They like Express, but found that it's too flexible and desired to have some conventions used in PayPal's applications.  They came up with a library to house those conventions.

To test whether Node.js would work at PayPal, they chose to take their "account overview page", one of the most trafficked pages on PayPal's service, and recode it in Node.  To hedge their bets they had a second team work on a Java implementation.

The Node team had a slow start because they had to build up some infrastructure for node.js to work in PayPal, e.g. sessions, centralized logging, keystores.  Even with a two month lag before they could start work on the actual application, they beat the Java team to the end goal.  Further the Node implementation had these gains:

• Built almosttwice as fast with fewer people
• 33% fewer lines of code
• Constructed with 40% fewer files

And performance was great:

• Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
• 35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.