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.
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 your 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.
Much of what we do on the web, from commenting to gathering payment details is 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 up on 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 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 than query your back-end for existing redirects and create them on your static hosting provider.
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 paint 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.
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.
In order 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 site, such as Auth0, Firebase, Netlify'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.
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 the final part, in 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.