The Problem

Typically people see the problem to be solved as simply achieving feature parity with an existing solution—i.e., delivering Walmart.com. While achieving feature parity using a newly developed, unproven technology stack is not a trivial undertaking, that in itself does not provide any real value to the business or the customer. It just moves the eggs from one basket to another.

The real problem is not just delivering Walmart.com, but rather considering how it is delivered and how that delivery solution scales across multiple tenants and clients. Even this problem definition fails to adequately describe the true scope of the problem and the potential for value add by a new technology stack. The real value is determined by whether the new technology and processes can achieve the following guiding principles better than the previous solution:

• Attract and retain engineering talent

• Increase development velocity

• Improve code quality

Ultimately these guiding principles translate to reducing engineering costs to the business and delivering better experiences to the customer, faster. For instance, switching to a single language and runtime container that can be deployed across servers and clients increases development velocity, which in turn allows the business to quickly deliver product enhancements and services across channels. This also reduces development costs. Another example is providing engineers with tools and technologies that they are passionate about using. This will help to attract and retain talent. It will help improve the stack and developer knowledge, because a community will organically arise around these technologies. Lastly, if you select a technology that is flexible but still defines a rendering lifecycle, event interface, and composition pattern, then code quality will improve because there will be clear standards for these core UI patterns. If not, engineers across the organization will make the same decisions multiple times with different design outcomes, which causes reusability and integration issues and increases development costs.

There are too many examples to enumerate, but if you focus your solution and decisions on the guiding principles outlined here, then you will be much better off than if you just ride the latest technology bandwagon for the sake of popularity.

The Solution

As noted earlier, at Walmart the problem is being solved by React and Node. This is because these technologies met our needs and aligned with our goals of attracting and retaining talent, increasing development velocity, and improving code quality—in addition to solving the typical issues addressed by any isomorphic JavaScript solution by providing all of the following:

• SEO support

• Distributed rendering

• Single code base

• Optimized page load

• Single stack/rendering lifecycle

React also allowed us to easily share encapsulated pieces of UI rendering logic (i.e., components) across tracks, which greatly improved reusability and the quality of the components as numerous tracks enhanced them. It also provided a common interface for application developers to construct web and native mobile UIs. Furthermore, it provided a great composition model and the community had already defined composition patterns/best practices, such as container components, and presentation components that we could follow. Additionally, the low cost of rerendering the entire UI afforded by the virtual DOM makes UI state management much simpler than the approach of programmatically cherry-picking and manipulating sections of the DOM in application code. Finally, the React community is very active and there are numerous supporting libraries, patterns, and case studies for building and maintaining applications.

Rendering on the Server

The general approach is to run a Node web framework such as hapi or Express and call React’s renderToString method. There are many variations to this, but its simplest form can be seen in Example 12-1.

import Hapi from 'hapi';
import React from 'react';
import { renderToString } from 'react-dom/server';
import html from './html';
import Hello from './hello';

class Hello extends React.Component {
 render() {
  return <div>Hello {this.props.text}!</div>;
 }
}

const server = new Hapi.Server({
  debug: {
    request: ['error']
  }
});
server.connection({
  host: 'localhost',
  port: 8000
});

server.route({
  method: 'GET',
  path:'/{42*}',
  handler: (request, reply) => {
   reply(html({
     html: renderToString(<Hello text="World"/>)
   }));
  }
});

server.start((err) => {
  if (err) {
    throw err;
  }

  console.log('Server running at:', server.info.uri);
});

The HTML string from the Hello component is rendered to the template that is returned as the handler response, as seen in Example 12-2.

export default function (context) {
  return (`
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
      </head>
      <body>
        <div id="content">${context.html}</div>
        <!--
         this would be a webpack or browserify bundle
         <script src="${context.js}"></script>
         -->
      </body>
    </html>
  `);
}

This approach works well for static sites in which components do not rely on data on the client. To ensure that this data makes it to the client, a step is added to serialize any data used when rendering on the server (Example 12-3).

server.route({
  method: 'GET',
  path:'/{42*}',
  handler: (request, reply) => {
   // this could be data from a service, DB, etc.
   const data = { text: 'World' };
   reply(html({
     data: `window.__DATA__ = ${JSON.stringify(data)};`,
     html: renderToString(<Hello text={data.text} />)
   }));
  }
});

This data is then passed to the template along with the HTML string, as seen in Example 12-4.

export default function (context) {
  return (`
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <script>${context.data}</script>
      </head>
      <body>
        <div id="content">${context.html}</div>
        <!--
         this would be a webpack or browserify bundle
         <script src="${context.js}"></script>
         -->
      </body>
    </html>
  `);
}

The next enhancement usually added is a router that can be shared across the server and the client. This is necessary because without a way to match URLs to handlers—components, in this case—every URL would return the same response. The most commonly used router is the react-router because it was designed to work with React and is a React component itself. The typical approach is to use the react-router match function to map incoming requests to a route, as shown in Example 12-5.

