GraphQL is meant to be used along side a very smart client-side cacheing library like Apollo
The best practice for GQL is to make frequent, small, queries (Apollo handles batching them) throughout your application. Apollo won't do any extra work to fetch new fields if they're already in the cache
Not to be that person because I understand there's always edge cases, but in general with GQL if your queries are highly complex or too nested "you're doing it wrong™"
"Make frequent small queries and let a smart cache do the right thing every time" sounds like "make a perpetual motion machine". It just sounds like a fundamentally difficult problem with unavoidable tradeoffs. I admit I don't know the details of Apollo, but I find it hard to believe that a caching layer magically solves everything without introducing very gnarly bugs. A cache layer makes concurrent editing harder, for one.
The Apollo cache doesn't magically solve everything, certainly not concurrency. It's a state store like redux/pinia/mobx, with automatic normalization plus other goodies like being able to query/mutate the store locally with gql if you want. Doing N+1 cache-only queries is also no big deal, though I don't do so myself. They probably should have called it a state store and not a cache, but whatevs...
The best practice for GQL is to make frequent, small, queries (Apollo handles batching them) throughout your application. Apollo won't do any extra work to fetch new fields if they're already in the cache
Not to be that person because I understand there's always edge cases, but in general with GQL if your queries are highly complex or too nested "you're doing it wrong™"