After 6 years, I'm over GraphQL (opens in new tab)

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process.

With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want nothing to do with GraphQL anymore. Everything we attempted to fix our permissions issues just caused more problems. It would break existing queries and debugging GraphQL sucked so much.

If you only live on the frontend and someone else is responsible for the backend GraphQL then I understand why you might like it. From that perspective it's amazing, you can get as little or as much as you want with the specific fields you want. No waiting on the backend team to write an endpoint. However even then you end up saving queries as files or abstracting them (maybe IDE support has improved but it wasn't great last time I was using it ~5 years ago) and now you just have REST endpoints by another name.

At one point we considered whitelisting specific queries and that's when I knew we had gone too far and made a mess for ourselves. If we had taken the time to just write REST endpoints instead we would have gotten way more done and had way fewer grey hairs.

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article.

In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time debugging, this is true for any codebase.

But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of "learning-on-the-go" with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages).

Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere.

RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.

Aside from all the valid points listed in the blog I found out that the frontend engineers in my company save some queries in central library and reuse them even if they don't need all the field returned by this array just to save themselves the time they spend writing queries so they are basically using GraphQL as REST at the end and now we have the worst of both worlds.

Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me.

One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already 'vetted'", where you can look at things like complexity, ACL behavior, etc ahead of time. Since clients (in my experience) aren't usually modifying GQL queries at runtime, this is a pretty good tradeoff.

All that said, I find Buf Connect to be the best set of tradeoffs for most projects: strongly typed servers and clients, strong ecosystem support around protobuf (e.g. to generate an OpenAPI spec), a standard HTTP/JSON interface for easy curl et al compatibility, etc.

OpenAPI as the source of truth is annoying because it's too flexible, and it's rarely possible to generate type-safe servers + clients from an OpenAPI spec without running into one edge case or another.

GraphQL is the peanut butter to Reacts chocolate at FB.

It works there because

1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck?

2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want.

