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

551–560 of 721 posts

Re: After 6 years, I'm over GraphQL

#551

Post by rbalicki »

teaearlgraycold wrote: post #527
rbalicki wrote: post #522

Earlier quoted context omitted.

GraphQL gives you the ability to compose fragments, so if the UserDetail component and UserPaymentInfo component both use the user’s name, it is loaded once. With ad hoc solutions like tRPC, you end up fetching the same field multiple times (and probably doing some sort of network waterfall), or you give up on data masking and composability. And if you have enough engineers, data masking and composability are critica…

swr can handle the first issue you mentioned just fine.

I'm not sure I follow. Are you saying swr allows for fragments and deduplication?

If you don't have fragments (in particular, if you have a single call to an swr hook at the root), then you have implicit deduplication. But then you run into the issue of it being unclear whether you can remove a given field when a subcomponent stops using it — you have to check whether any other subcomponent happens to use that.

And if you have many separate queries, you're architecting in waterfalls. But you have clarity about who uses which field.

Re: After 6 years, I'm over GraphQL

#552

Post by squidsoup »

yCombLinks wrote: post #391
azangru wrote: post #180

Earlier quoted context omitted.

Odd, I thought I saw something about React in Microsoft's communications as well. Anyway, here is the horse's mouth: https://toot.cafe/@slightlyoff/112521248529973776

The options we have today are not the options we had at the time Facebook introduced React. React solved tons of browser shortcomings that are finally being fixed in the actual browser.

I don't think that's true, web components are not equivalent to libraries like react and vue.

Re: After 6 years, I'm over GraphQL

#553

Post by rezonant »

I have never bought the GraphQL hype, but have never explained my rationale as well as this article does. Kudos Matt on succinctly nailing the issues here.

As for how to tackle things today, I alternate between REST+OpenAPI and RPC models for communication. I am certainly biased as I have my own typed open source RPC library (Conduit) which is layered on top of arbitrary message passing transports such as WebSockets, but as of yet it's only suited for Typescript-based clients -- REST+OpenAPI is a better fit for an API with many consumers.

But for dynamic client/server and client/client single-implementor communication needs, I go with RPC.

Re: After 6 years, I'm over GraphQL

#554

Post by jhatemyjob »

nprateem wrote: post #110

I'm surprised it took 6 years to discover these issues. The N+1 problem and auth/field privacy are obvious on practically any project. In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.

Are you really surprised though? Like you alluded, people use Kubernetes and Bazel just because it has the big ol' G stamp on it. GraphQL is no different

(Well... slightly different. It's the FB stamp, not the G stamp)

Re: After 6 years, I'm over GraphQL

#556

Post by rezonant »

vdfs wrote: post #512
awongh wrote: post #478

Earlier quoted context omitted.

I’ve only been a consumer of a GraphQL API, so I don’t know what it’s like to maintain, but I mostly enjoyed using it. Of course the documentation on some kinds of query syntax was too sparse, (this is for Shopify) but I could see how it might be nice for certain kinds of cases. If you run a platform it might be a good option to offer in your API. For shopify afaik there are equivalent calls in both REST and graphql…

> equivalent calls in both REST and graphql so you have options. It's not that simple, new features are add to GraphQL only, some other things are REST only,some APIs work differently (like product search by title, in REST it have to be an exact match, in GQL it can be partial match)

This has been my experience when integrating with a vendor's APIs where they've been bit by the GraphQL bug. They have a full featured, stable and easy to use REST API, and then a poorly implemented GraphQL solution that doesn't cover all the use cases of the original API, and new features only appear in the GraphQL schema, so you have to be stuck using both and it's a horrible experience.

I'm also not personally a fan of having my API queries on the frontend span multiple lines for things that with a good REST design with OpenAPI are a single method call, but all too often the calls I would need to make to the vendor's GraphQL API were exactly this: did not make use of any of GraphQL's query features, and were effectively just RPC calls.

Re: After 6 years, I'm over GraphQL

#557

Post by rezonant »

albertgoeswoof wrote: post #515
pas wrote: post #495

Earlier quoted context omitted.

Can you elaborate on lack of syntax docs? As far as I understand one of the big big huugge benefits of GraphQL is that you get the strongly typed schema via the introspection query, so you can build queries with some confidence, that as long as the schema (version) is the same it should be syntactically okay. What did Spotify do compared to this?

This is one of the problems with graphql, there are no docs because the schema is all you need. But that assumes the schema is logical and consistent, which it rarely is. It also means you need to be an expert in the tooling to figure it out, so just dropping in to a graphql api is so frustrating compared to plain old rest

Also there is no standard for exposing the schema, and sometimes there isn't a schema at all. Sometimes a vendor will have the schema downloadable from their dev docs, sometimes it will be an endpoint that serves it up, and sometimes they just don't give it to you and expect you to use GraphQL Explorer directly to discover what you can do. When I encountered this I figured surely GraphQL Explorer must be fetching the schema, but I guess this is not always the case, as I never was able to get a complete schema that worked with the tooling. For that vendor, there was no way to generate client code for the schema using one of the many GraphQL client library generator frameworks.

Re: After 6 years, I'm over GraphQL

#558

Post by subsaharancoder »

lcnmrn wrote: post #435
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

Someone like you made me quit my first job as developer. He implemented a Clojure + GraphQL nightmare.

Did the person use Lacinia? https://lacinia.readthedocs.io/en/latest/index.html

Re: After 6 years, I'm over GraphQL

#559

Post by nprateem »

jhatemyjob wrote: post #554
nprateem wrote: post #110

I'm surprised it took 6 years to discover these issues. The N+1 problem and auth/field privacy are obvious on practically any project. In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.

Are you really surprised though? Like you alluded, people use Kubernetes and Bazel just because it has the big ol' G stamp on it. GraphQL is no different (Well... slightly different. It's the FB stamp, not the G stamp)

I'm surprised it took so long.

I worked with k8s and realised pretty quickly it was pointless for my org.

Re: After 6 years, I'm over GraphQL

#560

Post by doctor_eval »

meowtimemania wrote: post #412
Izkata wrote: post #163

Earlier quoted context omitted.

From https://graphql.org/learn/queries/ This isn't even close to valid json: { empireHero: hero(episode: EMPIRE) { name } jediHero: hero(episode: JEDI) { name } }

i agree with this. Writing queries is the most annoying part of graphql

I can’t imagine how annoying it would be if we had to write queries in JSON!

writing queries is stupid easy if you use a tool like GraphIQL especially with the explorer.

Post reply on HN