Hey, I'm Matt, a Software Engineer currently based in the UK. I work for Caring.com 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. 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
For a Rails side project recently I finally had the need for a background task handler. Now traditionally I’d jump at Sidekiq, and for good reason. It’s sexy, relatively simple, and comes with a ton of niceties like automatic exponential back-off retries. For this project however, at least at this stage, Sidekiq is overkill. We just need to run some ActionMailers out of the render loop, so we’d like to avoid booting up another server if possible.
So, in comes SuckerPunch, a gem built to address exactly this issue. SuckerPunch uses Celluloid to operate a barebones background task handler inside the server process, avoiding the significant memory overhead of running two Rails instances. Now while its worth noting thanks to the Global Interpreter Lock present in MRI, CPU intensive jobs are still liable to slow down your requests, however the GIL does not apply to external I/O, and so the bulk of what makes a mailer slow (negotiating SMTP) doesn’t block the server.
subscribe via RSS