3. everything at FB is some sort of blended context (my user, someone else's user, a permissions interaction)... security is baked in to every field.

4. Because of permissions, and login requirement it's hard to be a bad actor (FB just locks you out, nothing is public).

If you have a SPA and logged in user requirement and that robust permissions model then GraphQL might make sense... Otherwise its a shining example of conways law and might not be fit for your org... The same can be said for react too.

Kudos to the author for reevaluating his opinion and changing heart on a technology he admits to have championed before.

IMO GraphQL is a technological dead end in much the same way as Mongo is.

They were both conceived to solve a perceived problem with tools widely adopted at the time, but ended up with something which is even worse, while the tools they were trying to replace rapidly matured and improved.

Today OpenAPI REST and Postgres are rightfully considered as the defaults, you even have PostgREST combining them, while most of those who adopted Mongo or GraphQL have either long migrated or are stuck discussing migrations.

I must be the only one who found GraphQL, used it in a small project, and liked almost every bit of it. I used Apollo Client and graphql-codegen to generate types and functions for Vue 3, and nothing else could touch it. It wasn't all smooth sailing of course: I did find defining new scalar types to be fiddly, and I couldn't really even make proper use of union types, directives, or even enums due to the impedance mismatch of Apollo Client (JS) and API Platform (PHP). The latter had a lot of nice features in implementing the API backend itself, but the poor documentation for its graphql support held me back. But even the super-basic graphql subset I did use caught a great many errors at the type level where other solutions would not have.

These days, given the freedom to write the backend in TS too, I might look into tRPC instead. One thing's for sure, I won't be going back to OpenAPI unless and until I can fully autogenerate api.yaml and otherwise never have to touch it again (getting there with zod+openapi on another project, but it's nowhere near as easy as graphql-codegen doing all the things with one introspection query).

I’m the founder of Hasura - sharing some notes from how I’ve seen GraphQL usage evolve over the last few years.

1. GraphQL was and remains insanely hard to build without an underlying data layer that does the heavy lifting. Without projection push-down, predicate push-down, a data layer that can support heavy parallelism it’s untenable. Exactly the problems the OP highlights - needing to “hoist”…

2. GraphQL on REST is an anti-pattern. The hype takes you there, but the juice is not worth the squeeze. The problem was lack of types? Add openapi. The problem was custom aggregation endpoints? Make it super easy / cheap to build aggregate endpoints in REST. Use an AI copilot to write an aggregate REST endpoint and a openapi schema for it even. But maybe the last thing to do is to build annd mainatian another API layer with a completely different execution model.

It’s not what it was meant for perhaps, but GraphQL’s killer use-case is an API to access / operate on data. Especially when there are multiple consumers of data (services, apps) and they don’t own the underlying data sources or speak the underlying language of the database. This turns out to be the underlying problem behind a lot of api, data modernization / migration / decomposition efforts.

The cost of this approach is implementing Graphql by building a compiler/planner with a robust authz system baked into it. A resolver based approach can never cut it, unless you resolve a query plan - aka build a compiler.

If you want to use graphql to just batch rest endpoints, it’s very likely going to become legacy tech as soon as the team that built it starts to move on.

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits:

- If data already exists in cache, a query will return that data instead of making a network request.

- Everything that has a data dependency on something in the cache will automatically update when the data is updated, e.g. after a mutation.

- Cache data can be optimistically updated before the request completes, UI that queries this data will automatically update.

- Components will automatically refetch data if they need to, e.g. if an object is partially updated.

The pain points are pretty painful though:

- Really hard to debug unexpected refetches.

- Normalizing the data for the cache comes at a cost, it can be pretty slow for big responses.

- You quickly realise you need to really understand how the client works under the hood to be productive with debugging/complex behaviour.

I see it as a case of "this is the worst API/client, except for all the others". I'm curious to hear how people using non-graphql APIs are managing data in the client in web-apps with complex data needs?

[1] https://www.apollographql.com/docs/react/why-apollo [2] https://relay.dev/

Additional graph pain points I'd add:

Reliability:

* Not null fields in a distributed system are a lie. Clients write code assuming something is not null, so a query that fetches data from N sub systems breaks the entire page when one of them fails.

Performance:

* People say you only need to fetch just what the page wants but in practice clients create re-usable fragments for every object in the system and use it everywhere. Any time a new field is added, every api call fetches that new field adding latency everywhere

* clients are unaware of the underlying topology and add fields that are usually harmless but have bad tail latencies.

* The completely generic nature of the API means the backend can't optimize performance for a specific page. E.g. if one API has nasty tails, but it's not that important for this page, the backend could time it out at some reasonable value instead of holding up the entire request

I never understood peoples positions that GraphQL all of the sudden the frontend can make any Query it wants and control is out of the hands of the backend. That seems orthogonal to my experiences with GraphQL.

GraphQL is a protocol and you define the implementation. Some GraphQL implementations like REST implementations try to generate everything for you. That is not "GraphQL" but one type.

GraphQL is way to query nested APIS. The dataloading N+1 Problems are substantially easier to solve in GraphQL and many frameworks have solutions auto-optimize ORM queries for example.

The backend defines the query, the frontend requests it. Simple. Never understood the hate against GQL that now the frontend has all this power. They have exactly as much power as you would have exposed in a Rest Interface just now the backend can actually see all the data it needs at once and optimize.

If you are worried about a cartesian product from a GraphQL call I have news for you about production REST systems. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think.

REST encourages resource waste. You are getting fields you don't need. Hard to query related objects, etc.

Benefits I have reaped with GraphQL:

  1. API analysis - I can statically analyze a typescript program and verify their API calls are valid against backend schema.
  2. Usage analysis - Statically analyzing the schema I can see which fields are still in use and safely refactor.
  3. Frontend Velocity - The frontend can cange its data needs on the frontend query whatever related objects it needs efficiently without backend changes. You can get all data for a page with 1 call and not have to have page specific endpoints.
  4. Less backend engineers are needed as API changes less.
  5. N+1 Optimization much easier to solve in GraphQL then REST

There are so many advantages to using GraphQL. The only advantage of REST I can think of is for static external APIs.

Worked with GraphQL from 2017 to 2021. It was the last tech "hype" I bought into. At first, it made a lot of sense and the thing that got me was the structure. But eventually, I realized how much extra work and duplication of everything there was. At the time, too, things that should have been easy like subscriptions had a nightmare API packed with weird terminology that made implementing simple features a slog.

The one positive to come out of working with it (aside from knowing how to spot a tech black hole) is that it informed the design of the API layer in my framework [1][2]. I realized the sweet spot is starting with a basic JSON-RPC type endpoint and then layering things like input validation [3], authorization [4], and selective output [5] (only requesting certain fields back) on as you need them.

[1] https://docs.cheatcode.co/joystick/node/app/api/getters

[2] https://docs.cheatcode.co/joystick/node/app/api/setters

[3] https://docs.cheatcode.co/joystick/node/app/api/validating-i...

[4] https://docs.cheatcode.co/joystick/node/app/api/authorizatio...

[5] https://docs.cheatcode.co/joystick/ui/api/get (see output array in the function options API)

when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems.

There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firms etc. Some just use REST + JSON or RPC + JSON.

Wish us an industry would read Joel's Spolsky's Fire and Motion article: While you're fighting tools built by FB you're not making stuff for your customers.

Revenue / Profit >> Tech

I never got into GraphQL. It always felt like a lot of complexity for little gain (I'm full-stack). People always jump on tools created by tech giants but they solve different problems than the vast majority of companies.

“the main thing your frontend devs like about GraphQL is its self documenting type safe nature”

I’ve been saying this for years: fetching multiple things in one query is not something normal-scale apps care about. What devs like about it is client generation and type safety. So OpenAPI, for all its flaws, covers that. GraphQL’s schema language is much more beautiful — hopefully Microsoft’s TypeSpec will take off and we can have the best of both worlds.

https://typespec.io/

Another point implicit in the piece but not quite stated is that GraphQL aims to make something nice for the API consumer, but the implementation side is a nightmare. It is not worth the tradeoff because eventually, that nightmare leaks out to the consumer because it is too hard to make improvements to the API.

I generally agree and am likewise "over" GraphQL. Having said that, I disagree on some of the finer points.

First, some of these issues--authorization, security, N+1--can be mitigated by using something like Prisma, PostGraphile, or Hasura, instead of crafting GraphQL backends with code.

Second, there are gains to be made by compiling a GraphQL operation to a single operation in the underlying database's query language (e.g. SQL)--when that's possible--rather than by following the "resolver and data-loader" catechism.

Third, as I've written elsewhere recently, I think the N+1 problem is overblown. Not that it doesn't exist, but just that it only sometimes exists and usually isn't as bad as is often claimed. But again, this is eliminated by switching to a compiler approach anyway, so it's not worth making a federal case over it.

Despite all this, like I said I'm still over GraphQL. If you must implement it, try to use one of the tools mentioned above if you can.

One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar.

Same problem with Prisma Model definitions and other such things.

Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and programming concepts in order to generate, parse and make sense of your thing. Let me seamlessly write your language with the data structures I already know in my language if that's possible.

Don't make it pretty, make it usable.

Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL.

Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps:

1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has;

2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data.

3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data.

Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other.

The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak.

How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.

Working with GraphQL over 6 years, I have seen (and created) many mistakes mentioned in the article. GraphQL is not great but it has worked well for me, you just need to adapt & change mindset to create better interface for your graphQL endpoint.

For example, having nested queries more than 2 levels is a no go for me (just like having nested inheritance is basically anti pattern)

Focus more on your interface. One way to avoid N+1 and nested query is to required parameter for related fields. For example

```

user(id: $userId) { {

  id

  friends {

    id

    ...

  }

```

to

```

user(id: $userId) {

  id

  friends(id: $userId) {

    id

    ...

  }

```

GraphQL was the shiny new thing that everyone was excited about and I was also trying to learn and use it too, but I've never found a compelling use-case to use it over REST API. Now that you shared your experiences with it, it give me more reason to stay away from it. Plus, I think it's more productive to stay with the stack I'm very fluent at.

I agree with the article, and want to add on that the browser network debugging tools are a pain to use with GraphQL (every request to /api/graphql, can't even quickly filter by endpoint name). I landed instead on OpenAPI, which can feel like a bit of a hoop to jump through sometimes when writing endpoints (but then, so can GraphQL), but the result is equally nice. And it's much easier to get authorization right with REST APIs.

I wonder if GraphQL would have been as popular if it was a much smaller shop than facebook launching it. Feels like having a name like FB gets you a tech credibility pass.

I've come to believe that the "right" way to do things now is alternating smart / dumb layers.

If you have two smart layers adjacent to each other (and GraphQL is a smart layer) then the interconnection between the two and the conflicting abstractions of data becomes an issue.

By having something dumb (REST endpoints) between the business layer and the complexity of the front end, it is possible to have reasonable abstractions writing to the REST endpoints and an abstraction of the payloads that the endpoints provide into what is needed in the front end application.

It seems that GraphQL works best when the backend has minimal business logic and the thing that is calling GraphQL likewise has minimal logic -- and all the logic is contained in the GraphQL query itself.

But if you're finding complexity in getting things into GraphQL and manage permissions and mutations... or you've got the complexity of the front end where the data model the front end needs to work with doesn't align with the GraphQL model ... then you've got complex solutions abutting each other and those spots is where the pain will be found.

>GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018.

6 years. For a lot of people, that was also the time ( 2013 - 2019 ) they moved from SPA or Client Side Rendering and started looking or move back to HTML+ approach.

So may be for any company operating on Boring Technology principle, you should not choose any hyped tech until they have been battle tested by the market for 7 years.

GraphQL always felt to me like it solved the easy part of the problem and offered nothing to solve the hard part. I have a similar response to things like Zanzibar. At the end of the day I want to go and get some stuff out of a database, and that complexity just ends up dominating everything.

Ah, this is the advantage I have waiting at least 10 years of everyone I care about whining I need to use a technology. I had a few years of people telling me about graphql and how it is the best etc, but they stopped after a bit and are doing rest endpoints again. So I never tried it even.

I've run into all of these issues running a GraphQL API and, while they aren't easy, they aren't exactly intractable either. Let's not pretend that OpenAPI/REST or Protobuf are perfect alternatives. They've each got their warts and tradeoffs.

The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you may still have to reason about graph-like structures but without the benefit of a graph-like schema.

GraphQL is a great choice for internal applications hidden behind strong authentication that do not need to be heavily cached and where things like DoS are less of a concern or no concern at all.

It is often a poor choice for websites that should be cached, are publicly accessible and have simple and predictable data access patterns.

GraphQL has a fairly flat but very long learning curve which makes it a power tool that is great for those who have learned it in depth. Without that experience one is almost always better off using REST.

For the service I primarily work on, we've stuck firmly with REST for our internal APIs despite some mild pressure from elsewhere in the company to move to GraphQL. I personally believe it's been the right choice. Not only would it be probably an order of magnitude more complicated to setup and maintain, our REST APIs already are very performant.

We've got little to gain, and the lack of flexibility from our POV is a relatively good thing. It gives us direct insight into desired use cases, and since the APIs are internal it lets us provide guidance on potentially better ways of implementing things as well as in some cases being able to provide direct optimizations for specific tasks.

GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api as a whole quite annoying.

I do really like the Api definition part of it though - but I found something like typespec now to be the perfect middle-ground, it allows out you describe your apis similar to a graphql Api without enforcing the graphql engine on you though.

I still love GraphQL, but much of the love comes from using tools like PostGraphile which generates the API for you based on your database schema. I then add my own Javascript plugins as necessary. Going back to REST and hand writing everything gives me the shivers, how much time am I spending just translating data A to data B?

Authorization: I do it in the database using roles, row level security and column level security. It works well and I defer everything to PostgreSQL's security controls, it feels like the right place to do it and I don't have to worry about it going out of fashion, PostgreSQL is here to stay. Anybody else who talks to the database directly is also subject to the same authorization rules, which is nice.

Introspection: this should really be disabled on production services. Only enable it for development.

N+1 problem: I don't really have a problem with N+1 because PostGraphile converts the request into an efficient query. In other cases this problem presents itself in REST too and the article proposes hoisting N+1 queries to the controller, but that's just really moving the problem around, and you can do this with GraphQL too.

The other problems, yeah sure they are present and a worry if you're running some highly visible/very loaded public API.

many of these concerns are mitigated by ensuring you are using trusted documents (https://benjie.dev/graphql/trusted-documents)

I’ve found success just using GraphQL internally (with tools like Hasura or Postgraphile + row level security done strategically) and not exposing it directly externally. That way you can trust the clients and it unblocks frontend devs to accomplish what they need.

I worked on two projects using GraphQL and don't want to do it again. Both times the backend was a mess and the "design" or the lack thereof had all the signs of being written by "evangelists" who got bored or got fired leaving the new arrivals to sort out the mess. I'm sure GraphQL is the right fit for some problem domains, but most of the problems I deal with are happily solved with the help of a REST API.

I worked on a GraphQL API a few years ago and we solved these problems at the beginning and then forgot about them. We generated the schema for a user from their CanCan abilities (CanCan can handle attribute-level access, I wrote the PR). Shopify has support gems for the N+1 stuff, if I remember correctly. You can limit how many levels deep your query can go. We added some rate limiting.

Basically, these are all solved problems.

I only have one experience with a client using GraphQL and it was horrendous.

My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that I didn't know about and then I had to constantly ask them for the fields because I thought I was missing data. If I could have just queried ALL the fields, then saw what came in, and chop them down to what I need.. great.

The only way GraphQL seems to make any sense is if everything is basically completely defined and you are at a final project stage. After many many years of experience... this is rarely the case.

Cool piece of technology? Sure.. but hardly practical except in scenarios of extreme amounts of data and only when it makes sense for the client to return specific fields.

Although I think still for 95% of even those extreme cases, you just write a REST endpoint that returns the fields that make sense for the query....

I like restful API’s the most. Graphql is cool if you need data combined that is not nicely available in the restful endpoints. But I think that could mostly be solved with good endpoints that help with the actual use cases. When restful endpoints are hard to use, in a lot of cases it is because they are to much focused on how it is easy to write server side, then it is to consume them.

I've had the "pleasure" (/s) of inheriting a pretty large GraphQL API which I've had to maintain for the past few years. I've gone through the process of the hype, and then the sheer frustration. I'm now at the point where I think most people are just using it in the wrong places.

GraphQL works pretty well when it's acting as a Backend-For-Frontend. The client can make a single call to get everything it needs at once, the BFF can then fan out to various microservices as needed. The frustrating part is when it's blindly used for something like a monolithic CRUD API with some light permissions. In that scenario you're taking all of the drawbacks, without reaping any of the benefits.

I'm really glad to be leaving this project behind as I move jobs, and I'm praying no one suggests using it in my new job. At least not until the industry more broadly understands it in more depth.

I think GraphQL works its best magic when you are building your own unified data access layer for a backend. Your individual services can be backed by Postgres or Mongo or an in memory database, whatever, doesn’t matter. And from there a backend queries that, translates the data into a RESTful one, and passes it along to a front end Backends-for-Frontend style.

In this way services get freedom to define their stack while still neatly fitting into the suite of services, products get a tidy interface from which to query everything, and because the GraphQL consumer is more akin to a regular database consumer, the database muscle memory kicks back in.

I’ve also grown to prefer bespoke backends for each client over a super backend that tries to anticipate all of the needs of all the clients. It just opens too many holes and what it buys in versatility for the client author it also gives to the exploit author.

Fully agree with the article. I think the summary is that GraphQL was a great idea from the frontend's perspective, but it was never fully worked out from a backend's standpoint.

Exposing bare GraphQL the right way can be challenging, totally agree with author on that. Using it on a small project also can be an overkill.

But at the same time it doesn’t have to be that bad. I don’t have this array of issues because I do: - query whitelisting for performance and security, - data loading to avoid n+1, authentication with whatever works(session cookies, tokens), - permission check based on the auth context in a resolver.

It works decently for us, allowing to stay away from getting into ESB. Yet have some shared domain, type safety, and easy integration of legacy and new systems/services.

I would say a bigger issue for us was to keep it all nicely organized / designed in terms of types and api contracts. But that’s manageable.

Fine article describing the weak points of GrahQL. I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs.

I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had we gone with more powerful standards like API blueprint (or maybe raml).

Case in point, I'm consulting an org with roughly 1k engineers right now on improving their API ecosystem and what we are seeing is that the more OpenAPI tooling they use, the worse the DX gets...

There was a very short window of time when you could make very advanced queries over your Facebook friends graph. It was awesome.

I will, once again, bring your attention to hashql, which is so pleasant to use. It's so minimal that it is almost more a pattern than a library. Try it out as an alternative to graphql if you are mainly querying a SQL database anyhow (although it can be easily configured to request data from other types of sources.) I don't think it can currently combine results from multiple data sources, but I think it should be within the realm of possible things

https://github.com/porsager/HashQL

I still enjoy using GraphQL, because it has allowed my teams to move measurably faster when developing APIs over the last half-decade. Some organizations seem fairly allergic to full stack development, but it has broken that barrier in ways I hadn’t witnessed before at my workplace.

However, lately I’ve been thinking that with the advent of React Server Components we will see a migration away from GraphQL-focused Frontend applications, and instead move toward other solutions. Such as ones based purely on exposing Postgres databases (e.g. supabase & postgREST) and type safe APIs (e.g. tRPC).

I heard the argument that it's good because you don't need the server devs to change the backend; you can specify the data you want. As echo'd before, I guess that's great if your frontend and backend can't be developed in sync. Overall, I'd rather improve the development synchronisation/modification problem between backend and frontend than drive the GraphQL tank through the codebase. I guess I'll need to wait another 6 years before I can avoid GraphQL. Marketing-driven fads: exciting at the start of my career, a painful chore now

As much as I opposed GeaphQL at first I found a use case for it and have been using it successfully for past 4 years. In my application GraphQL is just a layer on top of GRPC API. It helps to fetch data across different services and glue together different entities in one frontend friendly payload. Since GraphQL is essentially a proxy in front of GRPC (which is the real API, exposed over REST endpoints as an alternative to GraphQL) I haven't suffered from most of the issues described by author.

Authorization is performed by GRPC which returns only fields available to the user, rate limiting is performed on GRPC requests so at some point your data will start coming partially if you make too many queries or query that is too complex, N+1 problem is still there, but in a distributed system it's there even without GraphQL, the mitigation is caching in GraphQL server on GRPC request level.

In my experience GeaphQL really helped decouple frontend and backend and I'm pretty happy about it.

Besides GraphQL offers some standard way of making server side event streaming, it's not supported that well, but at least it's more comprehensive than bare web sockets.

I never got around to implement mutations though, individual change requests via REST are enough.

A lot of the points in the articles are issues anywhere, it just depends on how well they are understood in the context and how mature the tooling is. Eg: rate limiting in REST is rarely problematic because we have no end of WAFs and gateways and circuit breaker libraries that understand REST very well.

It's very true that a few years ago the gap was there, and people implementing GQL had to solve all these problems without access to these mature solutions.

But these days, they're mostly solved problems. Authorization by type that propagate through the graph is pretty simple. Rate limiting and complexity limits on queries is often built in the frameworks. Query parsing is solved with persisted query all the major frameworks have as first class citizen. Performance: lots of GQL caching solutions out there, and the "multi threaded by default" model used by most frameworks helps a lot.

Etc etc etc.

I jumped companies a lot, did both. For a while I too thought GQL was redundant, then went back to a more classic world after a successful GQL implementation. I had forgotten how many problems were solved, especially organizational and people communication issues, through GQL. And so we're moving to GQL again.

Someone in the comment mentioned GQL is a tech solution for an organizational problem. I'll say most good software tooling and frameworks ARE tech solutions for org problem, because technology is usually a solution to people problem. GQL is the peek of that, and it does it quite well. Don't use GQL to solve tech problems, there's better tools for those.

For some reason every person I have worked with that pushed GraphQL seemed sufficiently obsessed with the idea of it that they prioritized its perceived elegance over the product we were trying to build.

In other words, they cared more about ideal ways to access data than the product of that data.

This has so consistently been the case in my personal experiences that I avoid people in hiring interviews that start talking about or try to sell me on why I should switch my stack to GraphQL.

The consensus I get from these comments is GraphQL is ultimately a failure as a REST API alternative. It’s useful for very specific cases that most companies don’t have.

If someone from Shopify's backend team is around, i would love to know how difficult it is to maintain/improve the GraphQL API It looks like Shopify is deprecating REST in favor of GraphQl so is the developer UX that good for Shopify developers? And btw some features are missing from the GraphQL related to REST. I wonder if that's related to hard-to-implement features or good-occasion-to-delete features (Eg Checkout)

This is a great write-up. I was already aware of most of the drawbacks that the author wrote about in the early days of GraphQL... Another category of solutions which was ignored completely is CRUD with field-granularity over WebSockets.

I've built platform which does just that: https://saasufy.com/

This approach has allowed me to create a library of highly generic components which can be composed into surprisingly complex front ends and where all data updates in real time (in a targeted, efficient and scalable way): https://github.com/Saasufy/saasufy-components?tab=readme-ov-...

You can build just about any front end you can imagine just by assembling these components. Almost no code needed. It takes me hours to build web applications which would take weeks or months to build. The real time update features come free. The dev experience is essentially bug free; any 'bugs' you may encounter have clear visual symptoms which can be 'debugged' by observing the HTML DOM.

I'm currently observing people getting hyped up over HTMX and it's kind of funny to realize that developers do actually like the declarative approach... And yet they're going in the wrong direction again. Just as they did with GraphQL.

It would have been impossible to do this with GraphQL because field-granularity/autonomy is essential. GraphQL queries combine different resources and fields together in complex ways and this makes it impossible to efficiently avoid real time update conflicts on the front end.

I used it at a past place (didn't choose it) and IDK, it just seemed like one more layer that wasn't really buying us much. Wasn't a fan.

Whenever you see REST in the article, think RPC. The author even says REST is simpler than GraphQL but I suspect they hadn’t implemented a REST API… ever.

I remember about nearly 6 years ago gql showing up in job postings, I scratched my head a bit because it was so new. And also just a QL, why hire based on it? Shouldn’t you pick techs easy to use AND LEARN. Thereby nullifying must-have-experiences

Perhaps now it might be;

Nice to haves: Enough experience with GraphQL to never suggest nor implement it.

These are the kind of experiences I think which truly matter.

We tried GraphQL for about a year, then switched back to REST, but took the important bits with us: a published API contract (an OpenAPI spec), and code-gen'ed Swift from that spec.

Looking back, it is hard to believe I spent a decade working in shops with no published spec, no code-gen. So many ugly surprises discovered in production, all of which were avoidable. Never again.

95% of this is specific to Ruby, not GraphQL. I also found ruby-graphql not to be a excellent library in contrast to what the author says. Other implementations (apollo for node, gqlgen for Go) alleviate many of the concerns mentioned in the article, especially when implementing the server with certain principles in mind (always use the data loader pattern, etc).

Except, the alternatives he presents aren't alternatives.

And for each issue he mentions that rest doesn't have said issue is basically because rest doesn't have the feature at all.

You could use graphql the same way as rest (by exposing queries without allowing to specify fields) and you still have a better rest, since at least the response has a schema out of the box.

Folks on this thread should check out Isograph: https://isograph.dev and https://www.youtube.com/watch?v=gO65JJRqjuc.

GraphQL has a lot of advantages, the most important of which is data masking. In a properly structured GraphQL app, only the function that requested a field (i.e. included it in a fragment) sees that field. This allows many developers to move independently, without communication or coordination.

It's unfortunate, but there are lots of rough edges with GraphQL and it is hard to incrementally adopt, and so if you don't have enough developers (to have communication issues) and a team devoted to adoption, it might not be worth it.

Anyway, Isograph is a framework that seeks to take away many of those rough edges, while baking in stuff like data masking, etc. Y'all should check it out!

I think the only reasonable way to use GraphQL on a freely accessible server is to only allow a set of whitelisted queries, ideally automatically extracted from the frontend codebase, stored on the server and invoked by id and arguments.

This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL API rather than knowledge of the whole backend architecture, which is generally useful if the backend and frontend are written by different people or teams.

That's the way Facebook uses it on their main website: they pass the query id in the "doc_id" form field, the arguement in the "variables" field, the server gets the actual GraphQL query based on the doc_id from some sort of internal dictionary and AFAIK no GraphQL query string ever goes on the wire in production.

I admire the 6 year dedication (or architectural investment?). We were both jumping aboard that hype train in 2018, even talked about it in meat-space. I left that project in 2019 and never looked at GraphQL again, so didn’t make it as far you to the technical depths.

Something just never felt right about the client building the queries for me, I guess.

For web apps (not simple pages), developed by a single full-stack developer, I think the best solution currently is to use Remix's loaders + actions (i.e. no need to create separate API layer) with EdgeDB (EdgeQL is like GraphQL but with capabilities of SQL, and the DB itself has authn+authz baked-in).

And with spec first and OpenAPI Spec we are back to the methods and tools, that we hadwith WSDL/XSD and SOAP/XML like 20 years ago. We went full circle. :) I love IT

The problems with GraphQL where so obivious in the first 5 minutes that I looked into that. Looks smart and flexible - but isn't

In my younger days, I always felt pressured to use ProductX especially when it is praised and/or considered the next big thing. You can refer to javascript frameworks, libraries, even "cool, new" programming language.

I remember working on a Rest API and thinking about (things like) GraphQL... the typical "would it make life easier" and all that.

In the end, as the years have passed, I just stick to the minimum. If there is a tried-and-tested library or something.. I use it. When there is something new, I question it.

Never tried GraphQL. It looks like it can improve my data on one end, but cumbersome when it is hard to reason the data, or get generally complicated, which this article demonstrates.

Fundamentally, GraphQL is a _query language_, but people keep trying to build/use it as an _API_.

If only developers/managers had their own sense of using the proper tools for the job instead of just swallowing everything the Big Tech shoves down their throat...

But when you see those job ads with all these "great new technologies" it's hard not to fall into the trap.

> Tab Grouping, Vertical Tabs, and our handy Sidebar will help you stay organized no matter how many tabs you have open — whether it’s 7 or 7,500.

Not sure if this will be good. This reads like they will add Vertical Tabs as a Sidebar, like all the other vertical tab-addons doing it now. But since the Quantum-update there is demand for a second sidebar dedicated for tabs, because as it's now, sidebar is really annoying to use.

But maybe it will at least add some improvements which the other addons can built upon.

> More streamlined menus that reduce visual clutter and prioritize top user actions so you can get to the important things quicker.

Oh gosh, no! Why make them even worse than they are already now?

Never bothered to learn GraphQL - anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects.

Stick to tried and true - monolith, asp.net, angular or blazor front-end, relational database.

I have never bought the GraphQL hype, but have never explained my rationale as well as this article does. Kudos Matt on succinctly nailing the issues here.

As for how to tackle things today, I alternate between REST+OpenAPI and RPC models for communication. I am certainly biased as I have my own typed open source RPC library (Conduit) which is layered on top of arbitrary message passing transports such as WebSockets, but as of yet it's only suited for Typescript-based clients -- REST+OpenAPI is a better fit for an API with many consumers.

But for dynamic client/server and client/client single-implementor communication needs, I go with RPC.

Back in 2021, I asked one of our devs who badly wanted GraphQL for his resume (this dev left in 6 months) to address the following issues:

- GraphQL performance issues

- GraphQL makes tasks more complex

- GraphQL schemas confuse junior devs, higher entry level

- REST cache easier

- REST if you understand what you are doing ... can do the same

- REST is better for error handling and tooling

Now in 2024, I clearly see LLMs gives much better autocomplete for REST or SDK code generated with protobuf ecosystem

There is not enough code repos based on GraphQL for LLMs to reason.

If you have like minded people who loves GraphQL, nothing can stop them but at higher and broader level it's a huge risk for dev velocity (like anything else if you dont know what you are doing)

GraphQL is a great way for FE devs to make life harder for BE devs.

The entire point is composition + client customization of the response body, but in practice the request schema is never modified. And even if it were, you could just version a REST endpoint.

GraphQL is never done "correctly," adds a layer of obscurity to monitoring and error tracing, and I've yet to see a case where it's actually the right tool for the job.

Maybe if you need to aggregate calls to multiple services into one, but if you're trying to avoid latency by reducing number of calls, you still eat that latency while the GraphQL server makes those calls for you.

GraphQL sucks.

Full blown GraphQL is hard to properly support. It needs a lot of developer time to get everything correct, as stated in the article.

However, you can go very far with a simpler version of it, just by allowing clients to specify what fields/relations they want and in what context.

I'm using a library that I've created for myself for years without any of the problems mentioned in the article.

The client side queries are generated by the server at compile time. Each request for an object requires a "segment" to be specified. On the server, each segment has the necessary filters/limits automatically applied to prevent data leaks.

GraphQL is an opaque layer that is not necessary in the truest sense.

The lie is that it makes things better. 100% of the time that I add an unnecessary thing to a project in the name of "it will make things better", it never did.

It's the old new-shiny, so here we are lathering on our dislike, which I feel is totally normal and expected. There's a new new-shiny around somewhere and a few years from now, I'll see articles like this one about it.

Having not yet read the comments, I plan to enjoy them thoroughly, I love a good hate-post about software I myself don't like. :)

If anyone is reading this and is using Django there is a smooth transition to drf-flex-fields. The package gives GraphQL-like features while using REST.

- https://github.com/rsinger86/drf-flex-fields

- https://django.wtf/blog/graphql-like-features-in-django-rest...

I have another one for you. GraphQL should never be used as a way to "GET-modify-PUT" records, but often is, because why reinvent GET if you already have GraphQL? Because the query specifies the fields, so if new fields are added to existing types, existing clients don't receive them and PUT the record back without those fields. You now have to try to deal with this in the backend, with subtle and severe edge cases potentially affecting the backend and all of its clients.

For something like OpenAPI+JSON REST API, does anyone have recommendations on tooling that would make my life easier?

I am also over GraphQL but I really like the api explorers, code completion, type safety, etc.

We just need a tool to let every REST/rpc endpoint gain the ability of 'resolve' and 'dataloader' from GQL, to provide rich detailed view data to frontend (in just single call)

So that: 1. we enjoy the current tech stack from REST/rpc 2. we gain the ability of quick composition from resolver / dataloader 3. with iteration, we can replace/ refactor endpoint without breaking anything.

for fastapi user, the lib 'pydantic-resolve' can help.

Has anyone use graphql for service to service communication?

Seems really great to not have each service adhere to another service’s potentially unstable api contract.

Especially if that service is owned by another team.

    > Data fetching and the N+1 problem
    > [...] if a field resolver hits an external data source such as a DB or HTTP API, and
    > it is nested in a list containing N items, it will do those calls N times

Why is this considered a problem regardless of the situation at hand?

F.e. using REST, if the nested list contains on average N-2 items that can be efficiently cached, wouldn't that be better than having the cache constantly invalidated on the aggregation of the parent and its items?

> Rate Limiting... OOM... There is no REST equivalent to this attack of this severity.

Yes there is, simply throw JSON such as `[[[[[[...` at the server. You probably don't have to get into parsing though, nearly all C# (and Node, and Ruby, some Rust even) assumes that memory is, in-fact, infinitely large and just throw network input into a precisely-sized buffer. Just upload a few GB of nonsense to an API endpoint, bonus points if you omit Content-Length.

I never understood the problem that GraphQL was trying to solve. If REST doesn't work for you, I don't see what was wrong with query strings, or JSON parameters.

A few weeks ago, I read that tRPC is an interesting alternative.

I was over GraphQL the moment I looked at the specification.

I would have thought all of those were fairly obvious. It is more complex and gives the client a lot more power and control, so the trade-off is inevitable.

Have OP heard of Hasura? Majority of issues raised about graphql are solved problems there, and with free CRUD to start

Skill issue.

REST serverless business logic on top and graphql is great

I learned REST first, then I started working somewhere with gRPC. It was a revelation. Type-safe APIs! I was sold. Now I work somewhere where we’re all-in on GraphQL. It’s just a massive pain for very little benefit. In many ways it’s worse than REST. It really only works well if you’re writing something meant to behave like a database. Normal backends don’t want to do this.

REST is simple and works well with debuggers, logging, caching, auth, request throttling e.t.c

For graphql like needs we use a standard set of props (select, filter, sortBy, limit, offset).

They map to a single sql statement and executed efficiently by PG.

select can be nested properties if we need deeper nesting. Server emits typescript types package for frontend.

It's worked really well so far at our scale. Eng team is fairly productive.

When I saw GraphQL I immediately saw the issues that the poster talks about. I was amazed that people were drawn to it like a moth to a flame.

Your most precious resource is time. I'm really glad of the time I invested in Python, node, TypeScript, Virtualisation and Serverless.

I'm less happy about the time I wasted on bash, DOOM WADs, and Desktop Linux. Yes these are are all a while ago. I didn't invest my time wisely when I was young.

I'm also glad I didn't invest in GraphQL, Kubernetes, Angular, Solaris, and perl.

Despite all of these things ringing true for me as well at the last few companies/projects I worked at that used graphql, I will say that like everything in tech, there are trade offs, but if the tool generally solves the problem you have well, you'll be motivated to find solutions to the additional problems you have - which often means the argument actually comes down to who is more passionate about the particular tech.

One example that stood out to me though:

> GraphQL discourages breaking changes and provides no tools to deal with them.

GraphQL the standard doesn't provide tools no, but I've been very successful using Apollo Studio to solve this as (in my experience) the workflow maps to how you generally develop applications:

1) agree on some schema 2) make a (Apollo studio) "branch" with the schema change 3) mobile & backend devs (typically) code gen the objects they need for the schema 4) backend dev deploys a preview branch of their implementation, mobile dev points the client to it 5) test it, merge it, publish the schema on the main "branch" - deal with the breaking changes if Apollo warns you of them.

