Six Years Later, I’m Over GraphQL

I love GraphQL. I also regret it. I’m very thankful this blog post exists so I can talk about it more.

SOURCE

S/O Ph4se0n3 for the awesome edit 🙏

[RaZziaN]

Well.. Theo is changing technologies every 3 months so no wonder..

[hanzo]

I may be misremembering but when I was first introduced to graphQL by some ex-colleagues circa 7 years ago, word on the street was that graphQL was not a replacement for your rest API. I thought it was supposed to be used on top of one or alongside it.

Ignorance is bliss I suppose

[SaschaBecker-kp]

Using graphql for the last years over all our products. We can spin up new products really fast. Every developers knows how to handle things. Sure, eliminating codegen would be cool but that's not enough for me to shift to trpc.

[Omnifarious]

This fits with the paper I wrote a long time ago about why CORBA (long time ago, ugly, think binary WSDL (also a long time ago and ugly)) and other forms of RPC are a bad idea.

The problem with GraphQL is that it exposes too much of your internal state to external users. In my paper I describe RPC as being about what you want the other side to do rather than the messages you want to exchange. And that's true, but the real problem there is that when giving the other side detailed instructions on what you want to do, it necessitates knowing a lot of internal details about how the other side functions.

I wrote this paper in the 1990s, but you could look at it as advocating for REST APIs. Though that's a little too narrow of a reading. I intended to lump in things like SMTP as being well designed protocols. I mean, SMTP has numerous security flaws involving verifying senders, but that's not the kind of issue I was talking about.

[jackwright]

I've used trpc and graphql, I can't put my finger on why but I'm more comfortable using graphql and find it more enjoyable to use 🙈

Graphql provides a level of power I just love. Even for... Simple projects. 😬 That have more servers than users. 🤣

But I agree with most of your points!

[AlexandruVoda]

As a database person, the fact that something called a dataloader pattern exists to soften the N+1 problem boggles the mind.
We can do most things with just 1 SQL query and output it all into JSON too directly from that same query.

[MrSofazocker]

20:49 In the php world, its common to have your endpoint for users accept query params to supplement additional fields on the request, which are themselves their own endpoints with authorization already included, (bcs they are their own seperate endpoints), but you can thus essentially make multiple requests with a single request from the client and get the combined data of both.
For example, a user, and its posts. They are separate endpoints.
But the user endpoint accept a param to supplement the user, data to include the users posts.
Just like that.
Also, rate limiting as a package lmao

[Edwin-nlqu]

Out all of the shitposting I've done over the years, the one tweet that got me mobbed on was basically saying exactly this back in 2022.. maybe with a little more color.

[rthomasv]

As a backend developer with a big focus on database, query design, and security, GraphQL has always worried me. And the more I learn about it, the more I'm glad I decided not to use it.

[MadsterV]

What I like about GraphQL: you can track which data is being consumed, which added to tracking request source lets you track how information flows across your app, spot possible optimizations and speed up deprecation. With proper instrumentation, you'll do magic.
What I don't like about GraphQL: code generation, additional load and effort, tying up all the infra to an additional standard, security complexity skyrockets.

Unoptimized lookups is not a GraphQL problem, it's a design problem.

[sbogdaniuk]

Our BE team: We can't in GraphQL, we will use REST. Period!

[O_Eduardo]

For the majority of developers seeing this video.... just use rest, thank me later.

[Grumpicles]

My one gripe is the argument right at the end about "front-end bugging back-end" in non-GraphQL APIs.

I live in the SME world where we're either full-stack doing both, or, we collaborate and "bugging" people is an advantage becuse it leads to a thoughtful architecture where back-end understands how their services are actually being used.

As developers we dont just "write code and call stuff". Everything is done with intent and should ve done thoughtfully.

[killswitch.]

19:08 Great job by your editor with the seamless transition...as I watched this on stream, it's so different I almost didn't notice

[lcarsos]

13:37 no it's okay Theo. You're completely correct. Requiring every developer talk to every team for every graphql query they're going to make to get the green light that you won't take down the whole service absolutely does not scale. Shame on that team.

[abc]

I think that REST with well documented Open API, or even better auto-generated Open API from backend code is the superior solution in combination with auto-generated API client from the Open API on the front-end, I guess literally every front-end technology/language has ability to generate such client. So basically we are receiving features declared by GraphQL and tRPC (I mean synchronization between FE and BE) without huge performance losses (In case GraphQL with Node.js) or without Typescript vendor lock with tRPC

[gamerzero]

"now you're building crazy DIY rate limiters" - Dude's clearly never used any full-featured backend framework. Pretty much all of them have that for graphql

[PhilipAlexanderHassialis]

0:10 - let me fix this for you. If you have a DESIGN DOCUMENT that SPECIFIES the REST API signatures and the back / front teams are communicating, then you don't need a monorepo, you don't need the same language, you don't need anything. Just a proper Tech Lead who will OWN and ENFORCE this document and an Architect who oversees the whole thing.

But I guess, having people actually talk and create design documents is too much these days, huh?

[jarrodhroberson]

just like “every slow car handles well” “every tech works well with every trival application”

[cyneostudio]

I'm using GraphQL in production since 5 years, it's always one of my favorite technology ❤❤