[rbalicki]

The author is missing the #1 benefit of GraphQL: the ability to compose (the data for) your UI from smaller parts.

This is not surprising: Apollo only recently added support for data masking and fragment colocation, but it has been a feature of Relay for eternity.

See https://www.youtube.com/watch?v=lhVGdErZuN4 for the benefits of this approach:

- you can make changes to subcomponents without worrying about affecting the behavior of any other subcomponent,

- the query is auto-generated based on the fragment, so you don't have to worry that removing a field (if you stop using it one subcomponent) will accidentally break another subcomponent

In the author's case, they (either) don't care about overfetching (i.e. they avoid removing fields from the GraphQL query), or they're at a scale where only a small number of engineers touch the codebase. (But imagine a shared component, like a user avatar. Imagine it stopped using the email field. How many BFFs would have to be modified to stop fetching the email field? And how much research must go into determining whether any other reachable subcomponent used that email field?)

If moving fast without overhead isn't a priority (or you're not at the scale where it is a problem), or you're not using a tool that leverages GraphQL to enable this speed, then indeed, GraphQL seems like a bad investment! Because it is!

[WickyNilliams]

Yes, Apollo not leading people down the correct path has given people a warped perception of what the benefits actually are. Colocation is such a massive improvement that's not really replicated anywhere else - just add your data requirements beside your component and the data "magically" (though not actually magic) gets requested and funnelled to the right place

Apollo essentially only had a single page mentioning this, and it wasn't easy to find, for _years_

[girvo]

Quite. Apollo Client is the problem, IMO, not GraphQL.

Though Relay still needs to work on their documentation: Entrypoints are so excellent and yet still are basically bare API docs that sort of rely on internal Meta shit

[sibeliuss]

The docs situation continues to be hilarious and bad, for the gem they have created.

It's the unfortunate situation where those who know, know, and those who do not, blasphemy the whole thing based on misunderstanding.

Super unfortunate, which could be solved by simply moving a little money over to Relay's docs, and working on some marketing materials.

[rbalicki]

100% agree on the unnecessary connection between entrypoints and meta internals. I think this is one of the biggest misses in Relay, and severely limits its usefulness in OSS.

If you're interested in entrypoints without the Meta internals, you may be interested in checking out Isograph (which I work on). See e.g. https://isograph.dev/docs/loadable-fields/, where the data + JS for BlogBody is loaded afterward, i.e. entrypoints. It's as simple as annotating a field (in Isograph, components define fields) with @loadable(lazyLoadArtifact: true).

[Already__Taken]

Reminds me a lot of Grafast too, a new stab at this the people that made postgraphile had. I liked using graphile, haven't needed to rewrite or start a new project yet for grafast. * https://grafast.org/

[presentation]

Agreed on fragment masking. Graphql-codegen added support for it but in a way that unfortunately is not composable with all the other plugins in their ecosystem (client preset or bust), to the point that to get it to work nicely in our codebase we had to write our own plugins that rip code from the client preset so that we could use them as standalone plugins.

The ecosystem in general appears to be a problem.