GraphQL: The enterprise honeymoon is over

> The main problem GraphQL tries to solve is overfetching.

My issue with this article is that, as someone who is a GraphQL fan, that is far from what I see as its primary benefit, and so the rest of the article feels like a strawman to me.

TBH I see the biggest benefits of GraphQL are that it (a) forces a much tighter contract around endpoint and object definition with its type system, and (b) schema evolution is much easier than in other API tech.

For the first point, the entire ecosystem guarantees that when a server receives an input object, that object will conform to the type, and similarly, a client receiving a return object is guaranteed to conform to the endpoint response type. Coupled with custom scalar types (e.g. "phone number" types, "email address" types), this can eliminate a whole class of bugs and security issues. Yes, other API tech does something similar, but I find the guarantees are far less "guaranteed" and it's much easier to have errors slip through. Like GraphQL always prunes return objects to just the fields requested, which most other API tech doesn't do, and this can be a really nice security benefit.

When it comes to schema evolution, I've found that adding new fields and deprecating old ones, and especially that new clients only ever have to be concerned with the new fields, is a huge benefit. Again, other API tech allows you to do something like this, but it's much less standardized and requires a lot more work and cognitive load on both the server and client devs.

The author is missing the #1 benefit of GraphQL: the ability to compose (the data for) your UI from smaller parts.

This is not surprising: Apollo only recently added support for data masking and fragment colocation, but it has been a feature of Relay for eternity.

See https://www.youtube.com/watch?v=lhVGdErZuN4 for the benefits of this approach:

- you can make changes to subcomponents without worrying about affecting the behavior of any other subcomponent,

- the query is auto-generated based on the fragment, so you don't have to worry that removing a field (if you stop using it one subcomponent) will accidentally break another subcomponent

In the author's case, they (either) don't care about overfetching (i.e. they avoid removing fields from the GraphQL query), or they're at a scale where only a small number of engineers touch the codebase. (But imagine a shared component, like a user avatar. Imagine it stopped using the email field. How many BFFs would have to be modified to stop fetching the email field? And how much research must go into determining whether any other reachable subcomponent used that email field?)

If moving fast without overhead isn't a priority (or you're not at the scale where it is a problem), or you're not using a tool that leverages GraphQL to enable this speed, then indeed, GraphQL seems like a bad investment! Because it is!

> The main problem GraphQL tries to solve is overfetching.

this gets repeated over and over again, but if this your take on GraphQL you def shouldn't be using GraphQL, because overfetching is never such a big problem that would warrant using GraphQL.

In my mind, the main problem GraphQL tries to solve is the same "impedance mismatch" that ORMs try to solve. ORM's do this at the data level fetching level in the BE, while GraphQL does this in the client.

I also believe that using GraphQL without a compiler like Relay or some query/schema generation tooling is an anti-pattern. If you're not going to use a compiler/query generation tool, you probably won't get much out of GraphQL either.

In my opinion, GraphQL tooling never panned out enough to make GraphQL worthwhile. Hasura is very cool, but on the client side, there's not much going on... and now with AI programming you can just have your data layers generated bespoke for every application, so there's really no point to GraphQL anymore.

GQL was always one of those things that sound good on the surface but in practice it never delivers and the longer you're stuck with it the worse it gets. Majority of tech is actually like this. People constantly want to reinvent the wheel but in the end, a wheel is a wheel and it will never be anything else.

I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library.

The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not.

Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> ResultType"

In a REST API you might have

  app.GET("/user", getUser)
  app.POST("/user", createUser)

  {
    "getUser": getUser,
    "createUser": createUser,
  }

The arguments and output shape of your API routes are typed, like in OpenAPI/OData/gRPC.

That's all GraphQL is.

I have strong agreement here and would add reasoning about auth flow through nested resolvers is one of the biggest challenges because it adds so much mental overhead. The reason is that a resolver may be called through completely different contexts and you have to account for that

