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

301–310 of 721 posts

Re: After 6 years, I'm over GraphQL

#301

Post by hot_gril »

BiteCode_dev wrote: post #95
zer00eyz wrote: post #2

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

No, GraphQL makes sense at facebook because at their scale, dealing with the consequence of allowing all possible queries was less work that having to create dedicated enpoints for all the possible client queries. People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server. Which in a app and team as huge as facebooks' made sense, especially since they hav…

Yep, GQL can make sense if you have tons of clients.

Re: After 6 years, I'm over GraphQL

#302

Post by eatsyourtacos »

hombre_fatal wrote: post #133
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.

The difference is that the client came up with its own data access patterns instead of having to rely on the server to design the exact endpoints that it needs. Overfetching or not, that's a rather big difference.

Sure, but just how often is the client the one who defines what data it needs without the designer being able to create obvious endpoints?

Surely there are some good use cases.. just so few and far between. No one should be using GraphQL unless absolutely necessary.

Re: After 6 years, I'm over GraphQL

#303

Post by [deleted] »

probabletrain wrote: post #85

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

[deleted]

Re: After 6 years, I'm over GraphQL

#304

Post by hot_gril »

probabletrain wrote: post #85

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

I use Express for my web server and OpenAPI for the schema, which works like a charm.

Re: After 6 years, I'm over GraphQL

#305

Post by eatsyourtacos »

tossandthrow wrote: post #238
chasd00 wrote: post #151

Earlier quoted context omitted.

If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?

Indeed, this is what graphQL solves. Are you proposing just to add new field to a JSON response, even though they are not needed?

>Are you proposing just to add new field to a JSON response, even though they are not needed?

That is exactly what OP is proposing and it makes total sense. More data != bad. Just ignore if you don't need it. For 99.999% of cases the bandwidth of extra data is entirely negligible.

For business cases you just want to get things done. If the server has added more data, which is obviously relevant in some regard, you can see it and might want to use it etc. With GraphQL you are completely stuck without SPECIFICALLY requesting it. That means every client needs to know about the new data and specifically request it. In theory that might sound like it makes sense, but in practice this is virtually never the case.

Give me all the data and I'll use what makes sense.

Re: After 6 years, I'm over GraphQL

#306

Post by mbleigh »

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.

Re: After 6 years, I'm over GraphQL

#307

Post by merrywhether »

adeptima wrote: post #257

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…

Given that GraphQL makes much more sense for big orgs, I wouldn’t be surprised if much of that code is locked up in private repos that LLMs can’t get to.

Re: After 6 years, I'm over GraphQL

#308

Post by tarentel »

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.

We do something similar and it's because GQL at my company is really pointless. I think someone at some point someone also got on the hype train not realizing that we do not really need to have hyper specific queries we can write on the fly. I can't think of a single instance where someone proposed a feature and we all went well, we can combine these 3 things we already have into a new query and the backend has no work to do. The backend always ends up building out more into graph and have been doing so for at least 6 years now. There have been a handful of cases where we did combine something old with something new but given the extra complexity on the client and backend I'm not sure it was worth it over making 2 separate calls.

Re: After 6 years, I'm over GraphQL

#309

Post by nevir »

RedShift1 wrote: post #81
brabel wrote: post #78

Earlier quoted context omitted.

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.

Why is this a problem? If you add fields on a REST endpoint, you're going to have to change the client too to deal with those new fields.

One problem is performance.

(Most) GraphQL clients are optimized for relatively small/simple objects being returned, and you typically pay a cost for every single edge (not node) returned in a response / cached in memory.

It can quickly get to the point where your project is spending more time per frame processing GraphQL responses & looking data up from the cache than you spend rendering your UI

Re: After 6 years, I'm over GraphQL

#310

Post by blowski »

kiney wrote: post #196
hansonkd wrote: post #177

Earlier quoted context omitted.

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

I’ve heard this called the “backend-for-frontend” pattern.
Post reply on HN