According to Harrell, PayPal’s websites had accumulated a good deal of technical debt, and they wanted a “technology stack free of this which would enable greater product agility and innovation.” Initially, there was a significant divide between front-end engineers working in web technologies and back-end ones coding in Java. When a UX person wanted to sketch up some pages, they had to ask Java programmers to do some back-end wiring to make it work. This did not fit with their Lean UX development model:
At the time, our UI applications were based on Java and JSP using a proprietary solution that was rigid, tightly coupled and hard to move fast in. Our teams didn’t find it complimentary to our Lean UX development model and couldn’t move fast in it so they would build their prototypes in a scripting language, test them with users, and then later port the code over to our production stack.
They wanted a “templating [solution that] must be decoupled from the underlying server technology and allow us to evolve our UIs independent of the application language” and that would work with multiple environments. They decided to go with Dust.js – a templating framework backed up by LinkedIn – , plus Twitter’s Bootstrap and Bower, a package manager for the web. Additional pieces added later were LESS, RequireJS, Backbone.js, Grunt, and Mocha.
Some of PayPal’s pages have been redesigned but they still had some of the legacy stack:
At that time, they also started using Node.js for prototyping new pages, concluding that it was “extremely proficient” and decided to try it in production. For that they also built Kraken.js, a “convention layer” placed on top of Express which is a Node.js-based web framework. (PayPal has recently open sourced Kraken.js.) The first application to be done in Node.js was the account overview page, which is one of the most accessed PayPal pages, according to Harrell. But because they were afraid the app might not scale well, they decided to create an equivalent Java application to fall back to in case the Node.js one won’t work. Following are some conclusions regarding the development effort required for both apps:
|Set-up time||0||2 months|
|Development||~5 months||~3 months|
|Lines of code||unspecified||66% of unspecified|
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.
As a result, PayPal began using the Node.js application in beta in production, and have decided that “all of our consumer facing web applications going forward will be built on Node.js,” while some of the existing ones are being ported to Node.js.
As for "speed" when they use Node.js and plain Java, they are comparing apples and oranges. There are at least 3 Java async APIs.
There are multiple ways to code in Java for the client and still have it run as JS in the browser
That they were still using JSP is very telling.
Java or JEE problem?
Node.js is async and they probably used Spring in a sync way.
Simply combing UI engineer and JEE developer may not be a good idea
Again, you may not have a full view of the whole system's architecture.
Replacing JSP is good idea as it's not a good templating technology. But doing so doesn't mean that you're replacing Java, especially backend components.
The backend roles are definitely necessary as they're thinking different ways.
Improving the roll-out efficiency doesn't mean just to simplify the team as one or two roles that you like.
Hope you understand.
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014