Schema module generation without operations

[jaikumar-b]

Typescript and Kotlin both have options to generate schema types without specifying operations, this would allow to have a single schema module that can be consumed by all modules. We have a huge graph with 6000+ types, and would like to explore the idea of producing an xcframework of schema types to speed up build times. Understandably it would add types that the app may never use, but if were willing to accept the downside of additionally types for better productivity, it could be worth the trade off. Unfortunately, I couldn't an option for this on iOS. Is this something thats going to be supported? If not, any pointers on how we can add this to our folk of codegen so that we can enable this on our end?

[calvincestari]

HI @jaikumar-b - I think the module configuration you want is already supported.

The file output options in the codegen configuration allow you to configure schema types and operations separately.

For the schema types you'll want to use a module type of either embeddedInTarget or swiftPackage. embeddedInTarget requires you to configure and maintain the target module, whereas swiftPackage is the more automatic option; either way though you'll be getting a separate module for the schema types.

The operations configuration is where you get to separate operations from schema types through using either a relative or absolute configuration option.

Understandably it would add types that the app may never use, but if were willing to accept the downside of additionally types for better productivity, it could be worth the trade off.

There is no way to configure Apollo iOS to generate schema types for all types as it will produce Swift types for only those that are used in operations, and at least one operation is required for code generation. Note that we do have an open issue to correct some of this behaviour.

I'm going to close this issue because I think what you need is already supported. If after reading the documentation and trying the output options it's still not what you're looking for, then comment back in this issue and we can take another look.

[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.

[jaikumar-b]

My question was around how to generate all types not just types used in operations.

Was able to get this to work by modifying the codegen a bit with the limitation that you still need at one operation. Dropping it here in case someone needs it.

This gives the ios codegen the same generateSchema option like kotlin codegen has

apollographql/apollo-ios-dev@main...jaikumar-b:apollo-ios-dev:generate-schema

[calvincestari]

Thanks @jaikumar-b. I'm curious to understand what benefit the additional types are if they're not being used in any operation? How are they useful to you in your project code?

[jaikumar-b]

Thanks @jaikumar-b. I'm curious to understand what benefit the additional types are if they're not being used in any operation? How are they useful to you in your project code?

We're facing some limitations with the current codegen options -

Option 1:

• Have all the schema types of all operations and fragments in one module or package and have the operation types and fragment types relative to their location

Downsides:

• Having a huge schema of 6000+ types. The schema types become a bottleneck in complication times.
• We were using this setup in 0.5x release. But in 1.x, this is adding 3-4x more in compilation times. This was a non-starter for us

Option 2:

• Generating schema types local to the modular packages and hide the types from between packages. Re-run codegen multiple times for each module

Downsides:

• While the modular code development is okay, the parent binary is still a lot slower in compilation times due to duplicated types across modules
• We have some shared fragments across modules and the public schema types conflict with the schema types in consuming modules. This makes sharing fragments across modules a lot harder

Option 3: (Currently exploring)

• This is something our Android counterparts do - generate a binary whenever a supergraph is published and save it against a hash of the schema file. Gradle enterprise pulls the binary of based off the hash of the schema available locally.
• The key benefit here is that the schema module here could be a dynamic xcframework library helping us speed up our compilation times across local and CI
• We also have a multi repo setup so the same binary can be used in another repo without worrying about type collisions.

Downsides:

• Linking with xcframework is causing a crash on InputDict, have to dig why that happens. Not sure yet.
• Probably affects startup time, but this can be mitigated by switching the release builds to build code instead.
• Hard to debug (if we have to)

Hope this makes sense. Happy to answer more questions

[calvincestari]

I agree option 2 doesn't offer much benefit when you have shared fragments/types.

How often is the schema module changing in option 1? The increased compilation time is unfortunate but there should be minimal changes to these types once generated so you shouldn't need to pay that compilation cost on each build.

Re. option 3 - sounds like a valid option for you product configuration. Would love to know what you find out about the InputDict crash.