At Meural, we decided to implement server side rendering in order to increase our SEO exposure and to make social media sharing more effective. In this post, I’ll talk about how server side rendering works and the implementation that I developed.
There are also some downsides to server side rendering. These include slower server response time and, in lower bandwidth environments, slower time to interactive. For apps that run behind login screens, whose content is private, these downsides might make server side rendering less than worthwhile. For our use case, however, the benefits well outweigh the costs. Most of our app’s pages are public facing, so exposure to web crawlers is essential.
Implementing server side rendering is not a trivial task. In response to this fact, a number of libraries have emerged to make implementation a bit easier. These include Next.js, Razzle, numerous boilerplates, and others.
These libraries and frameworks can be a good choice for rapidly prototyping a feature or when starting a new app, but I would not recommend them for use in production or for extant apps. The reason for this is that using them requires surrendering a large portion of your codebase to them, which makes debugging and optimization more difficult, if not impossible, and makes you ignorant of how your app is really working. What’s more, integrating such a framework into an extant application is often more trouble than it’s worth.
Therefore, I developed a custom implementation of server side rendering at Meural. I hope that our stack is similar enough to that of other companies so that other developers might find this article useful. Our frontend uses React, React Router 3, and Redux, while our backend is a monolithic Django application.
The High-Level View
At a high level, setting up server side rendering consists in setting up the following chain of events.
POST request to our Node server, which will return our markup, plus the final state of our Redux store. Finally, we’ll embed this information into the HTML response of our Django app and send it to the client.
Let’s begin by setting up the Node server. I decided to use Express.js because it is battle-tested and very easy to use. Note that we are reading our
NODE_PORT variables from our runtime environment.
I recommend writing a simple
buildInitialState functions for testing purposes that simply return some valid output of any kind. I also recommend testing this server with cURL before moving on to anything else.
Now let’s wire up the Django app and test it’s interaction with the Node server.
buildInitialState functions, then all is well.
Defining the Render Function
It will be instructive to first look at the code of the
render function and then to explain how it works.
The first thing the
render function does is configure the Redux store. I used the same
configureStore function that I had already defined in following the usual Redux API pattern.
The second thing the
render function does is get the frontend routes of my React app, by calling a function I wrote called
getRoutes. This function takes the Redux store as an argument and returns all of the routes to my app. It prevents code duplication because I can call it in both server and browser environments (See the Handling the Client Side section below to see how it is used in a browser environment).
getRoutes, though accurate, is somewhat incomplete. The function does not just get routes. It also gets the React components of which my app is composed, since they are embedded in the definitions of the routes themselves. Therefore, the
getRoutes function is what links my existing React app to the render function.
Next, in order for the
render function to match the desired route, I use React Router’s
match function. This function’s first argument is an object containing all of my app’s routes as its first key — which we have from the
getRoutes function — and the desired route as the second key. The match function’s second argument is a callback that gets evoked after matching is complete. In a successful matching, this callback’s third argument is a
renderProps object. These
renderProps represent the state of my app’s props at a given route. I pass this object into React-Router’s
<RouterContext> component (which is a static version of its more familiar
<Router> component) to render the state of our app at the matched route.
To give the components of my app access to the Redux store, I wrap the
<RouterContext> component with the
<Provider> component from the React-Redux library.
Next, I call
ReactDOMServer#renderToString with this wrapped component as its argument to render the state of my application at the matched route to HTML.
Finally, I call
getState on my Redux store to extract its final state in case the rendering process changed anything.
If the match function fails to match the desired route, the second argument of its callback is a
redirectLocation argument. In this case, I recursively call the
render function with this new desired route. I am confident that there will never be a chain of infinite redirects because I have defined a wildcard route to handle such cases.
Calling the Render Function
The render function will not work as it is currently defined. The reason for this is that the JSX used in the function itself, as well as in the rest of my app, is not understood in Node runtimes. Therefore, I use Webpack and Babel to transpile my
render.jsx file into Node compliant code. All I had to do to make this work was to copy my existing webpack config, change the entry point to
render.jsx, and replace the target parameter with
When transpiling, I ran into some errors. Since this version of my React app will not be running in the browser, window and document will not be defined. Therefore, I had to move all references to
document to functions that are executed only after the DOM is accessible. This involved moving references to
document from methods like
Component#constructor to methods like
Component#componentDidMount will only be called after the component has been mounted to the DOM. I also had to abandon some third-party libraries that relied on
document in problematic places.
Handling the Client Side
Now that my server responds with a fully rendered page of my app, I need to adjust my client side JS to expect this. Here’s the code I wrote.
You might have noticed that I added an
async attribute to my script tag in
DOMContentLoaded before rendering with ReactDOM might not always work, since
DOMContentLoaded might have already fired, in which case, the React app would never get executed and the page would never become interactive. Therefore, I check the
document.readyState when the bundle is initially executed. If the
interactive, I initialize my React app right away. Otherwise, I add listener for
DOMContentLoaded and use my initialize function as the callback.
initializeApp function, I get the current state of the Redux store from the window and pass it into
configureStore to setup Redux. Next, I match the current route, just as I did on the server side, using the same
match functions which I discussed above. Instead of calling
ReactDOM#render, which is the usual pattern in client rendered apps, I call
ReactDOM#hydrate, which sets up React’s virtual DOM and installs listeners to make the page interactive.
Since deploying this project, we have seen much better SEO at Meural. Now a Google search for the terms
meural and some artist’s name will yield a result of that artist’s page or one of her playlists, if that artist is in our collection. Prior to this deployment, this was not possible, since we had exposed only one webpage, which contained our single-page React app.