Multiple graphs

[swizzlr]

Question

I currently have my apollo schema set up to generate a schema module and then per feature module operations. I now need to support a second graph. Are there any best practices around this? Should I collapse all operations into a single module and then have a module per graph?

Alternatively, if i wanted to get fancy, I considered potentially using some kind of file prefix to indicate which graph the operations belong to, then use two parallel configs to glob for different operations respectively, e.g.
**/*.graph1.graphql and **/*.graph2.graphql. I don't know if this is a terrible idea or not.

[AnthonyMDev]

The first thing to know is that you need to have a separate ApolloClient and NormalizedCache instance for each schema. We do not recommend trying to write cache data for two schemas into the same cache.

In order to ensure that you don't accidentally send an operation for one schema to the other client, I recommend you wrap your ApolloClient in a wrapper with a generic type over the schema. Then each can only take in operations where Operation.Data.Schema == Self.Schema.

You should also run codegen separately for each schema and have two separate schema modules.

Alternatively, if i wanted to get fancy, I considered potentially using some kind of file prefix to indicate which graph the operations belong to, then use two parallel configs to glob for different operations respectively, e.g.
**/.graph1.graphql and **/.graph2.graphql. I don't know if this is a terrible idea or not.

Including operations in features modules will be easy as long as each module only uses a single schema. If a module needs to use models from both schemas, you'll need to do what you've suggested here. I don't think it's a terrible idea necessarily, but might be more cumbersome than it's worth.

It's probably a lot easier to just include the operations in their corresponding schema module.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.