If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

The two GraphQL implementations I have worked with, on independent jobs, were a bunch of over-architected ****.

The amount of trouble they went through to actually use it far outweighed the benefits.

Assuming they were going to over-engineer, regardless, the very fact that they used a technology they had no way of ever understanding just made it impossible.

I don't want to use it, I don't need to use it, I don't consider it "great".

I was fairly sure we all are :) It’s seemingly found its part in the common web devs toolbelt. Perhaps not universally adopted, I believe it’s still regularly applied to systems with non-trivially large clients/fe-apps.

As a frontend person, the most common reason I've heard from the backend folks for not implementing is simply a lack of familiarity plus high difficulty, especially people who are used to existing AWS REST patterns and services. I heard from several people that making the stack for it on the backend is a pain compared to traditional REST, and every time I've brought it up, they decided it was too much work. (I took their word for it)

Similar vibes to "if JSON is so great, why haven't SAP and Salesforce rewritten their SOAP APIs?"

Huge companies are slow to adopt things. All the smaller companies I've worked for used GraphQL, but even then I didn't see the benefit over a regular REST-like API.

When you have performance issues with hand crafted REST API's, a GraphQL enabled set of API's feels like it could be a lot worse. Huge volumes of data for tables don't blend well with a mix-n-match way of joining things.

I find it to be more complex(Hence more error prone), less performant, harder to resolve bugs.

For a queries and mutations you still need to write business-logic and database access which is very similar to how you would develop a REST-API.

A lot of people use GraphQL. Like everything else, there's pros and cons. If you've invested highly into a certain tool you're going to see all of the pains.

Because REST works, and I just wanna get on with solving actual business problems that make money, NOT play around with GraphQL

GraphQL basically a layer that hides data federation from the client.

Graphql offers benefits for a few types of architecture (typically microservices or when you are supporting multiple clients such as Android/iOS clients). If you don't have these, then Graphql primarily adds complexity

In my opinion, graphql is a good detector of companies that want to be "cool" and thinks that they do software well as they follow dogmatically things like clean code. But that are not pragmatic and so they don't realize the bad side effects of it. Often early stage startups.

Graphql is a typical example of something that is nice on paper but doesn't pass the reality check.

There’s an inherent amount of complexity with two (or more) systems talking to each other over a network. You can shift the balance from one to the other, but it’s always there.

GraphQL pushes complexity into the backend where it’s arguably easier to manage, in return the frontend can have more flexibility and autonomy as a client.

REST pushes the complexity to the frontend requiring clients to orchestrate multiple calls, and reconcile the data models in the API to their own.

GraphQL got a lot of early praise for having good tooling that can provided end-to-end type safety, autogenerated client and server frameworks, and so on. OpenAPI has more or less caught up on this front now.

You can’t just take a REST api and convert it into a GraphQL api. Like going from dynamic to static types, with GraphQL it pays off to define your data model and reuse it throughout the API.

I’ve seen simple things like using the same field name, or same set of fields for a given type get bikeshedded for months. You can get with this for REST APIs, but not GraphQL.

GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it)

You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who use your API to write frontend clients.

GraphQL has its place, but IMHO it is at either side of the bell curve of project complexity. It will be great for trivial projects, and it can help simplify things in really complex large projects with multiple clients and services, but it just isn’t worth it for everything in between these two extremes.

Significant engineering time will need to be spent ironing out important things that just work with REST (like caching).

The best analogy I have for what working with GraphQL on the backend is like is the “If you give a mouse a cookie” story [1].

You try to set up an API but end up being asked to implement three different caching layers, using the data loader pattern to batch requests to the DB to improve performance, discovering that custom error handling code is needed to get non 200 status codes back from your API, using persisted queries now that your frontend is asking for a lot of data in the body of the request which is taking up too much bandwidth, etc…

The code as you can imagine after doing all this is very hard to follow, even without doing any of the optimizations I listed above there are things like reference resolvers that make tracking down bugs or just finding where the data is being collected from a nightmare.

[1]: https://en.m.wikipedia.org/wiki/If_You_Give_a_Mouse_a_Cookie