of course! like everyone else :)
GraphQL client cache can be built on e.g type name + entity id (it’s really good and easily implemented in Apollo). It means that after requesting all pets, your request to one particular pet will be derived from cache.
Other advantages are also mentioned in the article and they all about benefits GraphQL as transport/query language against HTTP limitations. That’s it.
I’m afraid you are talking not about concepts, but about certain implementation details and I’m not sure what is your target and it could be too verbose.
If we are talking exactly about swagger-to-graphql, then you can not link resolvers cross types. It’s not going from the box. The relation is: endpoint — type. It’s built…
I think you are still mixing database concepts and data representation. You can organize your user model so that it will contain user’s pet. And you don’t need to do a separate request even with REST.
Again, GraphQL has nothing common with your data storage or data organization/relations. It’s not SQL, because SQL is coupled…
The article is not about GraphQL itself. It’s about situation when you have to support REST in parallel. It means that your API in REST and GraphQL already has similar advantages by design. But at the same time you can use all benefits of GraphQL on the client side (smart caching, validation, fragments, pagination etc)
GraphQL should know nothing about your data organization, if we are talking about `swagger-to-graphql` it just wraps your existing REST approach to make transition to GraphQL as soon as possible.
So in your example you should query GraphQL type `get_users_id_pets_id` with arguments (userId=123, petId=456) and under the hood…