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

151–160 of 721 posts

Re: After 6 years, I'm over GraphQL

#151

Post by chasd00 »

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.

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?

Re: After 6 years, I'm over GraphQL

#152

Post by swader999 »

dopylitty wrote: post #129
projectileboy wrote: post #100

Earlier quoted context omitted.

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

Construction is always the wrong metaphor for sw dev.

Think more like marketing campaign or product design.

Re: After 6 years, I'm over GraphQL

#153

Post by jpalawaga »

DanielHB wrote: post #116
dudeinjapan wrote: post #57

Earlier quoted context omitted.

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…

> It is far better for the Backend to provide Frontend a contract It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3). > This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. I…

trying to solve org problems with tech just creates more problems, allthewhile not actually solving the original problem.

Re: After 6 years, I'm over GraphQL

#154

Post by dartos »

Has anyone use graphql for service to service communication?

Seems really great to not have each service adhere to another service’s potentially unstable api contract.

Especially if that service is owned by another team.

Re: After 6 years, I'm over GraphQL

#155

Post by jerf »

strken wrote: post #121
BiteCode_dev wrote: post #92

Earlier quoted context omitted.

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…

There's a lot of relevant differences between REST & GraphQL. It is possible to construct a REST endpoint that simply can't do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of "all posts ever" is not uncommon, and clients won't be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in quantity that is itself a change in quality. Hypothetically, both approaches are vulnerable to all the same issues, but GraphQL is far more vulnerable.

Re: After 6 years, I'm over GraphQL

#156

Post by gedy »

dudeinjapan wrote: post #57
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…

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…

> the Frontend is allowed to send any possible query to the Backend

It's really not, it's not exposing your whole DB or allowing random SQL queries.

> It is far better for the Backend to provide the Frontend a contract

GraphQL does this - it's just called the GraphQL "schema". It's not your entire database schema.

Re: After 6 years, I'm over GraphQL

#157

Post by Izkata »

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

> React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time.

Webpack wasn't how it started, remember gulp?

Also don't forget the switch from class components to functions, then inventing "hook" functions to reintroduce functionality that already existed in the class components.

For the past few years I've been on a team that handles a legacy system from long before React existed (internal) that just renders HTML directly, a client website that uses Backbone, and a newer client website that uses modern React. The old internal one that doesn't use any frontend frameworks has been by far the nicest to work with, and Backbone the worst.

I think that's some missing context as well - React+Redux was much better than what came immediately before it, for complex web apps. But when you're not building something like that, yeah, both are worse. It just doesn't seem like the Backbone era encouraged people to use it for everything, unlike React.

Re: After 6 years, I'm over GraphQL

#158

Post by diggan »

azangru wrote: post #124
chrisandchris wrote: post #115

Earlier quoted context omitted.

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...

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

Maybe I'm missing something obvious, but React isn't mentioned in that post. Maybe you put the wrong URL?

Re: After 6 years, I'm over GraphQL

#159

Post by fire_lake »

dudeinjapan wrote: post #57
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…

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…

A GraphQL schema is a contract though.

And the REST API can still get hammered by the client - they could do an N + 1 query on their side. With GraphQL at least you can optimize this without adding a new endpoint.

Re: After 6 years, I'm over GraphQL

#160

Post by strken »

friendzis wrote: post #147
strken wrote: post #127

Earlier quoted context omitted.

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.

The problem with XML is precisely that it is so much more than simple hierarchical, nested trees of data. The fact that in a casual conversation XML is reduced to hierarchical trees of data pretending the rest of XML does not exist more than proves OP's point.

I'm not pretending anything and I hate XML. I would still rather use it than HL7, because it's a hierarchical tree of data and HL7 is not. OP's point is that almost nobody wants to use XML anymore; my point is that almost nobody wants a Ford Model T as their daily driver anymore either, and yet it was still the future, in a certain sense.
Post reply on HN