Server side rendering a React app while keeping users and developers happy
Server side rendering (SSR) a website yields better perceived performance and faster load times. SSR is great for Search Engine Optimisation (SEO) because it provides plain HTML that can be indexed. In addition SSR contributes to a better user experience since the browser can directly interpret the HTML. Recently, we investigated server side rendering at the Bol.com checkout using their existing frameworks and processes.
Let’s start with a quick recap on server side rendering (SSR). In normal web pages with only html, the browser just renders the website. However since websites become more dynamic and use JavaScript frameworks, rendering on the client takes time. During rendering, the screen remains blank. This can become a problem for a couple of reasons.
If you render JavaScript in the browser, loading times become longer and web pages de facto slower. This is disastrous for your customers. Speed is essential. Research has shown that loading times of even a few seconds can be the difference between a customer staying or leaving your website.
Bad for SEO scores
Client side JavaScript frameworks are also bad for seo. Search engines use crawlers to index web pages. Mostly they do not interpret JavaScript so the framework cannot render the components. Product pages like we see at Bol.com use SSR so these pages can be indexed by crawlers. Moreover, when a visitor lands on these pages, for instance from a Google-result, they immediately see what they searched for.
Existing areas
We wanted to see if we could implement server side rendering of JavaScript in an existing and complicated development context without disrupting the way of working for developers. Frameworks like Handlebars, Angular or React can also be used on the server to implement server side rendering. For the new Bol.com checkout we use the latter.
We thought about how to apply server side rendering using React in Java since we didn’t want to change Bol.com’s environment. In addition React has other advantages we can use that are perfect for what we try to do. It already has support for server side rendering without having to call other functions. Also, it’s a great library to handle state mutations in your component tree very efficiently.
Frictionless development!
Our next challenge was applying that process into the way we work. Traditionally, developers from different teams speak different languages. Frontend developers speak JavaScript, backenders tend to speak Java. When working on server side rendering these things come together. Not only do you have to consider the technicalities, but also the processes of how not to be in each other’s way too much. You don’t want to force a different development ecosystem on each other, that would go against what we’re trying to accomplish!
Normally, server side rendering would be done on Node.js, but many companies are hesitant to do this because of security reasons or because they simply are not familiar with it. Instead, they just stick to the Java Virtual Machine (JVM) on their backends.
Docking into containers
Docker turns out to be a really good solution for this separation of concerns. Docker gives you the possibility to make different containers, so we used this to build different containers for frontend and backend development. That way you can work as a frontend engineer in the frontend container, doing all the things that frontend needs doing (like installing React, or run a webpack dev server). The same goes for the backend container.
This Docker solution works for us in many other ways. Let’s say the company wants to change the backend environment at some point in the future. No problem! The Docker setup makes that super easy. You don’t need a lot of adjustments, you can just migrate to a new environment while everything keeps working as it should. That saves a lot of time! Also, you don’t run into problems where you have to install of remove repo’s or programs, or fix those annoying migration issues. That’s the beauty of containerisation.
Transforming Java into JavaScript
Still, we had our share of obstacles. For instance how to get JavaScript to run on the backend. It is, after all, a very different language compared to Java.
It turns out there is a solution for this. Java has a JavaScript engine available called Nashorn. This interprets all the JavaScript on the JVM. That way, Nashorn can perform server side rendering using the React framework. And that means you can do all the preparation (like loading the website text) in the backend. All the browser gets to see is bare html — which is exactly what we want for fast SEO and UX.
Unfortunately, Nashorn will disappear in the future. This made us a little anxious because we did not know if there would be a successor. Luckily there is another project, GraalVM, and it speaks even more languages! So thankfully, this won’t be a problem and is easily fixed using our dockerised approach.
PoC
So that’s our proof-of-concept to implement server side rendering using Java, while keeping both front end and back end development way of working intact. We want to test this thoroughly, and optimise performance from there. Then we will plan sprints to bring it into production. First for our checkout, then it is available for use on other projects!
Authors: Niels van Midden & Jerre van Veluw
