Is there a way for using the same structs with different requests?


I have several Queries and Mutations which logically share the same object (struct). For example the getUser(id) method returns the same User as the listUsers (which returns an array of users in this example) and the login (which returns the logged in user’s details).

In the iOS app I want to have variables with a common User type to handle these results. Apollo’s code generation creates different models for each query, like GetUserQuery.Data.User, UsersQuery.Data.User and LoginMutation.Data.User. Do these structs have a common ancestor, protocol or anything I can use for my internal data structure? Obviously I will need users of the same data kind to be able to extend it with helper functions (for example a hasValidName()), to compare them and use them in general.

For this purpose my best solution was to introduce my own User struct, which had helper methods for every request type which converted an Apollo struct to a User type I created. Obviously this kills the simplicity of Apollo GraphQL instantly. Each model change caused me tens of source code lines and hours of work.

I am looking for a better way to do this. Maybe I overlooked something or missed an important note in the documentation? Please help me find the right way to solve this very common situation.

Hi @gklka, :wave: - you could try fragments as a way of sharing a struct between queries. Fragments will get placed into its own file and you would then be able to extend that type.

We’re also exploring sharing types outside of GraphQL fragments in Hoisted types · Issue #2191 · apollographql/apollo-ios · GitHub. It has the potential to dramatically reduce the generated code size in certain schemas.

Fragments don’t help in this problem. I think Apollo is not good for any usecases when you want to use the response objects as long living models in your app. You have to do either some kind of data conversion or use another GraphQL implementation, like SwiftGraphQL, which was created with exactly this problem in mind: Why? - SwiftGraphQL