Gatsby is currently generating a ton of buzz as the new hot thing for generating static sites. This has lead to a number of frequent questions like:
Gatsby is a static site generator, intended to build all the HTML you need based on data you created. Presumably, that data was simpler to manage than straight HTML.
A static site generator probably doesn’t make sense if your site is truly static (e.g. a marketing site that gets updated twice a year.) Static site generators make more sense if you are building something that updates every 1-10 days, like a professional blog.
If you’ve ever used Jekyll, another static site generator, the basic concepts are similar: turn a folder of plain markdown files, or the like, into a complete site with just a bit of config.
But the limitations of Jekyll and other older generators are myriad:
Gatsby offers significant improvements in these areas since, along with bare-text files, Gatsby can import data from almost any data source and generate a clean React site based on the data it queries.
GraphQL offers a tantalizing dream: a system that can connect multiple data sources with a simple query language. Suddenly your hip NoSQL databases and creaky SQL databases can all be displayed through a single app.
But building and running GraphQL are not always simple, and fundamentally this new engine requires learning a new query structure. It’s cool to see that Gatsby is ‘powered by GraphQL’ but doesn’t that mean there will be some massive friction in getting this deployed?
But remember Gatsby generates a static site. It uses GraphQL to access DB’s and generate your site, but once that process is over, GraphQL doesn’t need to be running for your site to work.
Yeah, that part is inescapable. While many common setups have templates to start with, your team’s weird content database from 1997 is going to require some custom config. There’s no way this could be harder than importing the data yourself, and once it’s configured you only need to update your database and re-run the Gatsby build.
If it took a React expert to use Gatsby, it wouldn’t really have a market and that’s clearly not the case. Ultimately, if we could make awesome React sites from scratch, what use would there really be for Gatsby?
Fortunately, the tutorial for Gatsby is also a great way to gain knowledge of React in general. If you only use Gatsby for your first React app, a few things like auto-link formatting will seem like they’re core React tools when they’re really part of Gatsby. But that shouldn’t be a dealbreaker for anyone.
Having written zero React in the last year, I found my first few sites a cinch with Gatsby after spending a couple hours in their tutorials. If I can do it, anyone can—yes a logical fallacy on the SAT, but true here.
Here we get to the real potential of Gatsby: for our non-git-savvy team members, Gatsby can consume the database of another Content Management System (CMS), seamlessly importing articles with your main site. A CMS can present an input and editor for articles without taking responsibility for displaying the content it stores. Used this way it’s ineptly called a 'headless CMS'. The good news is, your content contributors can now publish content on their own, without needing to do a code push.
I’m not aware of any other static site generator that has this kind of functionality out of the box. Problems like scheduling posts ahead of time, editing posts (without needing to edit HTML) and content with multiple links and embedded files can all be handled by a tried-and-true editor like WordPress, while Gatsby generates a high-performance React app from the data. Gatsby is worth the plunge. Let me know how it goes for your team!