r/programming • u/macrohard_certified • 21h ago
Maybe you don't need GraphQL
https://alexandrehtrb.github.io/posts/2026/09/maybe-you-dont-need-graphql/104
u/Isogash 20h ago
The first one is coupling to the data layer. Most databases don't have native support to GraphQL queries, meaning that a layer of mappers and logic needs to be built on top of another data access layer. This is extra code and extra processing.
Most people aren't using their Database to provide any other API directly either. I personally haven't found the layer of mappers and logic required for GraphQL to be particularly more complex than any other API if you use a framework. In fact, it is often much easier to extend existing APIs because you can break your data fetchers down by field, and you don't generally need to consider endpoints as a whole.
The main benefit of GraphQL is that it allows you to design an API that is powerful for users and extensible for service providers. A huge plus that is overlooked here is GraphQL federation: you can have a single GraphQL object and query where fields can be resolved from different sources. This is really useful if you have a lot of data associated with some common entity, like a user. Any query that can find users can also get any data about those users from any service, all in a single query.
APIs can receive flags from the client indicating which fields it wants to receive.
Yes, you could do that manually. You could also write your own system which does it automatically. Then you'd have re-invented GraphQL.
I think where GraphQL doesn't make sense is when you don't have much data, or don't have particularly complex data needs and you're better off having much tighter control over the API.
28
u/chucker23n 17h ago
A huge plus that is overlooked here is GraphQL federation: you can have a single GraphQL object and query where fields can be resolved from different sources.
I… don't really see how other mechanisms don't allow that. A REST
GETdoesn't need to fetch from a single data base. It could aggregate different sources. It could even in turn make additional calls to other Web APIs. This is mostly uncommon because of the complexity and latency involved, but I imagine GraphQL doesn't change that.6
u/JarredMack 10h ago
Consumer A needs a user hydrated with their bank balance, 5 recent transactions, and their address which come from 3 different data sources.
Consumer B needs a user hydrated with their address only.
Do you fetch all of that data on every request and just give the full object? Do you have different endpoints? Do you have query params to opt in to particular fields (which is basically manually doing what GraphQL solves)?
The answer to these questions depends on how much data you have and how likely it is consumers need different shapes of data. In most cases it's overkill, but it does have its uses
3
u/chucker23n 5h ago
I get the use case, I’m just saying you can absolutely do that in REST or even SOAP.
20
u/Isogash 16h ago
GraphQL provides mechanisms that make it easier to write more automatically. Your GraphQL servers are able to resolve entities by their ID rather than querying for them, so if a query to service X gives you entities A, B, C, the federation layer can then go to service Y and fetch additional fields for these entities by ID. These fetches can be batched if you write special batched data loaders, which are not too hard to write normally and you can do it on a per-field basis where required.
Like, you could design your system differently, but GraphQL is pretty good at just letting clients do what they want reasonably efficiently, which matters in larger projects where it's difficult to justify refactoring everything and writing custom endpoints to make specific queries more efficient.
For a real-world example, we use it in a loan platform. Some data associated with the loans exists in different systems, but once you have a loan ID, you could potentially want any combination of the loan data (and it has a lot of complex child data e.g. historic versions, sub-products, summaries, arrears history.) This is never an issue for us though, because if you have some data associated with the loan, you just add it to the loan object in your GraphQL schema and write a field resolver and the federation service can resolve the field for a loan that was queried from any service.
So you could have one service that tracks workflow cases for loans query for the loan assigned to an agent, and then pull in any combination of data associated with the task as though it all lived in one system e.g. direct debit payment schedule and CRA report data, which live in different systems.
If I wanted to write that feature as a client, I wouldn't need to edit any of the services, I'd be done in minutes. I also don't need to predict what client features will need what sets of data when I wrote the services. The capability to pull DD payments and CRA report data at the same time would not be something I'd predict, but it's already possible because of GraphQL.
It's also really useful for debugging, because you can pull any data for a loan from basically every system all in one query.
13
u/kingdomcome50 18h ago
And, somewhat unintuitively, GraphQL also doesn’t make sense when you have lots of data or very complex data needs 😂
13
u/Isogash 17h ago
GraphQL doesn't care how much data you have, but it does care how much you're sending and how complex your query is.
It's not the right choice for data visualization webapp that might need to fetch millions of data points, and it's not for doing absolutely mammoth OLAP-style queries.
It's best when you have a good sized system with rich, connected data (especially lots of parent child relationships), and you have UIs that just want to fetch everything they need for the page in a single request.
6
u/Jump-Zero 13h ago
It makes sense when you have more clients than the team can keep up with. If you have a mobile client and a web client, you can just use REST. If you have like dozens of clients, then GraphQL becomes a no-brainer. If you have two clients, you can just build a custom endpoints to fetch exactly what you need for a given page/component.
2
u/Isogash 12h ago
It depends on how complex the clients are and how often you want to write custom endpoints. In the system we've built the clients are complex and we've needed to write precisely 0 custom endpoints for our web and app clients in the last 5 years. All we have to do is add a field to an existing GraphQL object if some data wasn't already being exposed, and because most of it is by default it's not a common occurence.
It makes adding new features a breeze because you don't need to modify any existing APIs, you just add new objects, fields, queries and/or mutations. The API can be played with in our sandbox environment GraphiQL which also displays documentation from the schema comments.
1
u/Jump-Zero 4h ago
That’s fair. I wouldn’t reach for GQL unless the complexity was there. If it is, then by all means. I generally stick to REST, but I’m comfortable with GQL if I really need it.
2
u/MrSqueezles 3h ago
GraphQL and its frameworks don't give you any of those features for free. You write database queries, mappers, cache control, endpoints, how to look up child elements, schema, literally everything except field filters. The API is arcane and not standards compliant, tossing out request verbs and response codes that are critical for caching and routing. It's a bad solution to optimize for a bunch of highly specific edge cases.
Nobody needs to re-invent GraphQL. Nobody needed to invent it in the first place. It wasn't a new idea when it was created. There are plenty of other options that embrace standards and provide the same functionality and more without the cache and concurrency complexities of frameworks like Apollo.
0
u/lechatsportif 6h ago
You only need the base use case to work well. We made 2-3 data pulls from heterogeneous backend datastores like 2 years ago. The frontend team pulls only what they need from our massive objects and they features and different projects all the time. Just that right was huge, I practically never have to field a frontend request for more data or new endpoint etc. Its like a once a year activity despite furious development pace all around. It's great, would use again in a heartbeat.
51
u/Merry-Lane 21h ago
Why the content of the article doesn’t even hint at "maybe you don’t need graphql"
5
115
u/c-digs 21h ago
GraphQL has a place.
- Multiple teams?
- Each team owns an API?
- Those APIs need a single, unified entry point?
- The FE team works separately from the API owning teams?
- There's a dedicated team available to own the unified API surface area and infrastructure?
GraphQL is a good fit and solves real problems.
If your developers are all full stack and own the FE + the BE, then GraphQL is just an absolute waste of time.
51
u/mcmcc 21h ago
Honest question: under what circumstances is a single unified API entrypoint a requirement?
25
u/holo3146 20h ago
I'm a working in a company whose product handles a full internet stack (vpns, sockets, bandwidth control, security, monitoring, content control, high availability, BGP, ...)
We have hundreds of types of entities with different structural levels, with hundreds of developers working on the product.
Having a uniform API for frontend<->backend communication is very convenient, and having a uniform public API to expose to clients is a MUST.
For those 2 use cases we use graphql. For internal backend components communications we mostly use simple REST
7
43
u/jpj625 20h ago
My feeling from "working" with it a few years ago was that it solves problems for Facebook.
If you need the ability to make a single call, with fields customized to your client/viewport, have different levels of caching applied to different parts of the response, support squillions of requests per moment, and you have dozens of talented SWEs... it can be worth the hassle.
But GQL can go piss up a flagpole.
10
u/c-digs 19h ago
Think Facebook: dozens of teams delivering multiple backend services that the front-end API accesses as a single unified surface area via GQL.
The threshold is probably a bit lower than Facebook; I think once you get into 10+ teams working on relatively isolated services that ship on different timelines, different release processes, etc. it starts to make sense to decouple their SDLC but unify them in terms of access. You don't want a client to deal with 20 different services; the GQL resolvers effectively unify the service as one surface area.
60
3
u/NecessaryIntrinsic 20h ago
I've found it invaluable in working with the M365 environment (which is a whole other nightmare but it's better than every api that came before it)
4
u/After_Dark 19h ago
It's not uncommon in more secured environments, anything to do with financials or medical data for example. One unified API entrypoint means a narrower scope for security, auditing, and all that wonderful compliance scope and means it's much easier to configure pinholes in firewalls.
2
u/rabidgnat 17h ago
To your exact question, when you have a massive SPA (or worse, many massive SPAs) and you find that client is constantly blocked on backend to implement changes it needs.
Imagine someone working on the Facebook frontend, where you have access to an endless pool of backend data and you can factor and refactor it infinite ways.
Note that you need a Facebook-scale blockage to make it worth it. GraphQL only makes sense is when you suffer from the exact specific problems that it solves: if you're implementing thousands of API endpoints to avoid overfetching/underfetching, if you need to provide federation and discovery for clients, if you have unexpected fanout and resource usage problems, if you're writing similar API endpoints over and over to avoid overfetching, etc. If you're not like, S&P 500 sized, you probably don't need GraphQL
5
u/made-of-questions 20h ago
There are a few additional scenarios where I've found it useful, for example in places with very complex data objects and an API that is used in many different ways. Allowing the clients to select what data they want and join is easier than to create a rest endpoint for every combination.
1
1
u/applechuck 19h ago
This was possible on REST for years through query params.
6
u/made-of-questions 18h ago
Join multiple models? Then it's not REST
2
u/lord2800 11h ago
Why do you believe it's not? The joining of multiple models is itself a new model.
1
1
u/Strifebringer 19h ago
Not only is it a waste of time, it becomes an enormous hindrance and performance risk.
12
u/Pharisaeus 13h ago
The issue is:
- Frontend people like it, because you can just pull stuff in one go and use magic frontend libraries to handle caching, refreshing etc.
- Backend people hate it, because all those magic features have to actually be implemented in the backend.
A good example is the "subcribe" feature - from the frontend perspective it's great, you just subscribe to changes in some data and you have real-time auto-updating display for it, without the need to fetch it periodically. But in reality this simply shifted that responsibility to the backend - now the backend might need to run some threads to fetch the data and monitor for changes (eg. imagine that this data comes from some other system, so you don't know when it gets modified).
Similarly one of the selling points of GraphQL is that you only get the data you requested without the need to pull anything extra. But on the backend side someone has to implement all those partial resolvers to make this actually true. I've seen cases where backend would pull everything every time, and simply drop stuff that wasn't needed.
The article was written from the backend perspective, so for obvious reasons it will be critical. Frontend people will hate it, backend people will agree with it :)
4
u/MonkAndCanatella 10h ago
The backend really should be driving all that stuff anyway though
1
u/Pharisaeus 3h ago
If you decide to have such features at all ;)
When you're the one who needs to implement and maintain it, you might very quickly realize that "maybe we don't actually need it".
7
u/Meleneth 14h ago
The article identifies a frontend N+1, then assumes GraphQL makes it disappear. It doesn’t: naïve resolvers simply move the same N+1 to the server. HTTP/2 multiplexing doesn’t fix request fanout, and ?includeAddresses=true&includeLoad=true is just a bespoke, impoverished selection language.
You may not need GraphQL, but the important question is whether the backend resolves the requested graph in batches—or fetches it one record at a time. That matters far more than REST vs. GraphQL.
6
u/jetsonian 11h ago
Our overseas developers wanted us to switch/implement GraphQL in our project. We presently use an Oracle database that’s hundreds of tables.
No one on our team had any experience with GraphQL but we were open to giving it a try. After a month of engineers off and on trying learn we decided against it.
Our biggest concern was that our API is rights-based at the data level (i.e. some fields aren’t returned or are partially returned like social security numbers) and we couldn’t figure out how to implement that in GraphQL despite a lot of googling.
Other elements we got stuck on was our API also has business logic in it (I didn’t architect this). This meant that we had to reengineer a chunk of our internal business logic to be run on the front end instead.
The biggest issue was that our state regulators won’t approve any code written outside of the United States period.
We’re in one of the most highly regulated industries (casino operations software) and everything has to be approved by regulators. When we want to release a new version, a regulator has to watch the entire build process and then take the files to their offices to scour both the code and the build. Their only exceptions are UI code and database functionality. Thus our overseas developers develop our mobile app and do database design but not database code or our primary computer app.
3
u/MonkAndCanatella 10h ago
Our biggest concern was that our API is rights-based at the data level (i.e. some fields aren’t returned or are partially returned like social security numbers) and we couldn’t figure out how to implement that in GraphQL despite a lot of googling.
that's crazy. maybe embed perms on the token and throw 403/simply not return forbidden fields? I wouldn't expect something like that to be difficult to implement in gql
1
u/jetsonian 9h ago
We have to return all the fields (a 403 isn’t appropriate in this case) but we don’t fill in, or we obfuscate, some of the fields because they’re PII. Who has access to what is based on our existing user system.
I’m sure it’s possible but we didn’t know GraphQL at the time and adding features like that was well beyond what our team was capable of. We even asked them to write us a proof of concept or sample code and they couldn’t produce it.
In the end my boss and I realized his boss was trying his best to outsource as many jobs as he could. When his hand-picked overseas crew couldn’t produce the same thing we were asked to do, executives lost confidence in him and he got canned.
1
u/MonkAndCanatella 3h ago
Oh that's an impossible situation lmao, not sure fizzbuzz could get accomplished in that environment
1
u/macrohard_certified 11h ago
A little off-topic, but shouldn't the database and UI code also remain in your country, for safety reasons?
1
u/jetsonian 11h ago
It’s not a requirement of the regulators. Basically they want to protect any code that is money related. They don’t regulate code that isn’t doing business transactions.
That said I work on the team trying to unravel a lot of our existing code, some of which is 30 years old. Our in-house ORM, for example, was written by a developer that isn’t just retired, he’s dead.
15
u/zxyzyxz 20h ago edited 20h ago
I want statically typed compile time checked guarantees of data types being sent over the wire between client and server, what should I use? Protobuf is clunky and is binary only so sometimes debugging is a pain, and it's more built for server to server communication anyway. OpenAPI is good but may not necessarily have the same guarantees as GraphQL which are checked by its compiler. So I'm stuck using GraphQL but there should be a better option. I guess Amazon's Smithy?
I also like how GraphQL can cut down API requests by stitching fragments into just one whole call, then the backend receives that and processes whatever it needs to do and creates one cohesive payload back to the client, so less data is sent over the wire each time. That's actually why Facebook created it in the first place, for saving data in bandwidth constrained areas and devices like phones.
I'm not using Javascript or TypeScript by the way, this is more so a mobile and desktop app question. You could just use tRPC if you have a TypeScript web or React Native frontend and using a server TypeScript backend.
10
u/kevin-mcdonald 20h ago
For a while now Protobuf has had mappings to JSON, so you can actually use protobuf-derived types on the frontend and backend across languages and the serialized format can just be JSON. All officially supported languages support this JSON serialization/deserialization, aka "ProtoJSON".
3
u/tadfisher 16h ago
TypeSpec. I will soon be working on Kotlin and Swift codegen for it, so you can have all your type safety guarantees without going through OpenAPI first.
1
u/zxyzyxz 16h ago
What's different about it compared to OpenAPI?
1
u/tadfisher 15h ago
It is human-writable, so it's positioned to be the language you write your API in, and you use it to codegen server/client code and/or an OpenAPI spec if needed. It is a compiler that's extensible, so you can write decorators or linters to enforce your business-specific API requirements. Basically it's meant to produce APIs instead of documenting an existing API like how OpenAPI (and Swagger) originated.
3
u/lamp-town-guy 17h ago
Django ninja/ FaatAPI generates openAPI directly from serialisers. At one workplace I used to work they replaced graphql with it because FE guys liked it and it wasn't pain in the ass to maintain in Python like graphQL
1
u/Merry-Lane 18h ago
OpenAPI + zod validation at the boundaries?
3
u/zxyzyxz 18h ago
I can't use Zod because I'm not using TypeScript and anyway that's at runtime, GraphQL can detect type discrepancies at compile time which is very powerful.
1
u/Merry-Lane 18h ago
I’m sure you can generate with most well known frameworks data validators (like zod).
Idk which language you use but you can usually have compile and runtime guarantees with OpenAPI
22
16
u/fabis 19h ago edited 19h ago
Love GraphQL, been working with it more than half a decade and always use it in personal projects as well. I love the opinionated nature of it which has resulted in great tooling (e.g. Apollo Client, especially the caching layer), an easy to reason about API surface and I love how easy it makes building big and scalable APIs. Designing the API as a graph is genius as it enables very custom and specialized queries, ones that you may not have even imagined at the time of designing.
I hate how low level and unopinionated REST is and how it leaves so much about how to architect the frontend app state and caching up to you, forcing devs to come up with their own shittier half assed solutions for problems GraphQL tooling solved ages ago.
Pretty much the only time I will not use GraphQL is when I'm not building any kind of frontend in front of the API (e.g. for server to server communication) as a lot if not most of the value is derived when consuming the API from a stateful UI. But most of the APIs I ever build have a UI in front of them, so thats a rare exception.
Sure it has its quirks and pitfalls just like anything else, but I've worked for years with REST and I've worked for years with GQL, and GQL has been the best full-stack experience by far.
I feel like people who shit on GQL are usually backend devs who don't give a shit and don't have any understanding about the pitfalls and challenges of frontend development, because REST is just easier to get started with in the backend side of things. Like how does this bullshit article not even cover the consumption/client side of the API at all when making its judgement of the language?
6
u/DirtyFrenchBastard 18h ago
Sure. I like GraphQL but my experience is that it is to mis-use and then people start making Rest 2.0 with it.
5
u/acdha 7h ago
I feel like people who shit on GQL are usually backend devs who don't give a shit and don't have any understanding about the pitfalls and challenges of frontend development
This reads as pure projection: the backend developers have to implement and support GQL. If they didn’t care, they’d say “sure, we can do that, it’ll look good on my resume!” but you’re getting pushback because they do care and recognize that shifting complexity doesn’t reduce it, it only means someone else has to deal with it.
The same traits which make GQL appealing also make it hard to optimize and scale, not because it’s intrinsically horrible but because it’s flexible and gives callers more control over access patterns, an inherently harder challenge. That doesn’t mean it can’t be scaled well but if you’re shifting work to another team without shifting people, they’re rightly going to see it as reducing the time they have for other work.
8
u/chucker23n 17h ago
I feel like people who shit on GQL are usually backend devs who don't give a shit and don't have any understanding about the pitfalls and challenges of frontend development, because REST is just easier to get started with in the backend side of things.
I would flip that right around. I imagine a lot of teams that go with GraphQL do so because of "easier to get started". It's easier for the backend team to just shove out a generic "whatever, just say what data you want" endpoint, and for the frontend team to consume that, than for both teams to actually sit together and design the APIs that are actually required.
Doesn't mean that GraphQL is bad, but I do think it can be an indicator of a poor processes regarding software design/architecture.
2
u/drgmaster909 7h ago
Invariably I find the people who hate GQL to have really, really shitty GQL implementations. I joined my current company when GQL was on its way out and being replaced with a v2 REST API and having reviewed how they used GQL... no wonder they hated it.
Just kills me because there's no opportunity to "fix" it. Its on its way out. End of story. But now I have to solve a bunch of problems that simply having a well-defined Schema already solved.
Now there's no one "Author" entity. There's the Author /authors returns. The author /authors/:id returns. The author /books?page=1 returns. The author /books/:id returns. The author /publishers/:id returns. The author /wishlist/:id returns. A dozen different "shapes" of Author. It's driving me crazy there's no one canonical "Author" entity I can generate for unit tests or TypeScript.
3
u/Pharisaeus 14h ago
I feel like people who shit on GQL are usually backend devs who don't give a shit and don't have any understanding about the pitfalls and challenges of frontend development
Those are simply people who actually have to "implement this" :) All those partial resolvers and subscriptions have to be implemented in the backend by someone, and in many cases it's not trivial at all.
3
u/MonkAndCanatella 10h ago
I hate how low level and unopinionated REST is
REST is extremely opinionated but I imagine you're talking about json payloads over HTTP accessed over URLs and not actual REST, which is super unopinionated.
3
u/seppyk 17h ago
The most important part of the article was the appropriate solution section. GraphQL is useful for platforms with a very large number of clients with distinct requirements - one size fits all RESTful APIs create larger issues in this ecosystem.
Most specialized SaaS or on-premise solutions do not require the tradeoffs that GraphQL provides.
3
u/MonkAndCanatella 10h ago
I kinda think that if you think you need graphql what you really need is a BFF or just write screen shaped endpoints instead of forcing everything into resource based endpoints.
2
5
u/Komarara 20h ago
We are using graphql api and I love it, so easy to resolve complex objects also end user can use the api to for reports.
3
u/CVisionIsMyJam 19h ago
i use postgraphile and laugh whenever i think of developers spending their days writing get endpoints
2
u/lovethebacon 14h ago
No-one who wants GraphQL needs GraphQL. And no-one who has GraphQL wants GraphQL.
1
u/mysteryihs 13h ago
If you work with shopify, you need GraphQL. (Not by your choice, but because the head honchos at shopify decided so)
1
u/drgmaster909 7h ago
Meanwhile over in REST I keep solving a dozen problems GQL solved OOTB with an actual schema I can codegen off, one idiomatic Entity Shape instead of a dozen "snippets" of an underlying model each REST endpoint returns, and an actual separation of my Domain Entities and how they relate to each other.
People keep trying to build non-Caller-aware REST APIs and invariably fail when a page they're building needs data the REST endpoint didn't originally return. Thus mixing consumer needs with backend "purity." Not really a thing in GQL. Query what you need. Backend doesn't need to know. Use a dataloader.
1
u/Bitter_Ad3906 2h ago
You seems not understand what graphql for what it need be used. Also implementation you show it’s same for rest api, and it’s bad idea send pure data from db to client in most times.
1
u/gretro450 21h ago
We have a GraphQL API. It sucks, man. The code is much more complex to account for it, but the worst is the usual metrics that could help you scale your API don't translate super well into GraphQL. Any request could be a super complex one
-4
u/GenericRedditor12345 19h ago
You’re probably doing it wrong
-2
1
1
u/n9iels 12h ago
Every tool, language, framework or pattern can be (mis)used for the wrong purpose. There is no golden bullet or one-size-fits-all solution. GQL is just one of these things.
I personally think it is used too many times with argument 'reducing complexity of multiple endpoints and self documenting'. A REST endpoint can be documented as well with OpenAPI doc and with only a little standardization consuming multiple endpoints isn't a problem at all.
1
0
u/falcompro 10h ago
Sure lets not talk about the best features of front-end GraphQL, fragment composition and colocation.
536
u/thicket 21h ago
You definitely don't need GraphQL