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!

▲

girvo a day ago | parent | next [-]

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 a day ago | parent | next [-]

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 a day ago | parent | prev [-]

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).

▲

girvo a day ago | parent [-]

Neat! I basically just reimplemented some of the missing pieces myself, but honestly for the kind of non-work GraphQL/Relay stuff I do React Router with an entry point-like interface for routes (including children!) to feed in route params to loadQuery and the ref to the route itself got me close enough for my purposes

I’ll have a play though, sounds promising :)

Oh this is interesting, sort of seems like the relay-3d thing in some ways?

	▲	rbalicki a day ago \| parent [-]
		Yeah, you can get a lot of features out of the same primitive. The primitive (called loadable fields, but you can think of it as a tool to specify a section of a query as loaded later) allows you to support: - live queries (call the loadable field in a setInterval) - pagination (pass different variables and concatenate the result) - defer - loading data in response to a click And if you also combine this with the fact that JS and fragments are statically associated in Relay, you can get: - entrypoints - 3D (if you just defer components within a type refinement, e.g. here we load ad items only when we encounter an item with typename AdItem https://github.com/isographlabs/isograph/blob/627be45972fc47.... asAdItem is a field that compiles to ... on AdItem in the actual query text) And all of it is doable with the same set of primitives, and requiring no server support (other than a node field). Do let me know if you check it out! Or if you get stuck, happy to unblock you/clarify things (it's hard for me to know what is confusing to folks new to the project.)

▲

WickyNilliams a day ago | parent | prev | next [-]

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_

▲

presentation a day ago | parent | prev [-]

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.