PayPal Node.js
I present to you the translation of the article Node.js at PayPal , where PayPal’s engineer, Jeff Harrell, talks about how PayPal chose tools for working with Node.js, compares the development in Java and Node.js using the same product as an example It also talks about the future of Node.js in PayPal.
There was a lot of talk about switching 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 being transferred from Java to JavaScript and Node.js.
Historically, our development team was 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 a HTML developer who should have asked a Java developer to connect two pages “A” and “B”. That's where we were. This system prevented the introduction of full-stack professionals 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 sticking point in PayPal has always been the border that we used between the browser and the server.
')
Node.js helped us solve this problem by allowing us to write the browser and server side of the application in JavaScript. This unites our specialists into one team that allows us to understand and respond to user needs at any level of our technology.
Like many others, we pushed Node.js like a prototype platform. Together with all the qualities, high professional ability was confirmed, so we decided to give it a turn in production.
In our first attempts, we used express for routing, nconf for configuration, and grunt for building tasks. We especially liked the omnipresence 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 occurred, how many teams chose Node.js and wrapped it in kraken.js; By itself, this is not a framework, but an interlayer on top of express, which allows it to be scaled for large organizations. We wanted our engineers to focus on building their applications, not just on setting up their environment. We have been using kraken.js for many months (we will soon open its source code!), And our developers are looking forward to implementing Node.js applications that we have built.
Our first implementation of Node.js for production was not a minor application; This was the account viewing page, one of the most viewed pages on our site. We decided to go wide, but we reduced the risks by building the same Java application in parallel. We knew how to deploy and scale a Java application, 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.
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, keystores. 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 the Node.js application. In early June, their roads crossed, the app had the same set of functions; in the Node.js application, a smaller team that started with a two-month delay quickly caught up. Several details that we learned after running tests on applications where the same functionality was tested. Node.js app was:
Productivity 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 another open source. The application consisted of three routes and each route did 2-5 API requests, managed data and rendered pages using Dust .
We launched our testing utility using hardware from a production driver that tested the routes and collected performance and response time data.
You can see that the Node.js application has:
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 differ. Nevertheless, we are glad that we saw the pure Node.js performance.
All our consumer-oriented web applications will be built on Node.js. Some, like our developer portal, are already working, while others, such as account viewing, are in beta. Already more than a dozen applications are in the transfer stage and we will continue to share data as applications are released. This is an exciting time to be an engineer at PayPal!
There was a lot of talk about switching 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 being transferred from Java to JavaScript and Node.js.
Historically, our development team was 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 a HTML developer who should have asked a Java developer to connect two pages “A” and “B”. That's where we were. This system prevented the introduction of full-stack professionals 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 sticking point in PayPal has always been the border that we used between the browser and the server.
')
Node.js helped us solve this problem by allowing us to write the browser and server side of the application in JavaScript. This unites our specialists into one team that allows us to understand and respond to user needs at any level of our technology.
Preselection
Like many others, we pushed Node.js like a prototype platform. Together with all the qualities, high professional ability was confirmed, so we decided to give it a turn in production.
In our first attempts, we used express for routing, nconf for configuration, and grunt for building tasks. We especially liked the omnipresence 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 occurred, how many teams chose Node.js and wrapped it in kraken.js; By itself, this is not a framework, but an interlayer on top of express, which allows it to be scaled for large organizations. We wanted our engineers to focus on building their applications, not just on setting up their environment. We have been using kraken.js for many months (we will soon open its source code!), And our developers are looking forward to implementing Node.js applications that we have built.
Moving Node.js to Production
Our first implementation of Node.js for production was not a minor application; This was the account viewing page, one of the most viewed pages on our site. We decided to go wide, but we reduced the risks by building the same Java application in parallel. We knew how to deploy and scale a Java application, 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, keystores. 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 the Node.js application. In early June, their roads crossed, the app had the same set of functions; in the Node.js application, a smaller team that started with a two-month delay quickly caught up. Several details that we learned after running tests on applications where the same functionality was tested. Node.js app was:
- Built in twice faster with fewer people.
- Written 33% fewer lines of code
- The final application had 40% fewer files.
Performance
Productivity 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 another open source. The application consisted of three routes and each route did 2-5 API requests, managed data and rendered pages using Dust .
We launched our testing utility using hardware from a production driver that tested the routes and collected performance and response time data.
You can see that the Node.js application has:
- Twice more requests per second compared to a Java application . This is even more interesting because one Node.js core was used to get our internal performance results compared to the five cores for Java. We expect a further increase in this difference.
- 35% decrease in average response time for the same page. This led to pages being serviced 200 milliseconds faster — something users would 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 differ. Nevertheless, we are glad that we saw the pure Node.js performance.
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 account viewing, are in beta. Already more than a dozen applications are in the transfer stage and we will continue to share data as applications are released. This is an exciting time to be an engineer at PayPal!
Source: https://habr.com/ru/post/324912/
All Articles