Now that I’ve settled back down in Alaska after a fun trip to Berkeley for BADCamp, I’m finally digesting all of the info I gathered throughout the week. As always, it was cool to look over the schedule and see what topics were getting a lot of attention; and, without a doubt, it seemed like GatsbyJS was the hot-ticket item this year. So here’s a primer on what GatsbyJS is and why the Drupal community seems so head-over-heels for this up and coming site generator.
What is GatsbyJS?
For the uninitiated, GatsbyJS is a static site generator for React which allows you to compose a website using React components and JSX. Then, with a “Gatsby build” command, the entire React app gets compiled into a set of static HTML, JavaScript, and CSS files.
However, this is nothing new. Static site generators like Jekyll or Hugo have been doing this for years. So, what makes Gatsby so popular, especially within the Drupal community? Judging by the sentiments I heard from the four sessions on Gatsby I attended at BADCamp, I noticed that folks tended to gravitate toward a few essential features that made Gatsby appealing, not only as an integration with a Drupal backend but also more broadly.
Gatsby’s Drupal Source Plugin
The feature most commonly cited in BADCamp talks about Gatsby was the source plugin ecosystem, which allows a developer to define a backend “source” from which Gatsby will build pages. There is a robust and well-developed plugin for Drupal 8 (gatsby-source-drupal), which allows Gatsby to programmatically create content from Drupal’s content types, taxonomies, as well as blocks and menus.
The plugin works like this: first, you must enable the JSON API module, which exposes routes and schemas that help Gatsby import your content into your Gatsby application. Then, on the Gatsby side, you are able to query the data from your Drupal site using GraphQL and render the query results to various React components, such as page templates.
Build/Deploy Workflow
Secondly, the architecture around deploying/building a Gatsby site lends itself well to working with Drupal - using something like the Webhooks module, you can have your Gatsby site rebuild (and thus, pull new content) on every node create, update, or delete operation, and so forth.
This is very important, considering that most static sites are perceived as being labor intensive (in the sense that every time content is updated, someone needs to recompile the site); but, to hear Gatsby co-founder Sam Bhagwat talk about it, the ready availability of on-demand build triggers and integrations makes your static site actually perform much more like a cache. However, it’s the sort of cache that doesn’t require maintaining a highly technical caching stack like Varnish or Memcache. After the minute or two it takes for the build step to complete, your changes have completely propagated and site visitors are being served the new content.
React
Love it or hate it, React is here to stay. It is rapidly becoming the most common front-end stack in web development. Although it may not be for everyone, most developers who have spent the time to learn React tend to fall hard for it. Heck, this year’s Stack Overflow Annual Developer Survey puts React as one of the most “loved” frameworks by developers this last year, with 69.4% of respondents reporting that they enjoy working with React. Obviously, something is working for React in terms of developer experience. Being able to implement a React front-end without the architectural concerns of a complete decoupled solution certainly seems to be one of the bigger motivating factors behind Gatsby’s adoption among Drupal developers.
Performance
Last, but certainly not least, Gatsby’s appeal comes largely from speed. As mentioned above, since everything is served from static files, Gatsby sites load really fast. Without any server-side code to execute, the only limitations on performance are in the size of HTML/CSS/JS bundles being served over the network. When folks in a traditional Drupal site (or any other monolithic CMS) concoct solutions for better performance there are a few usual suspects:
- better caching
- reducing bundle sizes (minifying JS and CSS, for example)
- optimizing images
- serving non-dynamic site files (such as images) from a CDN
Out of the gate, a Gatsby site effectively implements all of these features by default. Since the entire site is a set of static files, your content is effectively ‘cached’ to the state of your website as of the last executed build, and the flat files that are generated from the build perform similarly to cache catch. Likewise, because Gatsby runs a build step, our entire HTML/CSS/JS bundle is minified from source using Webpack. No configuration required! Gatsby also comes pre-wired with a bunch of image optimization, including using the Sharp image processing library and progressive image loading to get a contentful, interactive page rendered as quickly as possible. And lastly, with a completely static site the most common way of hosting the site is through a CDN - some popular ones among Drupalers who use Gatsby include Netlify and Amazon S3. On top of all of that, Gatsby also has some other nifty built-in features like prefetching, which means that after the initial page load you’ll get lightning-quick performance between internal pages on your site.
Limitations
Of course, most folks discussing Gatsby + Drupal implementations at BADCamp were quick to acknowledge Gatsby’s limitations. First, and most notable among the limitations, is the inability to use conventional user-submitted data. If you wanted to define a webform and render those results into a views-generated table, that would be pretty straightforward in a conventional Drupal 8 site. In a Gatsby site, however, it would be much more complicated. Likewise, for many of the ‘nice to have’ out of the box things that Drupal gives us - authentication, custom user roles, and access restriction, etc. – they all need to be effectively re-engineered if we want to implement them on our Gatsby front-end. That said, we could certainly continue to do many of those things in Drupal, but in the emerging conventional patterns of using Gatsby and Drupal together, it is unclear what the ‘best practices’ method is for handling those use cases.
All in all...
I think it’s really interesting to see this attention and centralization on Gatsby as a defacto solution for decoupled Drupal sites. While there are plenty of limitations, Gatsby seems like an interesting solution for some of the characteristic decoupled problems that many decoupled Drupal devs are very familiar with by now.
And, as always, this year’s BADCamp was really great to get a chance to see the Hook 42 team – it’s amazing that we “see” each other so often online, but once we’re all together I’m reminded of what a smart, funny, and fun group of people we are. Can’t wait to see everyone again!