Choosing not to use the GraphQL feature of Gatsby – a bad idea?

[jamesplease]

👋 Hi there! Gatsby is very cool – thank you for creating and maintaining it! I just got started, and I am really enjoying using it so far.

This is more a question than a bug or feature request; I am trying to understand the downsides of choosing not to use the GraphQL feature of Gatsby.

I am familiar with GraphQL, and I think it is a great technology, so I have no qualms or questions about GraphQL itself. I am wondering more about GraphQL's role within Gatsby.

I read through this section of the documentation to try and learn more about it. After reading that, though, I was left thinking that I can do most of the GraphQL things without using GraphQL, so I am considering removing the GraphQL usage from my site.

The reason that I am considering this is because I want to encourage developers to contribute to my site, and I don't want GraphQL to increase the learning curve. I doubt that most developers are familiar with GraphQL. This belief is supported by the "How to learn GraphQL" section of that page that opens with:

Your experience developing with Gatsby might be the first time you’ve seen GraphQL!

For the general developer population, that seems likely, I think!

So my specific question is: what are the downsides to not using the GraphQL features of Gatsby?

With the Gatsby starter, the out-of-the-box query that you get is for getting some site metadata:

{
  site {
    siteMetadata {
      title
    }
  }
}

To accomplish this without GraphQL, it seems like you can just import the gatsby-config.js file, and use the data directly. Because the config file is a static JS object, I don't think that using GraphQL to pull in the data could be any more or less performant. Perhaps not, though?

The docs also describe:

GraphQL enables another unique feature of Gatsby — it lets you control data transformations with arguments to your queries.

This is definitely cool. Data transformation is really useful! But because we're writing React with JavaScript, transforming this data is already straightforward to do. Outside of Gatsby, I can't imagine that someone would reach for GraphQL to format a date or to render markdown.

The responsive image feature is nothing short of awesome, and this is one thing I would lose if I chose not to use the GraphQL feature within Gatsby (I think it could be reimplemented without GraphQL if someone really needed it, but I do not have that use case).

Anyway, I may be missing something super duper obvious (it wouldn't be the first time 😅), but if I were to build a site with Gatsby without using the GraphQL feature, are there other downsides aside from missing out on the responsive images?

Thanks for reading!

[m-allanson]

Hey @jamesplease, it's a good question!

As you've noted, you'll miss out on the responsive image features of the gatsby-image plugin. In general, skipping the GraphQL side of Gatsby locks you out of most of the Gatsby plugin ecosystem.

Normally you'd use source and transformer plugins to pull data into Gatsby, then GraphQL queries to pull it back out. If you're managing that data yourself you miss out on using plugins that also operate on that data.

For example, I believe gatsby-link's data prefetching relies on content existing as part of Gatsby's internal data structure.

If you're looking to encourage contributors then doing things 'the Gatsby way' means contributors can refer to Gatsby's documentation - there's a lot of it and it's constantly being improved. Going part Gatsby / part custom might make it harder for contributors to get started. Although this is likely to depend on your audience and the type of contributions you're expecting.

@KyleAMathews's recent tweet might be relevant too: https://twitter.com/kylemathews/status/985264186723680256

Let me know if that helps? :)

[jamesplease]

Thanks for taking the time to respond, @m-allanson ! It does help. I admit that I still don't completely understand why GraphQL specifically was chosen (transforms and plugins and things can just be JS functions, and that seems like a simpler alternative to me), but I can see how the ecosystem has been built around that decision.

I'll close this out for now – thanks again!

[KyleAMathews]

I admit that I still don't completely understand why GraphQL specifically was chosen (transforms and plugins and things can just be JS functions

I wanted a way for users to declaratively specify (aka write a query) for what data a page component needs as there's a ton of optimizations we can do because of this — and GraphQL is a perfect fit as it's widely used in the React world & has great tooling. Also GraphQL is much easier to learn and use IME than a custom JS query DSL. I taught a 2-day Gatsby workshop last week where most didn't know either React or GraphQL and people had far more trouble learning React than GraphQL. They opened Graphiql and played around a bit and were fine.

You might be interested in reading the original issue for adding the data layer + graphql #420

[jamesplease]

I taught a 2-day Gatsby workshop last week where most didn't know either React or GraphQL and people had far more trouble learning React than GraphQL. They opened Graphiql and played around a bit and were fine.

That is really cool, and good to know ✌️

You might be interested in reading the original issue for adding the data layer + graphql #420

Oh nice. I am definitely going to give that issue a read 👍

Thanks for sharing more background around this decision, @KyleAMathews !