import Hapi from 'hapi';
import React from 'react';
import { renderToString } from 'react-dom/server';
import { match, RouterContext, Route } from 'react-router';
import html from './html';

// code omitted for brevity...

const wrapper = (Component, props) => {
  return () => {
    return <Component {...props} />
  }
}

server.route({
  method: 'GET',
  path:'/{42*}',
  handler: (request, reply) => {
    // this could be data from a service, DB, etc.
    const data = { text: 'World' };
    const location = request.url.path;
    const routes = (
      <Route path="/" component={wrapper(Hello, data)} />
    );

    match({routes, location}, (error, redirect, props) => {
      if (error) {
        // render 500 page
        return;
      }

      if (redirect) {
        return reply.redirect(`${redirect.pathname}${redirect.search}`);
      } else if (props) {
        return reply(html({
          data: `window.__DATA__ = ${JSON.stringify(data)};`,
          html: renderToString(<RouterContext {...props} />)
        }));
      }
    });

    // render 404 page
    return;
  }
});

Quite a bit of new code was introduced in this example. Let’s break it down:

• wrapper is used to inject props into react-router route handlers.

• The react-router match function is used in conjunction with the path (location) to determine if there is a matching route.

• If props exists, then a route was matched and the RouterContext—i.e., the route handler component, which is the wrapped Hello component in this case—is rendered.

Resuming on the Client

The previous section described the fundamental steps that most isomorphic React applications execute when rendering on the server. Everyone has their own slightly different implementation, but in the end an HTML document consisting of markup from the rendering of the React component tree to a string and related data is sent to the client. It is then up to the client to pick up where the server left off. In isomorphic React applications this is done simply by calling React.render on the DOM node where the output from renderToString was injected on the server (see Example 12-6).

import React from 'react';
import ReactDOM from 'react-dom';

class Hello extends React.Component {
 render() {
  return <div>Hello {this.props.text}!</div>;
 }
}

const props = window.__DATA__;

ReactDOM.render(<Hello {...props} />, document.getElementById('content'));

Example 12-6 will rerender the component tree, applying any differences between the virtual DOM created by ReactDOM.render and the actual DOM. It will also bind all component event listeners (among other things; see the React documentation). The same principle applies when using the react-router, as illustrated in Example 12-7.

import React from 'react';
import ReactDOM from 'react-dom';
import { Router, browserHistory } from 'react-router'

class Hello extends React.Component {
 render() {
  return <div>Hello {this.props.text}!</div>;
 }
}

const wrapper = (Component, props) => {
  return () => {
    return <Component {...props} />
  }
}
const props = window.__DATA__;
const routes = (
  <Route path="/" component={wrapper(Hello, props)} />
);

ReactDOM.render(<Router history={browserHistory} routes={routes} />,
  document.getElementById('content'));

This approach works really well because now routes can be shared between the client and the server. The last piece of the puzzle is ensuring that any rehydrated data is passed to the components. This is usually handled by a wrapper or provider component that resolves data for the component tree (e.g., react-resolver, async-props, Redux, etc.). However, we are using the wrapper approach just as we did on the server for simplicity.

That is all it takes to get a simple isomorphic React application up and running. As you can see, these steps are easily translated to the steps described in Part II, with some being combined and occurring implicitly (e.g., ReactDOM.render binds event listeners and creates component instances).

Time to First Byte

When we started migrating to React, we immediately found that our Time to First Byte (TTFB) was not on par with our existing apps. Server-side CPU profiling revealed that a majority of the time was being spent in ReactDOMServer’s renderToString code to render the initial markup on the server.

It turns out that React’s server-side rendering can become a performance bottleneck for pages requiring many virtual DOM nodes. On large pages, ReactDOMServer.renderToString(..) can monopolize the CPU, block Node’s event loop, and starve out incoming requests to the server. That’s because for every page request, the entire page needs to be rendered—even fine-grained components, which, given the same props, always return the same markup. CPU time is wasted in unnecessarily rerendering the same components for every page request. We knew that in order for React to work for us we had to change something fundamental to the framework in order to reduce the rendering time on the server.

Component Rendering Optimization

We decided to trade space for CPU time. We applied two complimentary optimizations: component memoization and component templatization.

const InstantiateReactComponent = require("react/lib/instantiateReactComponent");

...

const WrappedInstantiateReactComponent = _.wrap(InstantiateReactComponent,
 function (instantiate) {
   const component = instantiate.apply(
     instantiate, [].slice.call(arguments, 1));
   component._instantiateReactComponent = WrappedInstantiateReactComponent;
   component.mountComponent = _.wrap(
      component.mountComponent,
      function (mount) {
        const cacheKey = config.components[cmpName].keyFn(
          component._currentElement.props);
        const rootID = arguments[1];
        const cachedObj = lruCache.get(cacheKey);
        if (cachedObj) {
          return cachedObj.markup.replace(
            new RegExp('data-reactid="' + cachedObj.rootId, "g"),'data-reactid="' +
              rootID);
        }
        const markup = mount.apply(
          component, [].slice.call(arguments, 1));
        lruCache.set(cacheKey, {
           markup: markup,
           rootId: rootID
        });

    return markup;
    });
  }
  return component;
 });

