Hacker News Reader

Comment by jimmcslim | Hacker News Reader

I understand the GraphQL has fallen out of favour somewhat, but wasn’t it intended to solve for this?

It can't fall out of favor if it was never really in favor to begin with. GraphQL was a quite brief hype then a big technical debt.

Interesting take considering graphql adoption is growing and generally in favor at my company.

So if not graphql, then what's the latest "in-favor" thinking to solve the problem of underfetching and overfetching? Especially in an environment with multiple kinds of frontends?

What do you mean by technical debt here?

Everywhere I worked with GraphQL it was always a pain for the backend team to keep the graphql server updated and also a pain to use in the frontend, simple REST apis or JSON-RPC are much better.

Interesting. Why did you not have these pains with other tech? Team unfamiliar with GraphQL?

> Why did you not have these pains with other tech?

You don't need a new layer between database -> backend -> frontend

So GraphQL became a backend-for-frontend layer that needs maintaince. The team knowing GraphQL or not is not what causes this, but definitely makes it worse as they use the tool, which is quite complex, wrongly.

NextJS is the "evolution" (or more like growth? as a tumor) of this backend-for-frontend approach, glued with the mentioned RSC in this post. Great recipe to fight accidental complexity all days and nights.

So because they were not generating resolvers from the schema, a maintenance burden was created. You CAN create resolvers manually but that’s really not the best idea when automated approaches exist. That’s poor engineering, not bad technology.

GraphQL federation is where the thing really shines.

From what I recall, GraphQL has a feature that's similar (@defer) but I'm not familiar enough to compare them. RSC was definitely inspired by GraphQL among other things.

The GraphQL payload has redundant copies of the objects within. Relay has an experimental (dead) exploration of normalising data on the server[1] in order to avoid that transport cost.

For @defer, the transport is a stream[2] where subsequent payloads are tracked ("pending") and as those payloads arrive they are "patched" into the existing data at the appropriate path.

Both of these are effectively implementations of this Progressive JSON concept.

I can picture a future where both the JSX and object payloads are delivered progressively over the wire in the same stream, and hydrate React and Relay stores alike. That could potentially simplify and eliminate the need for Relay to synchronise it's own updates with React. It would also potentially be a suitable compile target for decoupling, React taking ownership of a normalised reactive object store (with state garbage collection which is a hard problem for external stores to solve) with external tools like Relay and TanStack Query providing the type-generation & fetching implementation details.

Using `new Promise()` in the client-side store would also mean you could potentially shrink the component API to this. `useFragment(fragment IssueAssignee on Issue { assignee { name }}, issue)` could instead be `const assignee = use(issue.assignee)` and would suspend (or not) appropriately.

[1]: https://github.com/facebook/relay/blob/main/packages/relay-r...

[2]: https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferSt...

For serialization GraphQL uses ... JSON.

GraphQL could use Progressive JSON to serialize subscriptions.

I think the point is that GraphQL solves the problem, a client only actually needing a subset of the data, by allowing the client to request only those fields.

Reply on news.ycombinator.com