Can Gatsby replace your CMS? Part 2

GatsbyJS is quickly gaining momentum in the web industry. But how does it fit into the landscape of the traditional CMS? In this series, we will explore the trade-offs between a decoupled Gatsby site and a traditional, monolithic CMS such as Drupal or Wordpress.

Can Gatsby Replace Your CMS? Part 2

GatsbyJS is quickly gaining momentum in the web industry. But how does it fit into the landscape of the traditional CMS? In this series, we will explore the trade-offs between a decoupled Gatsby site and a traditional, monolithic CMS such as Drupal or Wordpress.
TLDR: Gatsby only deals with the presentation (aka theme) layer, so it won't replace your CMS completely. But it can be used to strategically replace parts of it in order to maximize performance and scalability.
This is part 2 of a 3 part series, see part 1 here.

Hidden Tradeoffs

In part 1 we explored the benefits provided by Gatsby. In this post, we will explore the tradeoffs you make when you decide to replace the front-end of your CMS with Gatsby. To be fair, much of what follows is not specific to Gatsby. It applies to all sites built using the JAMStack methodology. 

Source Data Access

When you're building a monolithic CMS, you have absolute control over the type of queries that you execute because you have the option to write them directly. With Gatsby, access to your source data is proxied through the source plugin for the data store you're connecting to, which means you're limited to queries which that plugin supports.
If this becomes a problem, you can work around this without much trouble. For instance, you can set up an endpoint on your CMS and access it during Gatsby's build process. But the built-in access to data is by definition less flexible as the GraphQL API imposes structure. In many cases, this structure is actually a good thing, but it may cause frustration.

Forms

Much of what we do on the web, from commenting to gathering payment details are achieved via forms. Every major CMS allows you to create customizable forms for use on the front-end of your application. But JAMStacks don't offer this out of the box because there is no server behind your application to process the form submission.
Again, this is a solvable problem. You can reach for a SaaS application such as Typeform or Wufoo, or you can set up a form handler yourself, perhaps in a serverless function. You could even set the handler upon your CMS, but this negates some of the security benefits offered by the JAMStack as you are allowing direct access to your CMS's server from the outside world.

Redirects

Redirects are a no-brainer for any mature CMS. They give content editors flexibility to experiment with and change URL's over time without having to worry about broken links or SEO concerns. Unfortunately, static sites don't offer a good way to create redirects, at least not on their own. You could use a tag like this to perform a redirect in static html: <meta http-equiv="refresh" content="0; URL='<http://yoursite.com/some-other-page>'" /> , but this approach is not recommended.
An alternative approach is to select a static hosting provider that allows you to register redirects server-side, such as Amazon S3 or Netlify. With this approach, you can create redirects in your CMS back-end as usual. At build time, you can then query your back-end for existing redirects and create them on your static hosting provider.

Content Preview

Most CMS's have the ability to preview your content before publishing, allowing content editors to iterate on content updates before revealing their work to the rest of the world. This is especially important when the editing interface does not resemble the live site, as it can be difficult to visualize content changes when they are divorced from your presentation layer.
This has historically been a pain point for JAMstack sites as the build step must run in order to see changes reflected on the site. This can be especially painful with Gatsby as the build process often takes minutes to complete, depending on the size of the site in question. Additionally, you may need to set up extra infrastructure to support previews outside of your live environment.
While this problem is definitely solvable with a bit of extra engineering effort, you can also reach for existing SaaS solutions. The Gatsby team recently released Gatsby Cloud, which solves both the preview and the build time issues. Netlify also offers a feature called Deploy Previews which could be used in conjunction with your current CMS's publish states to provide a dedicated preview environment.

Authentication

Out-of-the-box authentication is another feature that mature CMS's have had for years. This makes it easy to tailor user experiences based on authentication state, potentially offering personalized content or extra functionality after a user logs in to the site.
For Authentication to function, you need a back-end that can verify the credentials provided by the user and return a secure access token (at least at the most basic level). Since JAMstack sites don't necessarily have an associated back-end, they don't offer this functionality out of the box.
That said, there are many options that you can use to add this functionality to your JAMstack sites, such as Auth0FirebaseNetlify's Identity Service, or even your own serverless function that communicates with a back-end you control.
However, implementing any of these solutions will require more engineering effort than using the authentication capabilities of your legacy CMS. They may provide more options or a better user experience, but those benefits are not free.

What's Next?

Now that we have reviewed the benefits of a JAMstack architecture in part one, as well as the potential pitfalls, it's time to weigh the options together. Stay tuned to the final part of this series for a 10,000-foot view of the current JAMstack landscape, as well as where it is likely to go in the near future.