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.
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.”
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.”
“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.
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.”
“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.