Module.prototype.require = function (path) {
 const m = require_.apply(this, arguments);
 if (path === "./instantiateReactComponent") {
    return WrappedInstantiateReactComponent;
 }
 return m;
};

var componentCache = require("@walmart/react-component-cache");

var cacheKeyGenerator = function (props) {
   return props.id + ":" + props.name;
};

var componentCacheRef = componentCache({
  components: {
    'Component1': cacheKeyGenerator,
    'Component2': cacheKeyGenerator
  },
  lruCacheSettings: {
  // LRU cache options, see below
 }
});

var React = require('react');

var ProductView = React.createClass({
  render: function() {
    var disabled = this.props.inventory > 0 ? '' : 'disabled';
    return (
      <div className="product">
        <img src={this.props.product.image}/>
        <div className="product-detail">
          <p className="name">{this.props.product.name}</p>
          <p className="description">{this.props.product.description}</p>
          <p className="price">Price: ${this.props.selected.price}</p>
          <button type="button" onClick={this.addToCart} disabled={disabled}>
            {this.props.inventory ? 'Add To Cart' : 'Sold Out'}
          </button>
        </div>
      </div>
    );
  }
});

module.exports = ProductView;

"use strict";
// Example component cache that can be used templatized
var componentCache = require("@walmart/react-component-cache");

var componentCacheRef = componentCache({
    components: {
      "ProductView": {
        templateAttrs: ["product.image", "product.name", "product.description",
         "product.price"],
        keyAttrs: ["product.inventory"]
      },
      "ProductCallToAction": {
        templateAttrs: ["url"],
        keyAttrs: ["availabilityStatus", "isAValidOffer", "maxQuantity",
         "preorder", "preorderInfo.streetDateType", "puresoi",
         "variantTypes", "variantUnselectedExp"
        ]
      }
    }
});

component.mountComponent = _.wrap(
   component.mountComponent,
   function (mount) {
     const cacheKey = ...
     const rootID = arguments[1];
     // Iterate over configured template attributes
     // and set template delimiters on props
     templateAttrs.forEach((attrKey) => {
        const _attrKey = attrKey.replace(".", "_");
        templateAttrValues[_attrKey] = _.get(curEl.props, attrKey);
        _.set(curEl.props, attrKey, "${" + _attrKey + "}");
     });
     const cachedObj = lruCache.get(cacheKey);
     if (cachedObj) {
       const cacheMarkup = restorePropsAndProcessTemplate(
          cachedObj.compiled,
          templateAttrs,
          templateAttrValues,
       curEl.props);
       return cacheMarkup.replace(
          new RegExp('data-reactid="' + cachedObj.rootId, "g"),
                     'data-reactid="' + rootID);
     }
     const markup = mount.apply(component, [].slice.call(arguments, 1));
     const compiledMarkup = _.template(markup);
     self.lruCache.set(cacheKey, {
       compiled: compiledMarkup,
       rootId: rootID
     });
     return restorePropsAndProcessTemplate(
        compiledMarkup,
        templateAttrs,
        templateAttrValues,
        curEl.props);
});

    const restorePropsAndProcessTemplate = (
     compiled, templateAttrs, templateAttrValues, props
    ) => {
      templateAttrs.forEach((attrKey) => {
        const _attrKey = attrKey.replace(".", "_");
        _.set(props, attrKey, templateAttrValues[_attrKey]);
      });
      return compiled(templateAttrValues);
    };

Performance Improvements

By applying the memoization and templatization optimizations we were able to improve the mean request time by 40% and the 95-percentile request time by nearly 50%. These optimizations freed up more of the event loop on our Node servers and allowed them to do what Node does best: asynchronous data fetching. The result was lower CPU time for each page request and more concurrent requests that are not blocked on renderToString(..). As you can see in Figure 12-2, the CPU profiles of one server request after applying the optimizations looked much better.

Figure 12-2. CPU profile with and without optimization

If we were to highlight all the cached markup that was returned to a sample page, it would look something like Figure 12-3 (the shaded area indicates markup that was cached on the server).

Figure 12-3. Example page using optimization (the shaded area indicates markup that was cached)

It is important to note that there are several other independent projects that are endeavoring to solve the React server-side rendering bottleneck. Projects like react-dom-stream and react-server attempt to deal with the synchronous nature of ReactDOM.renderToString by rendering React pages asynchronously. Streaming React rendering helps on the server by preventing synchronous render processing from starving out other concurrent requests. Streaming the initial HTML markup also means that browsers can start painting the page earlier (without having to wait for the entire response). These approaches help improve the user’s perception of performance since content can be painted sooner on the screen. However, the total CPU time remains the same since an equivalent amount of work needs to be done on the server, whether it is done synchronously or asynchronously. In contrast, component memoization and templatization reduce the total amount of CPU time for subsequent requests that rerender the same components again. These rendering optimizations can be used in conjunction with other performance enhancements like asynchronous rendering.