Cloud // Software as a Service
News
3/17/2014
11:46 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

PayPal Finds Node.js Secret To Successful Makeover

As PayPal transforms itself for transactions over smartphones and other mobile devices, it's found Node.js to be an indispensable tool.

PayPal has been undergoing a makeover for about two years now, and the company's senior director of user interface design, Bill Scott, says Node.js has become one of the top tools in its transformation. Scott, a former head of Netflix e-commerce user interface design, says Node is a sign of the deeper changes underway at PayPal.

One of Scott's assignments at Netflix was designing an effective way for Sony PlayStation 3 owners to download movies. Instead of creating one user interface to test, his team came up with four and tested all of them with PlayStation users. He said in an interview with InformationWeek that the one that won was not the one the developers would have chosen. The story shows how he prefers to choose technologies that allow him to experiment and test different options quickly.

Scott described how PayPal has used Node.js, as well as his experience moving from Netflix to PayPal, last May at the O'Reilly Fluent Conference. He provided an update on how far PayPal has progressed with its Node.js makeover on Feb. 28 at Node Day, held at PayPal's headquarters in San Jose, Calif., where 400 Node.js programmers showed up from Groupon, Wal-mart, Netflix, LinkedIn, Adobe, and GoDaddy, among others.

He also moved his personal blog to Node.js late last year, and said in his personal blog, "In case you didn't know, I love NodeJS. It has helped us start a revolution at PayPal for our engineers, and soon our customers, as experiences will start rolling out faster."