So maybe you can accomplish this with other tools, and maybe it's not fair to compare "the standard" to a particular tool, but I usually say I stick to gql (where appropriate) because there is a tool for it that works so well for the problem(s) I'm typically solving.

I've read the article and a few of the responses but have never used GraphQL. However I have a question

Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc?

So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.

At Cosmic, we released our latest API version without a GraphQL option in favor of a declarative REST API using `props` https://www.cosmicjs.com/docs/api/objects#get-objects.

I post sql queries to my backend then match them against the exact string. The lack of flexibility is on purpose.

Many of you guys probably don't even need API for web development. Same as we didn't. We rewrote codebase, removed React and Graphql part and now Django serves html. Win win for everyone.

We don't have mobile app and don't even plan, but if we do, we always can implement some rest api.

Graphql via spring is easy integrates seamlessly. Obviously stick to its core use cases and it will go great.

The only time I think GraphQL works is when it is when the GraphQL schema and resolvers are autogenerated by the underlying data stores. As a ORM layer, I love solutions like Postgraphile and Hasura where they mostly just reflect the structures you've already designed in your database. I also like REST solutions like PostgREST for the same reasons.

Then I'm designing my table structure, optionally designing my views when I don't want a 1:1 reflection of how data is stored, setting up row-level security at the data layer, and making user-defined functions for the one-offs that deviate from plain CRUD.

But solutions like Spring DGS for Java, Graphene for Python, and Apollo for Node? No thanks. Never again. Way too much trouble and pain. I'd rather make lambdas that talk to the data store directly and output HTML than make and maintain a GraphQL schema manually again.

I really wish Postgraphile and Hasura were more popular, so folks could have skipped the low level plumbing and optimization fences like dataloaders that make GraphQL such a chore otherwise.

It really is elegant when you're not stuck in a swamp.

As an alternative datapoint, we use GraphQL for a medium-sized app, are several years in, and are pretty happy with it. The downsides he mentions are all true, but on the other hand, are addressable, and for us feel worth the benefits of getting flexibility and control on the client-side.

Just use jsonrpc over websockets - you’ll have same semantics as function calling in your programming language, type it if you’re using static type aware lang and have happy life. It’s easy to optimise, refactor, trace/debug, use (same as using library with async functions) etc.

TL;DR GraphQL isn't really the problem, untrusted clients executing arbitrarily complex queries is the problem. This is why authz is hard, why rate-limiting is necessary, why "query complexity" calculations are necessary...

At Firebase we chose GraphQL as the basis for our new Data Connect PostgreSQL product (https://firebase.google.com/products-data-connect) despite acknowledging pretty much all of the issues outlined in this article as correct.

GraphQL is an excellent IDL (interface definition language). It's compact, it's flexible (through directives), and there's literally no better way I'm aware of to rapidly construct complex nested relational queries. But the promise of "clients can fetch whatever they want" adds an enormous burden to backend developers because you have to secure yourself against queries of arbitrary shape and complexity.

In reality you don't want clients to "fetch whatever they want" because clients can't be trusted. The path we took is that developers can predefine the queries that are needed for their client, and then only those queries can be executed from an untrusted client.

This approach provides a surprising number of benefits - you get the flexibility of nested queries and field selection, the end-to-end strongly typed structure of a schema-driven API, and the ability to reason about security like it's a custom backend.

Skill issue in my case, but I kept fighting against the caching of whatever GraphQL library I was using.

Made the dev experience a nightmare because I could never be sure whether it was my code or the client cache or the (actively in beta) server that was causing me to get back wrong data.

What are people using these days for TypeScript on both ends? I have a home-grown solution that starts with Zod schemas and gives synchronized types on the front end and backend as well as a client for free, but I'm always interested in using something standard

There’s a good response to this article here:

https://news.ycombinator.com/item?id=40536581

Several years ago, I used to respond to conversations where people hated on Facebook by saying that Facebook had given us at least two great gifts — react and graphql. Since then, I've grown to realize that these might in fact be its two great curses.

Of all the dumb ideas in the history of engineering, exposing an access point for strangers to query your database is certainly one of them. I cannot imagine that anyone involved had experience running enterprise systems at scale.

A lot of good reading and learning in the comments about where graphql usage can end up.

Has anyone experienced something similar with typedb? It feels a little too good to be true. Make it seems like graphql and nosql trauma.

My response to the blog above

https://blog.tailcall.run/writing-a-graphql-backend-by-hand-...

My $0.02 here:

GraphQL makes sense only at a certain scale when you have multiple APIs built by multiple teams that need to be exposed as a single endpoint. GraphQL as an API or APIs is the perfect use case and the one that it was designed for.

In every other case, REST is harder to do wrong and easier to do right. The tooling for it is widely supported and well known. Every aspect of building an easy to use, easy to own, easy to scale API is -- well -- just easier with REST.

I have seen more than a few small, 4-8 person engineering teams reach for GraphQL and then wonder why every cycle starts feeling slow. In a 4-8 person team, the devs are usually working full stack and if not, then they are working closely enough that having a highly flexible API layer servicing the front-end doesn't make any sense since it's either the same devs or they're one Slack ping away from getting the right shape from the backend in one simple `GET`.

Like the author, I've found that the story with OpenAPI nowadays is really good. I have a short writeup here with .NET that shows hot re-generation of the API into a TypeScript definition that can be used with React, Vue, or your framework of choice: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

This workflow is super productive and perfect for small teams working full stack; far easier than getting GQL right.

From a backend point of view, you will never be able to stop front end people from doing the wrong thing with an API.

GraphQL makes it easier for front-end developers to do the wrong thing, which is why they love it.

One context it works well in is something like PostGraphile. You basically spend very little time developing the back end. This obviously does not scale to very large projects.

Can only agree with author on all points. GraphQL was nice for the types, and precious little else. But we have better solutions utilizing just the types now, so it was still valuable.

We are in the process of winding down our biggest GraphQL attempt, after years of trying to make it work well. Nobody is feeling sad to watch it go, that is for sure.

At work we also stopped using Graphql and we only have a few endpoints left to migrate in our internal dashboard. Nobody that has worked on this project has liked the dx.

another project to take a look at for schema-driven approach to writing backend services and fully code-generated clients: https://github.com/webrpc/webrpc

it's similar to OpenAPI, but its simpler, and cleaner. In fact, you can generate webrpc schema's to OpenAPI and then generate OpenAPI clients.

This is a great post!!!

Not just for the content but I love it when someone changes their mind (very very hard thing to do) and details out what led them to change.

Odata is 80% of GraphQL with only 20% of the hassle.

Why, after 6 years, I'm over increased complexity for marginal benefit. Sounds like most things developed and promoted by FANG

So, TL;DR: if you want to exploit the flexibility offered by GraphQL, you need to pay for that with implantation complexity. I’ve never used GraphQL in my life yet can foresee the issues described in this post. If you try to retrofit GraphQL feature X, Y, or Z into your REST API, you’ll run into these exact same problems. If you stick with a classic REST API, you pay for that simplicity in other ways. Who here is on team “I have a plethora of use-specific endpoints”, and who here is on team “I built dynamic field selection and relationship traversal into API framework”? And, yeah. Dealing with N+1 database queries is loads easier if you constrain the potential pathways to the point that you can just hard-code your database optimisations instead of having to build a dynamic query optimiser. So you end up with a bunch of basic resource-mirror endpoints and then the N+1 database queries become N+1 HTTP requests. But hey, at least the requests are roughly equally expensive so you can simplify your rate limiting! As usual, it’s a question of trade offs, and it’s not the easy-path “you aren’t Facebook, so you don’t need it!” that people throw around here on the reg’. And, certainly, those that look down their nose and say “I know that I was right to not care for this, bloody magpie developers and their shiny toys” are certainly speaking with a misplaced sense of superiority.

You notice Facebook is increasing complexity across the board?

Frontend - React

Backend - GraphQL

What's extra creepy is the private equity firms squeezing this space dry

My experience is that a stable graphql server is dependent on well behaved clients, which is not something you control.

>1. Write a succinct human readable TypeSpec schema >2. Generate an OpenAPI YAML spec from it

Why? Isn't YAML human readable?

I started at the same conclusion of using OpenAPI and never ventured into GraphQL cause I only had one client.

Using Elixir+Absinthe solves most of these problems and the idea that a non-self documenting API doesn’t need every field to be secure is quite frankly a ridiculous thing to label as a problem for GraphQL, maybe the self documentation encourages better security practices, who knows!?

yes, let's conflate bad API / schema design with GraphQL / the technology being the problem.

shameless plug: i have been working on https://querydeck.io/ as a side project to bring the ease of use of graphql to REST apis. the plan is to open source it later in the year once its out of beta

I totally agree with every point.

GraphQL can be very powerful, but also very dangerous.

I think the post is definitely mentioning a few valid points which need to be addressed in proper GraphQL API designs. But most of REST "solutions" over GraphQL considerations are just pushing issues from the server side to the client side.

For example the whole n+1 data fetching topic: Yes this issue exists and like the author is mentioning: GraphQL has a well understood and common solution for this problem. On the other hand: In REST world you can have exactly the same issue, but either create a custom solution for this issue or push the issue to the client side, where this issue needs to be solved, too. I could not exactly follow the explanation of the special case of the n+1 problem in context of authorization. "This is actually trickier [...], because authorisation code is not alway run in a GraphQL context." OK authorisation code is not run in a GraphQL context, but why is this then a GraphQL issue?

On the rate limiting issue I also do not see why these issue would by design just exist in GraphQL world: Yes you can have recursive data structures and write queries which can take a lot a processing time to resolve. But again: Why would the same recursive data structure not be possible to be modeled for a rest api and why would the same data not be queriable from a rest api? My guess again is: You _can_ model the same data structure and also _can_ query the same amount of data. And also again: In case of the rest api the complexity of querying this data is just pushed to the client side and that is why it seems easier to rate limit individual rest endpoints. But actually I see no reason why a GraphQL API could not rate limit e.g. on data loader or any expensive operation level, too.

Generally regarding malicious (e.g. malformed) queries: I think this is definitely a valid issue, which should be addressed in GraphQL APIs. I think there should be a common way for application developers to sign their queries somehow and query engines should only attempt to process signed queries. This way only trusted developers are able to write arbitrary queries.

On the "Authorisation" section I can not quite follow the reasoning. Aside from implementation-specific extra-calls to a presumed authorisation framework: Why would domain requirements be different when they are implemented either as REST API or as a GraphQL API?

"Compare this to the REST world where [...] you would authorise every endpoint". OK if you can implement an authorization requirement simply on a REST endpoint, why could you not implement this simply on a Query-Type field in an equivalent GraphQL API? If this is about authorization on nested data structures: Can you not have equally nested data structures on REST endpoints, too? I think in these cases authorization on REST endpoints wouldn't be sufficient, too. Assuming you would avoid nested data structures: Would this not simply push the n+1 problem from the server side to the client side?

My general feeling about the REST vs GraphQL debate is both worlds can in principal cause pretty much the same issues. Even for client side caching I see no real design issue which prevents GraphQL queries and responses to be cached, but probably more like a middleware issue. On the other hand I still see a lot of benefit in using GraphQL: Especially the query flexibility for developers, the solved the n+1 query problem (which may still exists on the rest client side or is solved by a custom solution) and the error handling. I still hate to define exact use of HTTP status codes and custom error payload structure in every context where REST is a new or badly defined concept again and again.

The hype train strikes yet again! In fellow consultancy circles, we were giving talks on exactly this back in '17 and '18, but the hype train was too strong then. It was even harder to convince this same crowd that SPAs are usually a bad idea, and emerging technology like Hotwire or LiveView would soon eclipse the SPA-obsessed culture. GraphQL is immensely powerful and useful for its exact use case, and extremely burdensome and expensive for any other use case. If you dont already know that use case, YAGNI. The same can be said for any hype train. The problem with any kind of hype train in tech is everyone looks for reasons to use whatever the new hyped thing is, rarely does anyone determine if the new hyped thing actually fits their use case(s). This will continue so long as there is a dichotomy of culture between youths and those with lengthy experience. We old people will continue to point out exactly why this or that is pure hype, and will continue to be drowned out by the emotions that come along with participating in hype.

Last time I used GraphQL the front-end devs ended up writing a single query to hydrate the entire data model in one pass, so they could be sure the data was present for all the components. We spent a month on the backend enabling GraphQL and we could have saved that and written a single "api/getAllTehData" REST endpoint in about half an hour.

I'm looking at Shopify API at the moment, and there's a notification that they're deprecating their REST API and moving it all to GraphQL. I hope it's a joke. But I suspect not. Enshittification intensifies

Unfortunately it has become fashionable in SaaS products to only offer GraphQL endpoints, thus whatever we think about it, GraphQL it is.

I worked with CORBA during 90's and early 2000's. A truly shitty piece of technology that I do not wish upon my worst enemies, except maybe the higher ups at Microsoft who invented COM interfaces. When I saw the hype of GraphQL in 2017 I looked into it and while exploring it I started to have PTSD from CORBA days. "So you're the new CORBA, huh? I'll fuck off as far away as I can from you then" - and told the same to every client that even mention it.

i was over graphql when it started. REST was fine

GraphQL.. when people didn't learn their lessons from SOAP..

Graphql was routinely an overly complex piece of shit when I was forced to deploy software with it.

I'm surprised it took 6 years to discover these issues. The N+1 problem and auth/field privacy are obvious on practically any project.

In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.

Cross post from the blog comments. Since you asked whether there's other solutions...

I think it's worth mentioning that there is a GraphQL project which has worked to address every single point elucidated here. Of course whether the framework's conventions satisfy your tastes and sensibilities is an entirely different story. The project had at least an answer if not the answer to every gripe listed in this article by the end of 2022.

Despite having basically solved all these issues two years ago, there's been a consistent stream of articles, videos, and podcasts like this one claiming that GraphQL is too complex and the GraphQL ecosystem doesn't provide any tooling or support for managing these complexities.

The great irony is that the framework in question is now pivoting away from GraphQL. Seemingly no one wanted to use a GraphQL framework. But why? Whenever someone learned about the framework, they would say to themselves:

"Well I don't want to use a GraphQL framework since GraphQL has all these problems like auth and caching and rate limiting and performance. It's just too complex so I'll avoid any frameworks that use GraphQL." They would never seem to realize that the very framework they were refusing to use was literally the answer to the justification provided for why they didn't want to use the framework. Eventually, after having this exact conversation a few hundred times with a few hundred devs, I decided that there's only two ways I could explain what was happening, either:

(1) Every time while trying to explain this, all of these developers were experiencing some kind of out of body dissociation not dissimilar to a stroke or brain aneurysm which made it impossible for any semantic meaning to reach them.

(2) These developers just didn't like GraphQL and didn't want to use GraphQL. They were making up a bunch of reasons to not use GraphQL but they had no interest in a framework which solved these issues cause the issues weren't the problem, GraphQL itself was the problem.

Since I've already spent hundreds or even thousands of hours trying to explain to the open source web dev community how RedwoodJS solves these issues, you'll have to forgive my laziness today and make due with this ChatGPT rebuttal instead of another one of mine.

Understanding RedwoodJS in the Context of GraphQL Criticisms: A Detailed Response

The blog post raises several valid concerns about GraphQL's use in production environments, particularly around security, performance, and complexity. Here's how RedwoodJS addresses these issues, considering the specifics mentioned in the blog post.

1. Attack Surface - The blog highlights that exposing a query language like GraphQL increases the attack surface of an application, necessitating robust security measures. RedwoodJS leverages GraphQL Armor, which provides built-in protections against common GraphQL vulnerabilities. These include rate limiting, depth limiting, and cost analysis to prevent overly complex queries. Additionally, RedwoodJS uses Envelop plugins for enhanced security measures, such as blocking field suggestions and masking errors, which are essential to prevent information leakage and mitigate potential attacks.

2. Authorization - GraphQL's flexibility can lead to challenges in properly authorizing access to different fields based on context. RedwoodJS integrates authorization directly into the schema using directives like `requireAuth` and `skipAuth`. This ensures that each query and mutation can enforce authentication and role-based access control efficiently. By embedding these security checks into the GraphQL schema, RedwoodJS helps developers avoid the pitfalls of broken access control.

3. Rate Limiting - The blog points out that GraphQL queries can vary significantly in complexity, making it challenging to implement effective rate limiting. RedwoodJS includes mechanisms to estimate and limit query complexity. It supports configurations to set maximum query depth and complexity, thus preventing queries that could otherwise lead to server overload. These settings help ensure that the GraphQL server can handle incoming requests without being overwhelmed, addressing the concern of unpredictable query costs.

4. Query Parsing - GraphQL's requirement to parse queries before execution can lead to vulnerabilities if not handled correctly. RedwoodJS mitigates this by implementing limits on query size and the number of operations, ensuring that the parsing process does not lead to excessive memory consumption or server crashes. This approach helps safeguard against denial-of-service attacks that exploit query parsing vulnerabilities.

5. Performance - The blog mentions issues like the N+1 problem and challenges with HTTP caching in GraphQL. RedwoodJS uses the Dataloader pattern to batch and cache database requests, effectively mitigating the N+1 problem. By ensuring efficient data fetching mechanisms, RedwoodJS maintains performance even with complex queries. Additionally, while HTTP caching is not inherently compatible with GraphQL, RedwoodJS’s structure and client-server interactions are designed to minimize redundant data fetching.

6. Complexity - GraphQL's flexibility can lead to increased complexity in codebases, making it harder to maintain and debug. RedwoodJS aims to simplify the development process by integrating various tools and abstractions that reduce boilerplate code. The framework's philosophy of convention over configuration helps maintain a clean and manageable codebase. Moreover, the built-in support for Cells (components that handle data fetching, rendering, and updating) abstracts much of the complexity away from developers, allowing them to focus on business logic rather than the intricacies of GraphQL.

7. Conclusion - RedwoodJS addresses many of the concerns raised in the blog post through its robust tooling and thoughtful abstractions. By integrating security measures, optimizing for performance, and simplifying the developer experience, RedwoodJS presents a compelling solution for building modern web applications with GraphQL. While the criticisms of GraphQL are valid, RedwoodJS's approach demonstrates that with the right framework, many of these issues can be effectively mitigated, making GraphQL a viable choice for many projects.

Now lets do Docker next. :-)

For professional developers that know more or less what they are doing, most of those things are absolute non-issues. Let's list it:

> if you expose a fully self documenting query API to all clients, you better be damn sure that every field is authorised against the current user appropriately to the context in which that field is being fetched.

The same is true for a "regular http API" [now abbreviated as "rest API"] (in case it's not clear: imagine how the http API would look like and think about if it would be somehow magically secure by default. Spoiler: it won't). Security by obscurity was never a great thing. It can help, but it's never sufficient on its own.

> Compare this to the REST world where generally speaking you would authorise every endpoint, a far smaller task.

Just think about how many endpoints you would actually need to cover all combinations that the graphql API offers.

> Rate limiting: With GraphQL we cannot assume that all requests are equally hard on the server. (...)

It's true. However: a rest API only makes that easier because it's less flexible and you have to manually create one endpoint for each of the various graphql API combinations. So instead, a classical graphql mitigation that the author does not mention is to simply require the client (or some clients) to only use fixed (predefined) queries. That is then the same as what a rest API does, problem solved. So graphql is not worse of here, but it can be much better.

> Query parsing

This point is actually fair, except for the claim that there is no equivalent in REST. That is simply not true, as there have been many cases where rest frameworks worked with json and could be ddos'd by using large json numbers.

> Performance: When it comes to performance in GraphQL people often talk about it’s incompatibility with HTTP caching. For me personally, this has not been an issue.

