As you may have heard, the latest release of Gatsby, Gatsby 4 now supports SSR (Server Side Rendering). 🥳
This new addition to the way you can build with Gatsby is super exciting and to demonstrate how it works I’ve whipped up a little demo.
If you’re keen to get stuck in you can find the demo site and src code on the links below.
Demo: https://datachampionssrnycweather.gatsbyjs.io
Repo: https://github.com/PaulieScanlon/data-champion-ssr-nyc-weather
Let’s talk about SSR
If we rewind the clock a little bit back to 1995 we can find the source of Server Side Scripting, nowadays known as Server Side Rendering, so the approach of rendering web pages on the server and not in the browser is a technique which feels like it’s been around since the dawn of time, which it kind of has.
Gatsby, while very much focussed on SSG (Static Site Generation), has added this method because, well, you asked for it, so we delivered.
In this post i’ll be covering the following:
- Why would you choose to use SSR over SSG?
- How to use SSR with Gatsby 4
Why would you choose to use SSR over SSG?
Good question, and there are lots of reasons, but to keep this simple it probably all comes down to data, or more specifically how often this data changes and how important it is for visitors of your web page(s) to see real time data.
With SSR each and every time someone visits your website the data is requested from a server. SSR still statically bakes this data into the page like SSG but it does it on the fly, or as we like to say — Just In Time 😅.
The upside to this approach is: faster build times, because you don’t have to pre-prepare a web page / all of your site’s web pages upfront like you do with SSG, or as we say — Ahead Of Time ⚡.
The downside is that building a web page Just In Time 😅 means your users will experience a very slight delay before the page content is fully visible.
SSR can also be considered the second-best option with regard to SEO… but i won’t go into that now.
However, there are times where these disadvantages can potentially be overlooked.
To help demonstrate this I’ve built a Weather forecast website. It provides real time weather information for NYC for the current day and the next seven days. Using SSR I request the weather information using the US National Weather Service API each time the page is visited and bake it into the page.
How to use SSR with Gatsby 4
If you like, you can read the SSR reference guide from the Gatsby Docs: Server-Side Rendering API.
Or if you’d prefer to follow along I’ll show you how it all works.
There’s a new function called getServerData which can be exported from any Gatsby page(s).
In the demo site I only have one page, index.js and this is where I’ve exported the getServerData function.
SSR works in the same way as Gatsby page queries but instead of querying Gatsby’s data layer with GraphQL you can pass data straight to the page using plain old JavaScript via the serverData prop on the page component. It’s worth noting that because this data is passed directly to the page it’s not available to query from other pages in your site via useStaticQuery, you’ll also notice if you open GraphiQL the data isn’t available in Gatsby’s data layer.
At the absolute minimum this is how you’d use SSR.
You can see from the above that in the return statement of getServerData, on a props object I send a key value pair of something: 'test'. The src code for this page can be found here: src/pages/minimum.js
This data is then available via the destructed serverData prop on the page component, and in this example I return it wrapped with an HTML <p> element.
Something a little fancier?
Rendering “test” on a page isn’t very interesting so here’s how you can hook up to the US National Weather Service API. You can find the src code for this file in the repo here: src/pages/raw.js
There’s two requests to get the forecast for any given US city. The first request to https://api.weather.gov/points/ requires a latitude and longitude of a US city. In my demo I’ve used the latitude and longitude for New York City.
The first request returns a number of data points, one is called forecast and contains a URL which can be used to make a second request to retrieve the weather forecast for New York City.
Using data returned from the second request I poke around the response, format the updated date and return the periods which is the forecast for each day over the next seven days.
You can pass this data back to the page using props in the return statement.
I also pass back a status code of 200 if the request(s) were successful and a 500 if there’s been an error.
All this lovely data is then available to your page via the de-structured serverData prop in the page component.
What you do with it from here is entirely up to you. In my demo I’ve used the fantastic TailwindCSS to make it look pretty. There’s a guide in the Tailwind docs that will explain how to add TailwindCSS to your Gatsby project: Install Tailwind CSS with Gatsby
So there you have it, SSR with Gatsby 4! I’d love to see what you build so feel free to come find me on Twitter: @PaulieScanlon
Ttfn
Paul 🕺