After 6 years, I'm over GraphQL

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.

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.

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.

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.

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

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.

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

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/

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.

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

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.

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...

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.

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.

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 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 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.

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.

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 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.

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.

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.

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

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.

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

    ...

  }

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.

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.

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.

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.

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.

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.

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.

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)

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.

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.

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

Why? Isn't YAML human readable?

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

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

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).

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

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.

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.

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)

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?

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.

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

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).

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

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.

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.

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.

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.

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 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

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.

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

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.

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.

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

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!

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

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.

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.

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 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.

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

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

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.

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.

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.

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.

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)

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.

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.

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.

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.

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).

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.

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

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

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

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.

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 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.

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 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.

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?

    > 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

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?

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

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.

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 was over GraphQL the moment I looked at the specification.

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.

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.

“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 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.

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.

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.

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 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.

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.

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!?

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

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.

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.

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

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.

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