Node.js on PayPal

I present to you a translation of the Node.js at PayPal article , where PayPal engineer, Jeff Harrell, talks about how PayPal chose tools for working with Node.js, compares Java development and Node.js using the same product as an example, and also talks about the future of Node.js at PayPal.

image

There was a lot of talk about the transition of PayPal to Node.js, as a development platform. As a continuation of part 1: “free my user interface” , I am happy to report that the rumors are true and our web applications are ported from Java to JavaScript and Node.js.

Historically, our development team has been divided into those who write code for the browser (using HTML, CSS and JavaScript) and those who write code for the application (using Java). Imagine the HTML developer who was supposed to ask the Java developer to connect the two pages “A” and “B”. That's where we were. This system prevented the implementation of full-stack specialists who are able to create an incredible user interface and build an application based on it. Call them unicorns, but this is what we need and the main stumbling block in PayPal has always been the border that we drawn between the browser and the server.

Node.js helped us solve this problem by letting us write the browser and server parts of the application in JavaScript. This unites our specialists in one team which allows us to understand and respond to the needs of users at any level of our technologies.

Preselection


Like many others, we pushed Node.js as a prototype platform. Together with all the qualities, high professional suitability was confirmed, so we decided to give it a go on production.

In our first attempts, express was used for routing, nconf for configuration, and grunt for building tasks. We especially liked the ubiquity of express, but we found it not scalable enough for a large development team. Express does not impose anything and allows you to install the server as you see fit. This is great for flexibility, but bad for consistency in large teams. Over time, we saw a pattern that emerged, how many teams chose Node.js and wrapped it in kraken.js; By itself, this is not a framework, but a layer on top of express, which allows you to scale it for large organizations. We wanted our engineers to focus on creating their applications, and not just on setting up their environment. We have been using kraken.js for many months (we will open its source code soon!),

Porting Node.js to Production


Our first implementation of Node.js on production was not a minor application; It was an account viewing page, one of the most viewed pages on our website. We decided to walk broadly, but we reduced the risks by building the same Java application in parallel. We knew how to deploy and scale Java applications, so if something went wrong with the application on Node.js, we could go back to it in Java. This provided the basis for very interesting data.

Development


We started in January, and it took us several months to create the necessary infrastructure for Node.js to work in PayPal, for example, sessions, centralized logging, key stores. During this time, we had five developers working on a Java application. After two months of development in Java, two developers began to work in parallel on a Node.js application. In early June, their roads crossed, the application had the same set of functions; in the Node.js application, the smaller team, which started with a two-month delay, quickly caught up. A few details that we learned after running tests on applications where the same functionality was tested. Node.js application was:

  • Built in twice faster with fewer people
  • 33% fewer lines of code written
  • The resulting application had 40% fewer files

Performance


Performance is a fun and debatable topic. For our part, we had two applications with the same functionality and built with approximately the same commands: one on our own Java framework, which is based on Spring and the other on kraken.js, using express, dust.js and other open source code. The application consisted of three routes and each route made 2-5 API requests, managed data and rendered pages using Dust .

We launched our testing utility using hardware from a production machine that tested routes and collected data on performance and response time.

image

You can see that the Node.js application has:

  • Two more requests per second compared to a Java application . This is even more interesting because one core for Node.js was used to get our internal performance results compared to five core for Java. We expect a further increase in this difference.
  • 35% reduction in average response time for the same page. This led to pages being served 200 milliseconds faster - which users will definitely notice.

A disclaimer is attached to this data: this applies to our frameworks and our two applications. This is a face-to-face comparison, a performance test that we can get by comparing two technologies, your results may vary. Nevertheless, we are pleased to see the performance of Node.js in its purest form.

Future


All our consumer-oriented web applications will be built on Node.js. Some, like our developer portal, are already working, while others, such as viewing an account, are in beta. Already more than a dozen applications are undergoing migration, and we will continue to share data as applications become available. This is an exciting time to be an engineer at PayPal!

Also popular now: