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

141–150 of 721 posts

Re: After 6 years, I'm over GraphQL

#141

Post by silentguy »

jamesrr39 wrote: post #6

I agree with the article, and want to add on that the browser network debugging tools are a pain to use with GraphQL (every request to /api/graphql, can't even quickly filter by endpoint name). I landed instead on OpenAPI, which can feel like a bit of a hoop to jump through sometimes when writing endpoints (but then, so can GraphQL), but the result is equally nice. And it's much easier to get authorization right with…

There are browser extensions which make it easier to debug grapgql. A new pane is added to the browser debug panel. Last I used them more than two years ago, it was still not as good as the built-in network tab for rest queries. Still better than the default for the graphql queries.

Re: After 6 years, I'm over GraphQL

#142

Post by dventimi »

mst wrote: post #107
purge wrote: post #27

many of these concerns are mitigated by ensuring you are using trusted documents ( https://benjie.dev/graphql/trusted-documents )

Seems like at that point exposing each query as an OpenAPI endpoint would achieve pretty much the same thing. Then again having GraphQL as the definition for them is probably still not bad, I'll just have to write something that converts them to SQL::Abstract 2 trees once I get around to porting it to TS.

It would be the same thing except with Benje's approach, you're basically using GraphQL as a developer tool to create those end points instead of writing code to do it.

And you don't have to write something to convert them to SQL if you're using PostgreSQL, because Benje's already written it for you.

Re: After 6 years, I'm over GraphQL

#143

Post by dcre »

“the main thing your frontend devs like about GraphQL is its self documenting type safe nature”

I’ve been saying this for years: fetching multiple things in one query is not something normal-scale apps care about. What devs like about it is client generation and type safety. So OpenAPI, for all its flaws, covers that. GraphQL’s schema language is much more beautiful — hopefully Microsoft’s TypeSpec will take off and we can have the best of both worlds.

https://typespec.io/

Another point implicit in the piece but not quite stated is that GraphQL aims to make something nice for the API consumer, but the implementation side is a nightmare. It is not worth the tradeoff because eventually, that nightmare leaks out to the consumer because it is too hard to make improvements to the API.

Re: After 6 years, I'm over GraphQL

#144

Post by dventimi »

santiagobasulto wrote: post #11

Fully agree with the article. I think the summary is that GraphQL was a great idea from the frontend's perspective, but it was never fully worked out from a backend's standpoint.

Hasura, PostGraphile, and Prisma do make it quite a bit easier for the backend.

Re: After 6 years, I'm over GraphQL

#145

Post by [deleted] »

tomrod wrote: post #101
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 haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?

[deleted]

Re: After 6 years, I'm over GraphQL

#146

Post by ctvo »

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 was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.

performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> child component).

Comparing the above to ng with its dependency injection, MVC style approach to UIs, that used HTML based annotations and tags to sprinkle in functionality (`ng-if` baby) -- it was a much more simple way to build web applications.

React's style of building UIs has largely won. Vue, etc. all follow this component with composition view of the world.

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

Webpack has nothing to do with React. React has always had good documentation. The reason the documentation was good in the beginning was because the API surface area was tiny compared to Backbone, Ember, ng, etc..

I'm not going to go point by point here. You sound like you have a very superficial understanding of the space.

I'm going to hard pass on clicking a marketing link to your blog.

Re: After 6 years, I'm over GraphQL

#147

Post by friendzis »

strken wrote: post #127
BiteCode_dev wrote: post #99

Earlier quoted context omitted.

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.

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.

Re: After 6 years, I'm over GraphQL

#148

Post by diggan »

vitiral wrote: post #136

I've read the article and a few of the responses but have never used GraphQL. However I have a question Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc? So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.

> Would it be fair to say that GraphQL is extremely useful for internal-only clients?

Compared to what? If you're feeling really safe about the "internal-only" parts, just expose an endpoint to allow SQL (read) queries and you'll get essentially the same thing, especially if your data store already is SQL-like.

Re: After 6 years, I'm over GraphQL

#149

Post by tuan »

DanielHB wrote: post #47
atsjie wrote: post #24

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…

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…

> GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams)

What do you mean by "backend developer" ? The one who creates the GraphQL endpoints for UI to consume ?

Re: After 6 years, I'm over GraphQL

#150

Post by afavour »

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…

Obviously depends on the API but a REST API that maps relatively cleanly to database queries is going to make it very clear on both the client and the server when it’s not scaling well.

If, at page load, I’m making 100 HTTP requests to fetch 100 assets then as a client side developer I’m going to know that’s bad practise and that we really ought to have some kind of multi-get endpoint. With GraphQL that gets muddy, from the client side I’m not really sure if what I’m writing is going to be a massive performance drag or not.

Post reply on HN