So I’ve got a similar problem to this one but really don’t have the option of federation. We’ve got probably 8-10 teams at our company all spitting out multiple GraphQL endpoints on different domains with different types of data and need to consume potentially all of them (and zero ability to federate a supergraph). In Xcode, we’ve got one back-end business/data layer project for all of our legacy endpoints that has served just fine.
I was able to download schema and codegen easily enough with separate JSON files and the CLI. However on building I then ran into a bunch of duplicate file names (like SchemaConfiguration.swift). Manual clean up has gotten me to a clean build but it’s not a sustainable solution in the long term.
Are there any options? This seems like an extremely common problem as GraphQL takes off. All I can think of now is:
- Existing process and manual cleanup after every schema pull/codegen update.
- Break out our business/data layer into separate Swift packages/targets, or
- Wait for a solution from Apollo.
Am I missing something obvious here? TIA!
Thanks for the question!
Your option #2 is what I would suggest. If you generate the files for each of your schema endpoints as their own modules, they can each be imported by your project and you shouldn’t have name space conflicts.
Option #1 is probably something you can automate with some custom scripts of your own if you want.
Option #3 is a bad one. This is not something that we are planning on fixing.
Honestly, one application having to interface with 8-10 different GraphQL endpoints isn’t an “extremely common problem”. There are very few organizations with many subgraphs that aren’t doing some sort of federation. You say you don’t have the option of federation, but I’m not really clear on why that is. Even if you don’t want to use Apollo Federation, there are other competing technologies out there for creating a supergraph.
A federated graph is going to be so much more performant, powerful, and easy to work with than multiple endpoints. And even though we strongly believe that GraphOS and Apollo Federation are the best way to do this, we ensure that our open-source clients will work with any spec-compliant GraphQL server. But we aren’t going to invest time in solving the incredibly complicated issues surrounding cache normalization, code generation, and cross-graph data dependencies that are posed by multiple GraphQL endpoints, because the solution to that problem already exists – federation.
1 Like
Thanks for the response @AnthonyMDev ! I guess I’m at one of them regarding the federation sadly.Think it’s mainly due to siloed teams and DDD but I will try to get that fixed.
Question on #2 above. Is there a way to not just namespace the contents of the files but add the namespace to the file name itself to simplify this process?
For example, if we have class Location in two different GraphQL endpoints in the same Xcode project, the generated code is fine and namespaced properly, but the generated files in both folders are ‘Location.graphql.swift’ which Xcode doesn’t like at all. We then have to manually rename after every codegen. Would be better if we could get ‘Location.FooEndpoint.graphql.swift’ and ‘Location.BarEndpoint.graphql.swift’
Thanks!
We then have to manually rename after every codegen. Would be better if we could get ‘Location.FooEndpoint.graphql.swift’ and ‘Location.BarEndpoint.graphql.swift’
@rabbit_holes there isn’t any way to have that renaming automatically happen with the codegen engine today. You’re hitting the edges of what the design is intended to cater for unfortunately.
k, not a problem. thanks anyways!