Server Side Rendering

[pragmaticpat]

SSG, DSG, and client-side rendering can handle a vast majority of use cases in web development. But there is a small niche when you may still need to generate HTML on-the-fly. That’s when you’ll need Server-Side Rendering.

Server-Side Rendering is a method of content rendering in which each web page is served to a site visitor at runtime, meaning that a portion of the build process happens on each page request. Because the content is rendering during runtime, visitors will always get the latest version of content directly from the server—though they may have to wait a few seconds for it display.

As this is a new feature available in Gatsby 4, we're eager to hear about your experiences and use cases where you apply SSR in your Gatsby projects. Please share your questions and findings below!

Read all about SSR in Gatsby here

Thank you for building with Gatsby! 💜

[davidpaulsson]

Would it be possible to do redirects inside getServerData? Like… read the request headers and geo-redirect? Cloudflare adds a cf-ipcountry header for example one could spy on for figuring out what country the request comes from, is something similar available on Fastly / Gatsby Cloud?

[pragmaticpat]

👋 Hey @davidpaulsson - is your use case that you're attempting to to decide whether to land the visitor on a geo-specific top level domain? Either way, it'd be great to get some details behind what problem this would help you solve. Thanks!

[davidpaulsson]

👋 @praagyajoshi, yes that's exactly it. what I'd like to do honestly is geo redirect directly with gatsby cloud, like suggested here https://gatsby.canny.io/gatsby-cloud/p/locale-based-redirects, like Netlify does where you'd have the _redirects file contain something like / https://us.my-site.com/ 302! Country=us,mx or whatever. Since it's not doable (yet?) I'm basically wondering if I could utilize SSR to redirect to another URL than what they requested.

[praagyajoshi]

I think you mentioned the wrong person here @davidpaulsson 😅

[davidpaulsson]

Oh. my. gosh. Thanks for that auto-complete! Sorry @praagyajoshi! And ping @pragmaticpat 😖

[pragmaticpat]

open source is a team sport! 😆

[tlgimenes]

One thing I'm really interested on SSR is if we will have support for fallback pages like we do in Next.JS.

This is important for my use case where I have an API that is really slow for fetching data and, according to my tests, it's better to SSR only the fast part on the server and leave the rest to the client. I know that React 18 will have similar features and I wonder it better waiting for React 18 to come out.

Also, one thing I'm concerned is returning max-age like headers to the CDN and having users on two different versions of my site between deploys. This is problematic because page-data.json is mutable and if the user is in a different version of my site than the CDN, he will perform a server side navigation. I think adding a simple build hash to the page-data.json's name would solve this problem (like we do in js/css files), but I'd like to open the discussion for more comments.

Thanks!

[laurenskling]

Would it be possible to access the GraphQL data from SSR?
Something I have in mind: Creating a wildcard page, and using that parameter value in a pageQuery run by the SSR. This would allow me to make a search machine.

[moonmeister]

Moving this from twitter: https://twitter.com/moon_meister/status/1456709799907893251

How does one return an error from getServerData?

https://www.gatsbyjs.com/docs/how-to/rendering-options/using-server-side-rendering/ Suggests:

...
 } catch (error) {
    return {
      headers: {
        status: 500,
      },
      props: {}
    }
  }
}

but that does nothing in gatsby dev or gatsby serve to handle the error. It just goes on rendering the page like nothing is different and still returns a 200.

https://www.gatsbyjs.com/docs/reference/rendering-options/server-side-rendering/ doesn't even use a try/catch block suggesting that just throwing an exception will trigger the 500. That's reasonable...but what if I want to throw a 401 or anything other than a 200/500 code?

[moonmeister]

Moving status to not be under headers didn't change anything, incase this was an error of some kind.

Also no custom headers were returned in development. Is that expected?

[moonmeister]

Can confirm even Gatsby Cloud does nothing of note with the { headers: { status: 500 }}.

https://gatsbytest53287.gatsbyjs.io/badSsr/
https://github.com/moonmeister/gatsby-test/blob/main/src/pages/badSsr.js

[moonmeister]

Also, that Pattern is in the default starter. https://github.com/gatsbyjs/gatsby/blob/master/starters/default/src/pages/using-ssr.js#L44

😬

[vladar]

Sounds like a bug indeed. Thanks for the bug report 👍 I'll convert it to the new issue.

Edit: #33910

[sidharthachatterjee]

We now have a fix open over at #33914

Cheers

[moonmeister]

What's the thought behind using the getServerData headers API to also apply to the pages page-data.json file? https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/commands/serve.ts#L262-L268

[vladar]

Once React is hydrated, navigation happens on the client side. And so when you navigate to some SSR page - only page-data.json will be generated and served to the browser but not HTML.

Does it cause problems for you? Please describe your use case.

[moonmeister]

No specific big ATM. Just thought it was strange the same headers could be applied to 2 different files and was trying to understand why. Don't think I have. Areal case where it'd be bad. Thanks for the info.

[moonmeister]

Is it possible to access data queried by the page-query in the getServerData function? Or is it possible to do a Graphql query that's executed at build time that can then be used in the server side render?

[char-cole]

Is it possible to access data queried by the page-query in the getServerData function? Or is it possible to do a Graphql query that's executed at build time that can then be used in the server side render?

I'm still wondering this as well. I want to use a feature flag to toggle a head component, but I'm struggling to figure out how to make that work.

[trevorblades]

In Next.js, we have the ability to redirect to another path from within the getServerSideProps function, or report the page as notFound: https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering

These are extremely helpful tools, and while Gatsby SSR is missing these options, I figured that I could accomplish the same thing by using the status and headers properties. For example, I expected returning the following to redirect the request:

return {
  status: 301,
  headers: {
    Location: '/new-path'
  }
}

Unfortunately, this didn't work as expected. Gatsby still attempted to render my page and failed because I didn't pass any props.

For the notFound case, this is important for most SSR usecases. I try to fetch an entity based on some param, and then if it's not found I would like to render my custom 404.js page that I use for all other "not found" pages in my Gatsby site. I expected to be able to accomplish this by doing:

export async function getServerData({params}) {
  const thing = await fetchThing({id: params.id});
  
  if (!thing) {
    return {status: 404};
  }
  
  return {
    props: {thing}
  }
}

In both of these cases (redirect and 404), the page is still attempted to be rendered. Is there any workaround for this? How can I signal to Gatsby that I want to perform a redirect on the server side, or indicate the current page as "not found"?

[ebinion]

Does SSR work when using Styled Components in Gatsby v4?

I have a React/Styled Components based design system based I used originally on my primary Gatsby website and have since used to spin up a new Gatsby based micro-site. Both websites are setup using SSR per the instructions given at their respective times, but the new microsite is experiencing FOUC (flash of unstyled content). More specifically the new site doesn't seem to add styles for components from the design system to the HTML when statically built. However, SSR works for any components I create directly in the new project.

I'd appreciate tips, ideas, or pointers generally in the right direction.

Old site (no FOUC):

...
"dependencies": {
  "gatsby": "^2.28.0",
  "babel-plugin-styled-components": "^1.12.0",
  "gatsby-plugin-styled-components": "^3.6.0",
  "styled-components": "^4.4.1",
...

New site (FOUC for design system components):

...
"dependencies": {
  "gatsby": "^4.3.0",
  "babel-plugin-styled-components": "^2.0.2",
  "gatsby-plugin-styled-components": "^5.3.0",
  "styled-components": "^5.3.3",
...

[ebinion]

🙂 Found the issue! There was a mismatch between the design system's version of Styled Components and the new site's version. Updating it, fixed the FOUC.

[ilFusta]

it's possible to host a Gatsby site with SSR pages on IIS?
Does it need any particular IIS configuration or machine setup?
Is there any guide on this topic?

[moonmeister]

iis would be just routing traffic to a node app. I'd look up hosting a node application on iis then use gatsby-plugin-fasify to handle the Gatsby application logic

[HillertNext]

Disable/enable (ignore) SSR for specific environments

Hi folks. I hope I didn't overlook a similar discussion. First of all: SSR made my day. Thank you for implementing this very important feature!

Now, we want to deploy the entire Gatsby app in two different environments. One with SSR (for preview purposes) and one without SSR (SSG for end customers only). The documentation says "When a page component exports getServerData function, Gatsby treats all pages built with this component as server-rendered."
Hmm, just for my understanding: Does that mean exactly that the getServerData component really exists or not, returns undefined/null or not, props.serverData in the page component is undefined/null or not?

In case of existing getServerData component or not, it would be nice to ignore getServerData via an IGNORE_SSR configuration flag. Currently we use two instances of a page component (with and without getServerData) for each environment. Does anyone have similar requirements or any other ideas how to solve this in a nice way?

[HillertNext]

Ah, setting getServerData to undefined seems to ignore that component. I guess this allows us to enable/disable SSR for individual components in different environments.

export const getServerData = !process.env.GATSBY_IGNORE_SSR && ... || undefined

I'll keep you posted if that doesn't work well.