Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

71–80 of 721 posts

Re: After 6 years, I'm over GraphQL

#71

Post by bluehatbrit »

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.

Re: After 6 years, I'm over GraphQL

#72

Post by anonzzzies »

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.

Re: After 6 years, I'm over GraphQL

#73

Post by probabletrain »

jvans wrote: post #50

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

> clients create re-usable fragments for every object in the system and use it everywhere

I quite like Relay's pattern where components define their data requirements, and this is passed up the component tree to some query at the root. Avoids a situation where the query defined at the root asks for unnecessary fields because it's so far away from where the data is actually required.

https://relay.dev/docs/principles-and-architecture/thinking-...

Re: After 6 years, I'm over GraphQL

#76

Post by FrustratedMonky »

sswaner wrote: post #55
FrustratedMonky wrote: post #39

Earlier quoted context omitted.

Curious, I hadn't heard that take on Mongo. Do you have a link to some more info on this.

https://youtu.be/b2F-DItXtZs?si=rxrMwJVu95WQQt7M

That is pretty funny, But that video is 11 years old. It can't still be like that? can it? Seems like people are down on Mongo in the last year, and I'm trying to catch up.

Re: After 6 years, I'm over GraphQL

#77

Post by CharlieDigital »

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.

Re: After 6 years, I'm over GraphQL

#78

Post by brabel »

0-bad-secrotrs wrote: post #64

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.

Our frontend team needs to show the whole thing every time (as the user sees and edits full resources in most cases), which means they MUST keep a full query representing the entire resource, and when we add stuff in the backend, they must also add those things in the frontend (as they cannot generate UI for new things in most occasions). GraphQL was really a mistake for us.

Re: After 6 years, I'm over GraphQL

#79

Post by otabdeveloper4 »

lpapez wrote: post #25

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

Mongo is great if you want a distributed replicated log. Existing tools sorely lack. (Postgres and Kafka are broken by design.)

Re: After 6 years, I'm over GraphQL

#80

Post by hakanderyal »

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.

Post reply on HN