[Want to learn more about PayPal's mobile modernization effort? See How PayPal Got Its Swagger Back.]

In early 2012, Scott was still getting acquainted with Node.js when David Marcus, former CEO of Zong, a startup acquired by PayPal, was named president of PayPal. Marcus immediately realigned priorities, telling current CTO James Barrese and other key developers, "Let's redo PayPal Checkout."

Bill Scott, PayPal

That was music to Scott's ears. In his eyes, Marcus changed PayPal's risk-averse and stodgy technology culture into one that would modernize and revise applications fast. The PayPal Checkout function was the bane of merchants because it took shoppers off their e-commerce site and onto PayPal's to complete a transaction. Merchants wanted visitors-turned-buyers to stay on their sites, where they'd have another chance to interact with them after that transaction.

PayPal collects $3.5 billion in revenue through interactions with customers set by the user-interface front end. Scott was brought in to re-engineer the user interface that controlled those interactions.

When he arrived at PayPal in 2011, Scott told InformationWeek, he found the company had built its foundation code in C++ and Java. It used the Spring Framework, a way of lightening up Enterprise Java's complexities, but that wasn't enough for Scott. "It was a very unfriendly environment for front-end engineers," Scott told the Fluent Conference in May. Startups were developing almost exclusively in Ruby, PHP, and Node.js, and he wanted to do more of the things they were doing.

He's a big fan of Node.js because it runs fast on the server and works smoothly with JavaScript actions in web browsers. It was designed to function at scale with many concurrent end users. It returns responses, with content, information, or database lookups, quickly. Whereas a Java process would suspend further operations until a database query had been answered, Node.js's non-blocking system continues to execute commands and get work done while the query is going on.

When developers work in Node.js, they can change the code they're working on, direct it to run, and see whether it works -- in the blink of an eye. With Java, what was often a 15-second (or even up to two minute) wait when deployed to a staging server was a few thousandths of a second wait in Node.js. "Letting developers see changes almost simultaneously was a huge, huge win," said Scott.

Node.js language emerged from a project at cloud service provider Joyent in 2009. Part of Node.js's speed comes from the Google V8 runtime engine for JavaScript, found in the Google Chrome and Apple Safari browsers. "Google invested a lot in V8," he noted. PayPal can use it because Google has made it open source code.

Scott said PayPal had five engineers redoing the PayPal Wallet application using Java when he decided to assign a two-person engineering team to work on the same task using Node.js. Within two months, that team had caught up to the five-person team.

"You can do more work in a shorter amount of time with half the people," Scott concluded. Part of the conversion to Node.js was also a conversion to agile development methods instead of the waterfall approach. Node.js lends itself to agile development because it requires 33-50% fewer lines of code to get a job done, he said.

PayPal still has services written in Java and C++ that the web applications and Node.js applications call on. But PayPal Funding Source, PayPal Account Details, PayPal LogOn, and Wallet now have user experiences set by Node.js, not older technologies.

PayPal has redone 22 of its customer applications, most of them formerly in C++, Java, or Java Server Pages, into the lighter, faster, non-blocking functionality of Node.js. One other Node.js benefit: Because it includes an HTML server in its operations, no separate Apache Web Server is needed.

Before Scott came to PayPal, he developed the Rico library used in Ajax programming and co-authored "Designing Web Interfaces" for O'Reilly. But he's drawn to the challenge of converting a first-generation e-commerce company, which has always done business through PCs interacting with Web applications, into a more modern and mobile organization. "In the beginning, we thought Node.js would scale the same as Java, but we're seeing much improved performance and scaling. I've loved the developers' joy it's created."

What do Uber, Bank of America, and Walgreens have to do with your mobile app strategy? Find out in the new Maximizing Mobility issue of InformationWeek Tech Digest.

Charles Babcock is an editor-at-large for InformationWeek, having joined the publication in 2003. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive Week. He is a graduate of Syracuse ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
rradina
50%
50%
rradina,
User Rank: Ninja
3/17/2014 | 11:03:16 PM
Is it really an advantage?
From the article:

"Whereas a Java process would suspend further operations until a database query had been answered, Node.js's non-blocking system continues to execute commands and get work done while the query is going on."

Java code is almost always executed in a web application container like JBoss, Tomcat, Weblogic or WebSphere.  Those servers have thread pools that service a configurable number of concurrent HTTP requests (based on the number of cores in your server, each core's speed and total server memory).  They also have connection pools that allow for a configurable number of concurrent DB operations (depending on the strength and type of queries issued to the DB server).

I understand the Node.js asynchronous architecture.  It uses callbacks when work is finished and that Javascript closures make this seemingly easy to code (depends on whether or not the developers are used to closures).  However, somewhere there's still a limit to throughput based on the number of concurrent asynchronous operations permitted and backed by the number of concurrent DB requests permitted (some kind of connection cache).  It cannot be a free-for-all.

When analyzed on a deeper level, this statement seems to be a six to one, half dozen to another subjective call.  Both environments allow more than one thing to happen at a time but they achieve it through different architectures.  I fail to see how or why an asynchronous callback that must end up processing the work via a pool of synchronous threads, is any more efficient than having an up-front thread pool of synchronous threads.

I also fail so see why one architecture would be more efficient than the other.  In fact, the asynchronous programming model looks hideous and even the article mentioned it's a pain to debug.  The up-front thread pool model where each thread blocks on synchronous, relatively long-running requests seems more straightforward to program and for the life of me, I'm not sure why anyone would hail the asynchronous architecture as an advantage.

That said, I cannot disagree that it would be absolutely fabulous to change code and see instant results.  When I first started writing web pages in 1996 with Microsoft's Active Server Pages, it had a fast-turn-around programming model.  While still a shock to those familiar with stateful, event-driven fat-client GUIs (but like a warm blanket to those used to CICS), there were no long build times and changes were instant.  Save the file, hit the site.  However, the larger an ASP application became, the more disgusting and impossible it was to maintain.  There were no internationalization features or built-in support to organize code.  Server-side includes would only go so far.  While Javascript is much nicer than VBScript (it was really limited), it would seem Node.js would also run into similar problems.

While developers can make a mess with anything, it seems Node.js is returning to where the web began and we evolved from that to more complex architectures.  Maybe we went too far (I often think that) but what does Node.js offer that makes it a "back to the future" alternative?

 
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
3/17/2014 | 1:33:50 PM
A line from his first review?
I didn't get a chance to ask. Bill Scott once had a consulting company, LooksGoodWorksWell. And his blog still appears under that name. Is this a line from his first review as a programmer? You can see the irony, if it is.
8 Steps to Modern Service Management
8 Steps to Modern Service Management
ITSM as we know it is dead. SaaS helped kill it, and CIOs should be thankful. Hereís what comes next.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Nov. 10, 2014
Just 30% of respondents to our new survey say their companies are very or extremely effective at identifying critical data and analyzing it to make decisions, down from 42% in 2013. What gives?
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.