Edit May 5th 2023: I have been working with GraphQL for two years now, and though I understand better some of the advantages, all the arguments below still apply for small teams with not a lot of time to dedicate to get the DX right.

---

Disclaimer: I am writing this as someone who work in an agency, with a lot of new projects every year, whose sizes are usually small to medium. If you are building a product or a platform, the trade-offs may be worth the hassle.

---

I never really understood the hype around GraphQL. Yes it is cool, it is shiny, and “the basic example looks sooo coooool”.

Still, I am convinced it introduces — most of the time — more problems than it solves.

---

Let’s talk about setup and bundles impact.

GraphQL clients like Apollo introduces a non-trivial amount of JavaScript in your pages. Because you don’t only need a client, you also need to install graphql itself, you need to add a query cache…

Let’s add more runtime costs due to graphql data parsing, your bigger bundles will probably not reach a ROI unless you pass a lot of data to the client (depends on your usecase).

Now that everything is setup, you want to type your queries (TypeScript fanboys*, assemble!). And of course, a string litteral can’t really infer its own type.

* I’m one of them

gql`{
  hero {
    name
  }
}` // -> { hero: { name: string; } } nah, not gonna work

But you really want types. So you need code generation. You also need to isolate this generated code and not commit it, to ensure your code generation is correct and is matching the data model of your GraphQL back-end (so you add another step to your build process).

And the Babel plugins for optimization. And the Webpack plugins for…

This is not to dismiss all the people that are doing a fantastic job building these tools, but to show that quickly, a problem that was supposed to be simple, is actually really hard to solve well. And the complexity it brings to a setup might not be worth it.

---

Let’s talk about smaller payloads.

GraphQL usually transfers less data than REST. Now, returning 10 fields instead of 2 is 99% of the time not a performance bottleneck.

Unless you are querying millions of results (and you’re going to face a whole lot of other problems), or your database table have hundreds of columns, you won’t see any benefits here.

Moving on.

---

Let’s talk about server-side rendering.

Framework like Next.js or Nuxt.js allow you to fetch data asynchronously for routes from methods like asyncData or getServerSideProps.

For SEO-critical applications/websites, taking React as an example, you may not be able to use the Query component as you cannot return 404s from render().

So you will have to use weird hacks to query data from these methods.

Example with Next.js:

SomePage.getInitialProps = async ({ apolloClient, token }) => {
  try {
    const { data } = await apolloClient.query({
      // whatever
    });

    if (!data) {
      res.sendStatus(404);
      // render the error page here (good luck)
    }

    return { data };
  } catch (e) {
    throw new Error(`no data blabla:\n${e}`);
  }
};

So the exact equivalent of doing a “vintage” request with fetch. So what’s the point if we can’t make use of all those advanced features?

---

You’ll still do REST anyway.

As soon as you will have to hit an external service (Google Maps, Algolia, …), there is a quite high probability it won’t provide a GraphQL interface. So you will be back implementing your usual fetch/axios/whatever setup.

Double the work, double the complexity. Double the code (ok, maybe not this one). But double the cognitive load for sure.

---

So what?

GraphQL is a tool created by Facebook, to solve Facebook problems (e.g: data-fetching at scale, bandwidth costs, etc).

You most probably are not facing the same issues as Facebook.

Now what is the cost of learning GraphQL, adding it to your stack, adapting your setup, adapting your back-end, keeping your favourite GraphQL client up-to-date, adding yet another point of failure, etc?

In the end, do the maths. It might be a good idea for your usecases, not really for mine.