4 ms·

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

by jimmcslim 1y ago

delichon 1y ago
For serialization GraphQL uses ... JSON. GraphQL could use Progressive JSON to serialize subscriptions.
- Spivak 1y ago
  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.
owebmaster 1y ago
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.
- tunesmith 1y ago
  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?
- cluckindan 1y ago
  What do you mean by technical debt here?
  - owebmaster 1y ago
    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.
    - cluckindan 1y ago
      Interesting. Why did you not have these pains with other tech? Team unfamiliar with GraphQL?
      - owebmaster 1y ago
        > 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.
        cluckindan 1y ago
        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.
- RexM 1y ago
  Interesting take considering graphql adoption is growing and generally in favor at my company.
danabramov 1y ago
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.
tgasson 1y ago
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-runtime/store/RelayExperimentalGraphResponseTransform.js https://github.com/facebook/relay/blob/main/packages/relay-r... [2]: https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md#payload-format https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferSt...

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

delichon 1y ago

For serialization GraphQL uses ... JSON. GraphQL could use Progressive JSON to serialize subscriptions.

Spivak 1y ago
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.

owebmaster 1y ago

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.

tunesmith 1y ago
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?
cluckindan 1y ago
What do you mean by technical debt here?
- owebmaster 1y ago
  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.
  - cluckindan 1y ago
    Interesting. Why did you not have these pains with other tech? Team unfamiliar with GraphQL?
    - owebmaster 1y ago
      > 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.
      - cluckindan 1y ago
        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.
RexM 1y ago
Interesting take considering graphql adoption is growing and generally in favor at my company.

danabramov 1y ago

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.

tgasson 1y ago

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-runtime/store/RelayExperimentalGraphResponseTransform.js https://github.com/facebook/relay/blob/main/packages/relay-r... [2]: https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md#payload-format https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferSt...