What is a Fallback Client side route ?

Because the sites created with Gatsby.js are static sites, which is highly optimized from a performance point of view, for the content to be accessible, the site must be built since this content is available (from the CMS or the back-end).

But in some cases, especially large content sites, content are add by the editorial team faster than builds are done. And so, some content is added (via the CMS or the back-end), but not yet available on the site.

But this problem is adjustable thanks to a “Fallback Client side route” system.

Use case : News website

On our news site, we have more than 10,000 articles, they are stored in a database, and we create static pages using the Gatsby's createPages API.

So we have, for example, articles with these following urls:

• articles/news/AZE123
• articles/hobbies/RTY345
• articles/tips/UIO433
• articles/tips/QSD345
• articles/hobbies/FGH678
• articles/news/JKL789

The articles are added to the database after their creations by the team of journalists. Every day, the team of journalists on the site write an average of 100 articles and want to make them immediately accessible, because they talk about instant actuality subjects.

But the site is only rebuild 15 times a day (or else it takes several ten minutes to rebuild) → This is a part of what we called the JAMTAX (in reference to the JAMSTACK). So, very often, it happens that articles, which have just been published, are not accessible instantly, but only after multiple minutes or even hours.

It’s so necessary to create a “Fallback Client side route”. This Fallback Client side route will be the route that will be used until the article has been statically generated. This Fallback Client side route will be generated on the client side thanks to a call to the API.

How to setup a “Fallback Client side route” in Gatsby?

Our Fallback Client side route will match with URL of this following shape : articles/:articleType/:articleId

And if the client want to access to an article that has been generated statically, he must have access to the static page (SSG) and not the Fallback Client side route, because it’s more optimised.

For this we create a page which will be this Fallback Client side, then thanks to the onCreatePage API and its matchPath argument, we will be able to redefine its matchPath when it is created :

actions.createPage({
    path,
    matchPath: "articles/:articleType/:articleId",
    component: "fallbackArticlesComponent.tsx",
    context: {
            //The necessary context for your template
        },
  })

So, all users who want to access pages with the shape articles/:articleType/:articleId, and for which there is no statically generated page, have access to the content of this fallback page (and therefore of the fallbackArticlesComponent.tsx component) .

So, we need to make a call to our API (or CMS) in this component to get the content of the article.

Also, we need to prepare a behavior on this page when the request does not found any result. Because, for example, if the user want to access the page article/typeThatDoesNotExist/IdThatDoesNotExist, then he will “fall” on our fallback page.

We can then either choose to redirect it to the 404 page (with a navigate(/404, { replace: true })), or display an error such as “Unfortunately this article does not exist”.

Feel free to ask your question in the comments, I will answer it with pleasure.