The e-commerce fashion startup Rent the Runway comes with a simple but revolutionary premise: browse its selection of high-fashion luxury clothing, pick out an outfit, and the company ships it to you. You wear it, look fabulous, then send it back, renting your Oscar de la Renta by the piece or via unlimited monthly subscription. It’s like Netflix for women’s designer duds.
Actually running this business, however, is anything but simple. To keep the customer experience nimble, Rent the Runway must stay as current with web development best practices as it does with the ever-changing fashion trends.
First comes creating and maintaining multiple simple-to-use and attractive platforms (this is fashion, after all) as gateways to Rent the Runway’s 100,000-plus clothing, jewelry and handbag options. Then each of those 100,000 items requires real-time location and tracking: Charlene in Chicago can’t have that chartreuse Chanel handbag because Julie in Joliet hasn’t sent it back yet.
As the company grew, Rent the Runway’s software engineers were having particular trouble keeping the site and app reliable and performant. Browsing often crawled to a near halt at peak times as ever-increasing numbers of humans (and robots) hit the site, frustrating the company’s $5 million+ subscriber base of would-be shoppers.
Rent the Runway was not alone. Very similar challenges plague pretty much the entire sharing economy sector, especially as many sharing-economy companies are experiencing hyper growth and need scalable solutions, now.
Rent the Runway leveraged Node.js’s non-blocking asynchronous architecture to speed up front-end performance and get those shoppers back to their haute couture happy places, according to Sarah Meyer, who worked as a software engineer at the company when it hit upon the solution of using Node.js to create an isomorphic architecture that would allow page rendering on both client and server side.
All This to Make a Really Slow Webpage
In its early days, Meyer says, Rent the Runway — which launched in 2009 — used Backbone.js with jQuery.
The site was “difficult to navigate, and [it had] a lot of complicated client-side logic that didn’t have any server side backup,” she explained. “Functionalities that could only be accessed by going to a page and clicking a button to fire a JavaScript event to call our servers. Literally, everything happened in the front end. All this was how to make a really slow webpage — have it load and then kick off a whole slew of server requests.”
This started to get especially untenable once shopping from mobile devices, which are slower, to begin with and were becoming more popular with the company’s users.
The company evolved a web application stack that dealt with at least some of the performance issues. A front-end written in Backbone.js and Ruby communicates with a backend based on Java web services written primarily on DropWizard.
The setup was basically “a standard service-oriented architecture where basically we have to integrate a lot of responses from a bunch of different back end services to show our customers accurate information about whether the exact dress they want is still available,” Meyer explained. Rent the Runway partners with various fashion merchandisers, each of course using different implementations.
Even with a solid SOA in place, there was a still a need for speed, however.
“At first we wanted to just send HTML and kick off an absolute minimum of requests, and then only in response to user requests,” recalled Meyer. “We were a Java shop in our service layer, and the layer that served up the Backbone app to customers was in Ruby. There was no way to change that decision. Way too much code had been written at that point.”
A major attraction of isomorphic architecture, however, is the ability to transfer the load of traditional client-side rendering onto your own servers — and Rent the Runway definitely wanted in on that party. JavaScript itself seemed key to the solution, but not the whole solution. “JavaScript implementations are very different on different browsers, so expecting your JS to function flawlessly on all browsers is not only unrealistic but puts unreasonable expectations on your QA team. Especially when that team is just one person, as was the case at Rent the Runway,” Meyer said, laughing.
Ultimately, “We decided we could take React front-end framework code, which traditionally runs on the client side, and take the work of rendering the HTML pages on our side. It’s so much faster to do that work on the server and have more control. Also knowledge of what goes wrong,” explained Meyer. “React is one of best frameworks right now for server-side rendering, and the way you actually do that, move that on over, is with just a tiny little Node process.”
Don’t Go Back to 2001
But what’s the big deal, really, about server-side rendering? Couldn’t the team reconfigure the existing stack to handle it without adding yet more code? “If it was just about having server-side rendered HTML, we could have had Ruby do everything,” Meyer said. “But we didn’t want to go back to 2001 — we wanted to maintain the satisfying user experience and fast interactions of a modern JS powered web application. So we actually designed this so there would be a mapping between the URL of a page and the state object we are passing to React, and we wrote client side code to kick off an AJAX request to the server. That way you send down just the JSON to respond, without reloading the whole page. It’s a much more nimble process.”
Asked to break down that entire “nimble process,” Meyer explains that the HTML output of a React application “is kind of a function of a state object, which is really just a standard Javascript object. And you plug that state object into the templates you have written with React, and from that, you get your full client-side HTML. What’s great about this is existing server-side Ruby code generates the state object for our React, plus this tiny server side Node.js process doing the very same thing React components would have been doing on the client side…
“When you first hit one of these pages we would call out to the URL for a standard HTML request. If you have some action on the client side that calls out to the server, new information like calling out “show only black cocktail dresses,” the URL will change and there will be an Ajax call made to the exact same endpoints that were being made to send down the full HTML — but since it’s an AJAX request we already have that loaded up React environment running. So we need only get a new initial state object and reload that on the client,” Meyer said.
“So this is what gives us that best of both worlds — we don’t have to do full page reloads every time someone is navigating within the app, but don’t also have that problem of single page applications where if your JavaScript doesn’t work, you don’t have anything. It’s easy to forget how slow and unsupported JS can be for a lot of people out there.”
Twenty-eight Days Later
The major shift in Rent the Runway’s approach was more about strategy than implementation. In practice, the changeover took just under a month. “Writing the Node process and implementing the server side rendering, that was really two days of it, max,” said Meyer. “The rest of the time was spent getting the Ruby where it needed to be. This was made possible mainly due to using React as the framework — though Ember would work, and even Backbone could be possible if you home-brewed some stuff.”
The upshot, according to Sarah Meyer: “With Node we can take work from client side and put it back into server while keeping our existing Ruby code and starting to write React code, which is itself JavaScript code and the most comfortable thing for our developers.”
“We could swap out Ruby for Python, we could swap out Java for Go, but we could not swap out Node for anything else. It’s so cool how this little Node process just knits everything together,” she said.
Feature image via Pixabay.