The complexity and time lost to thinking is just not worth it, especially once you ship your GarphQL app to production, you are locking down the request fields anyway (or you're keeping yourself open for more pain)

I even wrote a zero-dependency auth helpers package and that was not enough for me to keep at it

https://github.com/verdverm/graphql-autharoo

Like OP says, pretty much everything GraphQL can do, you can do better without GraphQL

This doesn’t really make sense. Obviously if you combine GQL with BFF/REST you’re gonna have annoying double-work —- you’re solving the same problem twice. GQL lets you structure your backend into semantic objects then have the frontend do whatever it wants without extra backend changes. Which lets frontend devs move way faster.

How do GraphQL based systems solve the problem of underlying database thrashing, hot shards, ballooning inner joins, and other standard database issues? What prevents a client from writing some adversarial-level cursed query that causes massive internal state buildup?

I’m not a database neckbeard but I’ve always been confused how GraphQL doesn’t require throwing all systems knowledge about databases out the window

What I liked about GraphQL was the fact that I only have to add a field in one place (where it belongs in the schema) and then any client can just query it. No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“. It just cuts that discussion short.

I also really liked that you can create a snapshot of the whole schema for integration test purposes, which makes it very easy to detect breaking changes in the API, e.g. if a nullable field becomes not-nullable.

But I also agree with lots of the points of the article. I guess I am just not super in love with REST. In my experience, REST APIs were often quite messy and inconsistent in comparison to GraphQL. But of course that’s only anecdotal evidence.

I would agree that REST beats GraphQL in most cases regarding complexity, development time, security, and maintainability if the backend and frontend are developed within the same organization.

However, I think GraphQL really shines when the backend and frontend are developed by different organizations.

I can only speak from my experience with Shopify's GraphQL APIs. From a client-side development perspective, being able to navigate and use the extensive and (admittedly sometimes over-)complex Shopify APIs through GraphQL schemas and having everything correctly typed on the client side is a godsend.

Just imagining offering the same amount of functionality for a multitude of clients through a REST API seems painful.

GraphQL was created to solve many different problems, not just overfetching.

These problemes at the time generally were: 1) Overfetching (yes) from the client from monolithic REST APIs, where you get the full response payload or nothing, even when you only want one field

2) The ability to define what to fetch from the CLIENT side, which is arguably much better since the client knows what it needs, the server does not until a client is actually implemented (so hard to fix with REST unless you hand-craft and manually update every single REST endpoint for every tiny feature in your app). As mobile devs were often enough not the same as backend devs at the time GraphQL was created, it made sense to empower frontend devs to define what to fetch themselves in the frontend code.

3) At the time GraphQL was invented, there was a hard pivot to NoSQL backends. A NoSQL backend typically represents things as Objects with edges between objects, not as tabular data. If your frontend language (JSON) is an object-with-nested-objects or objects-with-edges-between-objects, but your backend is tables-with-rows, there is a mismatch and a potentially expensive (at Facebook's scale) translation on the server side between the two. Modeling directly as Objects w/ relationships on the server side enables you to optimize for fetching from a NoSQL backend better.

4) GraphQL's edges/connections system (which I guess technically really belongs to Relay which optimizes really well for it) was built for infinitely-scrolling feed-style social media apps, because that's what it was optimized for (Facebook's original rewrite of their mobile apps from HTML5 to native iOS/Android coincided with the adoption of GraphQL for data fetching). Designing this type of API well is actually a hard problem and GraphQL nails it for infinitely scrolling feeds really well.

If you need traditional pagination (where you know the total row count and you want to paginate one page at a time) it's actually really annoying to use (and you should roll your own field definitions that take in page size and page number directly), but that's because it wasn't built for that.

5) The fragment system lets every UI component builder specify their own data needs, which can be merged together as one top-level query. This was important when you have hundreds of devs each making their own Facebook feed component types but you still want to ensure the app only fetches what it needs (in this regard Relay with its code generation is the best, Apollo is far behind)

There's many other optimizations we did on top of GraphQL such as sending the server query IDs instead of the full query body, etc, that really only mattered for low-end mobile network situations etc.

GraphQL is still an amazing example of good product infra API design. Its core API has hardly changed since day 1 and it is able to power pretty much any type of app.

The problems aren't with GraphQL, it's with your server infra serving GraphQL, which outside of Facebook/Meta I have yet to see anyone nail really well.

> GraphQL isn’t bad. It’s just niche. And you probably don’t need it.

> Especially if your architecture already solved the problem it was designed for.

What I need is to not want to fall over dead. REST makes me want to fall over dead.

> error handling is harder than it needs to be GraphQL error responses are… weird. > Simple errors are easier to reason about than elegant ones.

Is this a common sentiment? Looking at a garbled mash of linux or whatever tells me a lot more than "500 sorry"

I'm only trying out GraphQL for the first time right now cause I'm new with frontend stuff, but from life on the backend having a whole class of problems, where you can have the server and client agree on what to ask for and what you'll get, be compiled away is so nice. I don't actually know if there's something better than GraphQL for that, but I wish when people wrote blogs like this they'd fill them with more "try these things instead for that problem" than simply "this thing isn't as good as you think it is you probably don't need it".