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

501–510 of 721 posts

Re: After 6 years, I'm over GraphQL

#501

Post by RussianCow »

hansonkd wrote: post #246
datavirtue wrote: post #226

Earlier quoted context omitted.

It's analogous to a specific method in code. No idea why people go nuts over this.

A REST endpoint can be analogous to a specific method in code. just as much as a GraphQL field. What people are excited about is that the frontend can request all the data it needs at once and the backend can efficiently serve it. Something not possible with REST without reimplementing something similar to GraphQL.

It's definitely possible, just not without tight coordination between frontend and backend. When your development teams are broken into silos with strong separation, this isn't feasible and GraphQL starts to make some sense. Otherwise, you just create an ad hoc endpoint that serves the exact data you need and call it a day.

Re: After 6 years, I'm over GraphQL

#502

Post by [deleted] »

gmassman wrote: post #283
dventimi wrote: post #134

I generally agree and am likewise "over" GraphQL. Having said that, I disagree on some of the finer points. First, some of these issues--authorization, security, N+1--can be mitigated by using something like Prisma, PostGraphile, or Hasura, instead of crafting GraphQL backends with code. Second, there are gains to be made by compiling a GraphQL operation to a single operation in the underlying database's query langua…

I don’t want to overly generalize, but N+1 problems are very real and frequently occur in code written by more junior developers. Their impact and occurrence rate are dependent on the nature of the application though. I also think there’s an avoidance to simply “translate” a GQL query into an SQL query. Not that it can’t be done, but it allows a lot less flexibility in the backend as far as code patterns that can be…

[deleted]

Re: After 6 years, I'm over GraphQL

#504

Post by kabes »

BillyTheKing wrote: post #5

GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api a…

True, but rest calls over multiple micro services is even worse

Re: After 6 years, I'm over GraphQL

#505

Post by esafak »

hinkley wrote: post #350
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…

I knew we were in trouble when we started having to sort the query criteria in order to support caching of requests. If I use graphQL again it’ll only be for admin features. Anything where very few users will use it and very infrequently. Preferably in spots where caching works against the workflow. OLAP vs OLTP. GraphQL is really about reducing friction between teams. High functioning distributed systems all have tw…

what's work stealing?

Re: After 6 years, I'm over GraphQL

#506

Post by nielsole »

troupo wrote: post #390
abound wrote: post #119

Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me. One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already '…

> the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. Then it's just REST with extra steps and none of the benefits

As this is being downvoted can someone explain why this wouldn't be true? One of the core tenets of graphql was not having to involve the backend team, wasn't it?

Re: After 6 years, I'm over GraphQL

#508

Post by kabes »

Except, the alternatives he presents aren't alternatives.

And for each issue he mentions that rest doesn't have said issue is basically because rest doesn't have the feature at all.

You could use graphql the same way as rest (by exposing queries without allowing to specify fields) and you still have a better rest, since at least the response has a schema out of the box.

Re: After 6 years, I'm over GraphQL

#510

Post by mocamoca »

If someone from Shopify's backend team is around, i would love to know how difficult it is to maintain/improve the GraphQL API It looks like Shopify is deprecating REST in favor of GraphQl so is the developer UX that good for Shopify developers? And btw some features are missing from the GraphQL related to REST. I wonder if that's related to hard-to-implement features or good-occasion-to-delete features (Eg Checkout)
Post reply on HN