Funny, because that is indeed one factual disadvantage of graphql.

> Data fetching and the N+1 problem: TLDR: if a field resolver hits an external data source such as a DB or HTTP API, and it is nested in a list containing N items, it will do those calls N times.

No, this is wrong. But first: this problem exists in a rest API as well, but worse: instead of N+1 queries to the DB, it will N+1 http requests AND N+1 db requests. But with graphql and some libraries (or some handwritten code) it is comparibly easy to write resolvers that are smart and "gather" all requests on the same query level and then execute them in one go. This is harder to do in a http api because you definitely have to do this by hand (as the auther describes).

> GraphQL discourages breaking changes and provides no tools to deal with them.

What? Comon. In a rest API there is no means to do anything against breaking changes by default. Graphql at least comes with builtin deprecation (but not versioning though).

> Reliance on HTTP response codes turns up everywhere in tooling, so dealing with the fact that 200 can mean everything from everything is Ok through to everything is down can be quite annoying.

True, but that can be adjusted. I did that and made it so that if all queries failed due to a user-error, the request will return 400, otherwise 204 if they partly failed.

> Fetching all your data in one query in the HTTP 2+ age is often not beneficial to response time, in fact it will worsen it if your server is not parallelised

Okay, I'm starting to be snarky now: maybe choose a better language or server then, don't blame it on graphql.

And actually, many real problems of graphql don't even get mentioned. For example: graphql has no builtin map type, which is very annoying. Or, it has union types in the response, but you can't use the same types as inputs due to a lack of tagging-concept.

And so on. My conclusion: the auther is actually fairly inexperienced when it comes to graphql and they probably had a bad experience partly due to using ruby.

My own judgement: graphql is great except for very very specific cases, especially in projects that require huge amounts of servers and have a high level of stability in the API. I would always default to graphql unless the requirements speak against it.

Well yeah, who knew that letting your frontend developers blow up your database because nobody talks to each other or designs things anymore would be a bad idea?

It's not graph, and it's not QL.

Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.

I never understand how people end up needing overly complex queries (REST or GRAPHQL). Maybe it's harder to coordinate in bigger orgs but I have almost always found its better to go to the DB, create some logic there like a new table or sql view and do a simple query from the client. It keeps thing way more performant and simple.