Hey, I'm Matt, a freelance Software Engineer based in the UK. I work primarily in Ruby on Rails, and React
In a previous post I talked about how I set up server side rendering of React components in Rails with Hypernova. I went on to build a complex Ruby based GraphQL data pre-fetcher because I could not work out how to do asynchronous pre-fetching of data in Hypernova alone. Well, it turns out though unclearly documented, its actually quite easy to do async pre-render work in Hypernova. That means we don’t need to do the crazy things I was doing in my previous post, and can instead pull off my dream: server side rendered React, served by the back-end language / framework of your choosing.
I’m going to assume you’ve already set up Hypernova with Rails (or the back-end of your choosing). In this post, I will cover:
- Understanding how Hypernova’s renderer works
- Extending it to support pre-fetching GraphQL data with Apollo Client
- Extracting this GraphQL data for rehydration on the client’s Apollo Client
- Server side rendering your component with this pre-fetched data included
UPDATE: This post has been made redundant by my discovery of a simpler approach. Please see: Server Side Rendering for React + Apollo GraphQL Client.
In a previous post I talked about how I set up server side rendering of React components in Rails with Hypernova. One detail I skimmed over in that post was how I got the data dependencies of our React components in Ruby-land. We’re a React + GraphQL shop (via Apollo Client), and following GraphQL best practices, our data requirements are colocated with the components that need the data, so this is a pretty tough problem. At first this seemed unsolvable, but thanks to some amazing tooling from the Apollo team, it can be done with surprising ease, and best of all no code duplication.
In this post I will walk you through how to extract your React components’ GraphQL queries, fragments and all, into a format a Rails app can read, run, enabling full data hydration and server side rendering. While I am using Rails and React, the principles of this tutorial can be applied to any server language with a GraphQL client, and to any JS framework using Apollo Client or (I believe) any GraphQL JS client that supports denoting queries with the
I recently discovered Hypernova, a wonderful tool from Airbnb, making the unimaginable possible: server side rendered React components, in a Rails app, with no Node server required in development, or even production.
In the post, I’ll walk you through how to make this a reality in four steps:
- Installing Webpacker 3.4.1, in a Rails 4.2+ app
- Installing Hypernova Ruby Client, initially just client side rendering React components
- Configuring Webpacker + Hypernova Server, to support rendering those same components server side
- Adding health checks, so we know things are working in production
But first, let me explain what I mean by “no Node server required”… After all, if you want to do server side rendering, you need to run a Node process on your server, so how can you not have a dependency on Node? Well, the architecture of Hypernova is such that during render, if a connection cannot be quickly established with the Node process, or the process errors during render, it falls back to the usual client side rendering approach. Coming from a Rails shop that over the years has dipped its toes further and further into JS heavy frontend, this is a great comfort to me. I am not a Node guy, I don’t have anything against Node, but I definitely don’t have expertise in it. So if I can have the benefits of SSR, without adding points of failure, and without massive increase in app complexity, thats a dream come true! Its also great for development; as another engineer, you can come into this project, edit a SSR React component, and check it in your browser, all just from a