What do you need to start a Gatsby static site?
To start off building a Gatsby site, one should probably be familiar with JavaScript (its expressions and iterations of data) and its ES6 version. Of course, since you’ll be building a website you should also be comfortable writing HTML and CSS.
For managing and adding packages, you should probably also be familiar with a JavaScript package manager, such as npm or yarn.
Receiving content data requires an understanding of JSON (and its structure) as well as GraphQL and how it will query the data within Gatsby.
Of course, since this is a React framework, one would be wise to have a basic understanding of React components and their composition, and how properties work at the component level.
Tools Required
You’ll need Node.js installed along with npm or Yarn, and obviously your favorite code editor or IDE to compose and edit code. Here at Chromatic we tend to prefer Vim or VSCode.
How flexible is Gatsby?
Gatsby is an extremely flexible static site generator and is backed by a substantial and lively community. With more than 2,500 plugins (as of January 8, 2021) — providing everything from data sourcing, SEO optimization, responsive imagery, offline support, Sass support, TypeScript, sitemaps and RSS, Google Analytics, and so much more — Gatsby is one of the major leaders in the React framework arena. Even better news, if a specific plugin for your needs has yet to be created you can either create your own and connect it to Gatsby with REST API or be a superhero and offer code contributions.
Dealing with diverse data types
Gatsby-node.js (Node API) takes care of generating the pages on your site, allowing you to point to different sources of data and specify which templates they should print to. Out of the box, Gatsby expects content as markdown, but this can be set up to accept varying types of structured content data. Custom transformer plugins can be created to consume the incoming content (imagery and media, complex markup/styled content, etc.) if needed.
Usability
Since Gatsby is not a content generation/management system, it still requires the content to come from elsewhere. In other words, Gatsby is the glass — the head — of the decoupled/headless approach. When the content is ready for delivery, Gatsby can be set to trigger deployments whenever data changes. And now with Gatsby Cloud smart and efficient incremental builds are possible. When only a small portion of the data changes, only the corresponding portion in your Gatsby instance will be built and deployed.
Getting started is intuitive and made even easier with Gatsby Starters. These Starters are boilerplate project templates that allow you to avoid starting from scratch. Though Gatsby usually accepts starters via their code contributions process, at the moment submissions are paused while they work on a new workflow.
Investment
Since Gatsby is open source, there are no licensing or subscription costs. Relatively low effort maintenance means lower support requirements. Since Gatsby comes in two rendering flavors (server- and client-side), one could choose the cheaper method of static file hosting. Of course, this does not account for the origin of your site’s content if not within the Gatsby instance itself (e.g., headless CMS, content aggregator, etc.), so one must always keep the cost of hosting said content in mind (as with any similar React framework).
Resourcing
In addition, one must consider resourcing costs. Gatsby, like any new software, can have a steep learning curve and requires time to roll out (especially the larger a team gets). The good news here is that Gatsby isn’t the new kid on the block anymore. With many successful launches under Gatsby’s belt comes a bounty of developers willing and able to serve as specialists.
Time Investment
You may find that consuming already established and structured data from an outside source proves a bit more arduous with your Gatsby build, albeit not impossible. However, as you would expect, designing and structuring your data model alongside a Gatsby build will prove seamless. Effort will vary when it comes to building out components, but integrating a design system that is available to add as a dependency can greatly increase efficiency.
Security
Taking the client-side rendering route certainly means fewer points of penetration, and therefore less to fret over and maintain. It also means less server security worry as well. In addition, serving up static files can reduce server security worries because you’re not running code on the server. One can even set the build to clear its source content origin references thereby further increasing the security of content being delivered.
Downsides
Dynamic content — like views and the filtering of views — is hard to reproduce in Gatsby, though not impossible. There are ways to replicate this with API endpoints accessible via AJAX requests, but this veers into the higher echelons of granular React knowledge and will require maintaining server-side code. Search is not Gatsby’s forté — to the point that it just doesn’t come with it. If your site is small enough you may be able to build a JavaScript-based search feature, but that may not meet most project’s search needs. Again, this doesn’t make search impossible, it just means one will need to consider a third-party service for search functionality.
As with search, one will likely need to look to a third-party service when it comes to webforms (like contact forms). This is certainly the weakest of all the downsides considering that most sites are part of a set of platforms in which one is a CRM or parallel marketing service (wherein webforms originate). So, we take this downside with a grain of salt.
Don’t take our word for it…
Thankfully, you aren't limited to our experiences concerning GatsbyJS as Gatsby themselves have provided an easy to disseminate article to help you convince your team to add the framework to your toolbox.
