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

121–130 of 721 posts

Re: After 6 years, I'm over GraphQL

#121

Post by strken »

BiteCode_dev wrote: post #92
DanielHB wrote: post #47

Earlier quoted context omitted.

GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a…

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…

I'm not sure this is any more or less of a problem for REST APIs. What if your engineers change $client/$server and the new version makes really expensive queries? Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don't take anything down, monitor new releases and roll back if anything breaks, etc.

If you're providing an external API like GitHub does, then that's a different story and I agree.

Re: After 6 years, I'm over GraphQL

#122

Post by em-bee »

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.

depends. i'd be writing the client such that it just lists all the fields, and then add special handling for the fields that need it. when the backend adds new fields, they will just show up and i just need to fix the formatting. with graphql i'd have to ask for those new fields, and thus make changes in two places. and in addition the backend team has to tell the frontend team about the new fields (instead of letting the api speak for itself), making it easier to accidentally skip a field.

Re: After 6 years, I'm over GraphQL

#123

Post by unsupp0rted »

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.

Re: After 6 years, I'm over GraphQL

#124

Post by azangru »

chrisandchris wrote: post #115
azangru wrote: post #112

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.

What do you dislike about React?

Performance. Alex Russell, formerly of Google and now the product owner of Microsoft Edge loves to rant about it. His latest rant is how Edge has significantly improved the performance of some of its UI features by moving off React [0].

[0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste...

Re: After 6 years, I'm over GraphQL

#125

Post by Jeema101 »

dzonga wrote: post #88

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

I think an aggravating factor in the software world (that's maybe not as prevalent in other fields), is that developers tend to want to use the latest and newest technologies, even if said technology is not really appropriate for the task. It looks good on your resume to say that you used the same technology Facebook uses - the ol' "resume driven development".

Re: After 6 years, I'm over GraphQL

#126

Post by FridgeSeal »

otabdeveloper4 wrote: post #79
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.)

Curious as to why you think Kafka is broken by design?

Re: After 6 years, I'm over GraphQL

#127

Post by strken »

BiteCode_dev wrote: post #99
yonixwm wrote: post #90

Earlier quoted context omitted.

That’s the problem. In the days of jQuery/Angular2 (and even now personally), React was a blessing. Everyone hoped the same here. We should just join technology a little later on the hype cycle and have less stress.

React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason. That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time. I remember above all that: - React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.…

XML was genuinely better than fix-width data formats (COBOL) or character-separated fields (CSV, HL7) for most APIs. Hierarchical deeply nested trees of data were the future. Everyone uses JSON or a more industrial format like protobuf/avro/BSON to represent such data now, but it wasn't necessarily wrong to point at XML and say it was an improvement.

Re: After 6 years, I'm over GraphQL

#128

Post by travellingprog »

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

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

Re: After 6 years, I'm over GraphQL

#129

Post by dopylitty »

projectileboy wrote: post #100
dzonga wrote: post #88

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

Exaaaactly. I worked on big systems at a very large retailer, and at a very large bank, and in each case, there were reasons why GraphQL worked very well for us. But 90+% of developers across the world adopt tools and technologies because they look fun and shiny, not because they need it. For the overwhelming majority of developers (who in most cases are working at medium-to-large-sized companies on internally-facing…

I wonder if this phenomenon happens in other industries as well.

I can't imagine a road crew getting away with spending an extra year to build a road because they decided to use completely nonstandard equipment that doesn't work well for the task or they don't know how to operate. I especially can't imagine the road crew screwing up multiple jobs in a row because they change equipment every time they're starting to understand the current equipment.

Maybe it does happen though and I just haven't seen it since I'm not in that industry.

Re: After 6 years, I'm over GraphQL

#130

Post by jvans »

RedShift1 wrote: post #67
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…

* Not null fields in a distributed system are a lie If something is null that's not supposed to be null, then the entire operation should be called into question. It's probably not safe to proceed so it's a good thing he entire page breaks, you don't want users to continue based on wrong information. If you define something in the schema that it's possible that it's null, but then the frontend dev ignores the fact th…

The problem with not null is people classify them from a domain perspective and not from a distributed systems perspective where basically everything can be null but only some fields mean rendering the page is impossible. It also depends page by page what fields make it unrenderable
Post reply on HN