This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M
Simple example:
1. header component - dev queries user for first name to do a welcome message.
2. sidebar component - another dev does a query for first/last/avatar/profile/etc.
Your app sends 2 network calls. Certainly it doesn't have to, but I've seen this chattiness get implemented.
So you avoided overfetching of data like official REST APIs but now you have more network calls.
> Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determines statically (i.e. before your application runs; at the time you write your code) the requirements for an entire view!
> This is achieved with the help of GraphQL. Functional components use one or more GraphQL fragments to describe their data requirements. These fragments are then nested within other fragments, and ultimately within queries. And when such a query is fetched, Relay will make a single network request for it and all of its nested fragments. In other words, the Relay runtime is then able to make a single network request for all of the data required by a view!
https://relay.dev/docs/principles-and-architecture/thinking-...
In order to prevent the frontend from doing that, I have to be sure to enforce usage of another layer. Devs need to use fragments and relay and not just fire off their own ad-hoc graphql queries.
Which is interesting, and thanks for sharing. I would move toward implementing this on any graphql project, especially an inherited, network chatty graphql project.
But I still prefer keeping the frontend really dumb and just sending the data it needs, that has been identified.
Most of the time a REST or REST like API endpoint is sufficient, and it doesn't matter if you overfetch some data, you avoid extra graphql layers (now enforcing fragments/relay, extra resolvers, potential performance issues, multiple schemas and access concerns).
I like GraphQL but it seems like a lot of overhead for little gain for many projects. One project has 3 different graphql schemas. Can't be exposing the whole tree to every user type.
I can see why frontend devs would like it though (need this data, probably already available), but a REST or REST-like API is more enjoyable for me unless I'm building a framework or on top of a framework or a client that needs ultimate ad-hoc query ability where it really shines to me.
UI using REST server tends to centralize the API client, call the endpoint(s), and make that available to all components.
UI using GraphQL often has frontend devs doing their components, running their ad-hoc queries for "just what they need". More network calls.
So overfetching like with REST tends to lead to less network calls unless you are extra diligent on a GraphQL project.