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

GraphQL kinda sucks

news.ycombinator.com

Post reply on HN
Print view View original

241–250 of 448 posts

Re: GraphQL kinda sucks

#241

Post by sonthonax »

GraphQL seems to be one of those 'bootcamp technologies'. I see it being advertised as a skill a bootcamp teaches more than I've ever seen used. I can imagine that for a junior developer the endless freedom might be quite paralysising.

What I don't understand about GraphQL, is that the majority of data people deal with is simple and relational. It's rare enough to have a deep (more than 4 layers) relational data structure that needs to be queried at once. And usually those data structures are relational to ever smaller relations; think user->company->address->country->county. Solving this with GraphQL just seems a bit bizarre when you can write a view of this data.

Maybe though, it owes its popularity in bootcamps because it allows unqualified developer to forget about writing the query layer.

Re: GraphQL kinda sucks

#242

Post by nkozyra »

spankalee wrote: post #239

Among the many problems with GraphQL are 1) That it doesn't deal in graphs, but trees, and 2) It's not a query language, but an RPC language with result subsetting I would love to see something similar to GraphQL that could return actual graphs. Like in the canonical Books/Authors example, a query over books that included the authors would return Books with _references_ into an Authors collection so that authors were…

> 1) That it doesn't deal in graphs, but trees, and 2) It's not a query language, but an RPC language with result subsetting

I'll resist pedantry on point one but I totally agree on point 2. Plus its syntax poorly reflects the data 'schema' it's defining.

Re: GraphQL kinda sucks

#243

Post by kbumsik »

makeitdouble wrote: post #179
mLuby wrote: post #76

Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have. It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to…

I used to see GraphQL (and to an uglier respect Soap like interfaces) as complicated solutions to that problem you describe. But more and more, I think Backend For Frontends solve this issue in a much better way. And of course that idea isn’t new and Yahoo for instance had that kind of architecture. Frontend teams get to adjust by themselves a simple interface to their needs, and backend teams can provide more info t…

You can use GraphQL for BFF btw.

Re: GraphQL kinda sucks

#245

Post by humbleMouse »

stickfigure wrote: post #232

The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…

That’s exactly what it is, a made up sql layer over sql exposing a special port. Ridiculous.

Re: GraphQL kinda sucks

#246

Post by oznog »

chpmrc wrote: post #36
jwr wrote: post #21

"Very Senior Dev" here (though it amuses me to call myself that). I had managed to avoid GraphQL for a while, but recently had to actually look at it and use it. I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. I was honestly surprised by this: when I first heard about the idea behind GraphQL, I was certain that I'd pass in nested data structures.…

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There…

> The quality of posts and comments here used to be a lot higher but it's slowly turning into a [..]

You can go on with your GraphQL, Kubernetes, gigantic frameworks, and pages with 3MB of JS if you want.

And let's see what stands the test of time.

Re: GraphQL kinda sucks

#247

Post by SnowHill9902 »

stickfigure wrote: post #232

The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…

> It's easy to construct a query which puts unreasonable load on your system.

Can you give an example?

Re: GraphQL kinda sucks

#249

Post by wes-k »

scottwick wrote: post #238

A frontend application that I work on has each component making separate tiny GraphQL queries to render just what it needs. The result is often 5-10+ GraphQL requests to render a single page. Is this a common practice? It seems like a lot of overhead to me since the backend has to perform some redundant queries (i.e. fetch and authorize the user, etc.) in order to serve each of those requests. I had thought one of th…

Use Apollo, it can stitch all those queries together into one deduped query. It’s awesome!

Re: GraphQL kinda sucks

#250

Post by [deleted] »

YZF wrote: post #192
danabrams wrote: post #150

Earlier quoted context omitted.

100% agree that it’s about dependence on other teams. That said, I’d much rather that we were communicating across a well defined api boundary, rather than a graphql api. You could, of course, very easily do this with an api layer in the middle.

Nobody seems to get the idea of building software out of pieces with well defined APIs any more . I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it. The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the te…

[deleted]
Post reply on HN