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

81–90 of 721 posts

Re: After 6 years, I'm over GraphQL

#81

Post by RedShift1 »

brabel wrote: post #78
0-bad-secrotrs wrote: post #64

Aside from all the valid points listed in the blog I found out that the frontend engineers in my company save some queries in central library and reuse them even if they don't need all the field returned by this array just to save themselves the time they spend writing queries so they are basically using GraphQL as REST at the end and now we have the worst of both worlds.

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.

Re: After 6 years, I'm over GraphQL

#82

Post by brabel »

RedShift1 wrote: post #67
jvans wrote: post #50

Additional graph pain points I'd add: Reliability: * Not null fields in a distributed system are a lie. Clients write code assuming something is not null, so a query that fetches data from N sub systems breaks the entire page when one of them fails. Performance: * People say you only need to fetch just what the page wants but in practice clients create re-usable fragments for every object in the system and use it eve…

* Not null fields in a distributed system are a lie If something is null that's not supposed to be null, then the entire operation should be called into question. It's probably not safe to proceed so it's a good thing he entire page breaks, you don't want users to continue based on wrong information. If you define something in the schema that it's possible that it's null, but then the frontend dev ignores the fact th…

About nulls: you're right, but because of authorization, everything can be null - if you don't have access to something, we need to remove it from the result (instead of just throwing an error, as you may still get enough information to do what you need to do) - and that will always be a fetcher error in GraphQL if the field was non-nullable. And because you shouldn't really know or care beforehand which fields may be "hidden" from the end user due to authorization, you need to make everything nullable or risk making a breaking change later.

Re: After 6 years, I'm over GraphQL

#83

Post by oreoftw »

Exposing bare GraphQL the right way can be challenging, totally agree with author on that. Using it on a small project also can be an overkill.

But at the same time it doesn’t have to be that bad. I don’t have this array of issues because I do: - query whitelisting for performance and security, - data loading to avoid n+1, authentication with whatever works(session cookies, tokens), - permission check based on the auth context in a resolver.

It works decently for us, allowing to stay away from getting into ESB. Yet have some shared domain, type safety, and easy integration of legacy and new systems/services.

I would say a bigger issue for us was to keep it all nicely organized / designed in terms of types and api contracts. But that’s manageable.

Re: After 6 years, I'm over GraphQL

#85

Post by probabletrain »

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits:

- If data already exists in cache, a query will return that data instead of making a network request.

- Everything that has a data dependency on something in the cache will automatically update when the data is updated, e.g. after a mutation.

- Cache data can be optimistically updated before the request completes, UI that queries this data will automatically update.

- Components will automatically refetch data if they need to, e.g. if an object is partially updated.

The pain points are pretty painful though:

- Really hard to debug unexpected refetches.

- Normalizing the data for the cache comes at a cost, it can be pretty slow for big responses.

- You quickly realise you need to really understand how the client works under the hood to be productive with debugging/complex behaviour.

I see it as a case of "this is the worst API/client, except for all the others". I'm curious to hear how people using non-graphql APIs are managing data in the client in web-apps with complex data needs?

[1] https://www.apollographql.com/docs/react/why-apollo [2] https://relay.dev/

Re: After 6 years, I'm over GraphQL

#86

Post by pjfii »

purge wrote: post #27

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

Yeah, we use Hot Chocolate with .NET where it is called Persisted Queries.

https://chillicream.com/docs/hotchocolate/v13/security

Honestly most of the "problems" the OP discusses has solutions in the documentation.

Re: After 6 years, I'm over GraphQL

#87

Post by discreteevent »

rockyj wrote: post #14
noduerme wrote: post #9

Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.

Not a fan of GraphQL (the problems mentioned in the post are very real), but GraphQL specification does not say anything about the DB design / queries. It is still an API layer and you are free to model it in any way you want.

Indeed, from one of the authors of graphQL on this very forum:

"That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1]

"GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2]

[1] https://news.ycombinator.com/item?id=9879870

[2] https://news.ycombinator.com/item?id=14351800

Re: After 6 years, I'm over GraphQL

#88

Post by dzonga »

when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems.

There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firms etc. Some just use REST + JSON or RPC + JSON.

Wish us an industry would read Joel's Spolsky's Fire and Motion article: While you're fighting tools built by FB you're not making stuff for your customers.

Revenue / Profit >> Tech

Re: After 6 years, I'm over GraphQL

#89

Post by RHSeeger »

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…

Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but

- Each individual thing available in the request should be no less timely to handle than it would via any other api

- Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller; the same way it would be if they made multiple REST calls

Do you have an example of a call to a GraphQL API that would be a problem, that wouldn't be using some other approach?

Re: After 6 years, I'm over GraphQL

#90

Post by yonixwm »

dzonga wrote: post #88

when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems. There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firm…

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.
Post reply on HN