Ok but I'm talking about your client application sending multiple network calls at different times. How does the server prevent that? It doesn't. In order to p

Ok but I'm talking about your client application sending multiple network calls at different times. How does the server prevent that? It doesn't. 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.