> If two sibling modules use the same schema type and this schema type wasn't generated upstream,...

# apollo-kotlin

[Jan Skrasek]

If two sibling modules use the same schema type and this schema type wasn't generated upstream, each module will generate its own version of the schema type, which could clash. To prevent this, Apollo Kotlin registers a global "check${service}ApolloDuplicates" task that will fail if there are duplicates.

Hello. I do not much understand this.
• Could clash means exactly what? Our two modules has different package names, so I guess they cannot clash, can they?
• Is the check "preemptive" in a way it fails even they do not clash (because of those package names)?
Thank you 🙂

[mbonnin]

Hi 👋

Our two modules has different package names, so I guess they cannot clash, can they

That's the catch. Because there's only one schema, all the "schema" types will use the same package name

[mbonnin]

Which is the package name of the "schema" module

[mbonnin]

If you have something like this:

:schema
- schema.graphqls
- query1 that uses input type Input1
:feature
- query1 that uses input type Input2

Then Input2 is going to be generated in the "feature" module
But if you move that query to the "schema" module (or just add a new one there), it's going to be moved to the "schema" module.
Because we don't want that move to break things, we use the same package name for all "schema" types

[mbonnin]

If you don't want to be bothered with this, you can set alwaysGenerateTypesMatching.set(listOf(".*")) in your schema module but this might generate a bit more code (or sometimes a lot depending your schema)

[Jan Skrasek]

Which is the package name of the "schema" module

So ours feature module setup will not work?

val packagePath = "xxx." + path.replace(":", ".") + ".network"
packageName.set(packagePath)

[mbonnin]

It will, only just for operation types

[mbonnin]

• schema types use all in the same package name
• operation types can use module-specific package name

[mbonnin]

We have only one packageName option in the Gradle setup for historical reasons but in multi-modules setup, there are in reality 2 packageName s

[mbonnin]

(or more if you have more modules)

[Jan Skrasek]

Our schema is quite big so we would rather not use .* to generate everything. At the same time there are some reused types, so some manual whitelisting could help, though in the end, having duplicated schema seems like the most easy solution.

[mbonnin]

You mean duplicate your schema in all modules (and therefore not using apollo metadata)?

[mbonnin]

I guess that's a solution if the manual whitelisting is adding too much friction

[mbonnin]

You can follow https://github.com/apollographql/apollo-kotlin/issues/4039 for ideas how to improve that. But ultimately I think there's no silver bullet if you want to only generate the used types and share them between modules at the same time

[Jan Skrasek]

We have about 200 modules and multiple graphqls (dont ask why, I dont like it either), so in this particular fist usecase, we have a graphql shared across just two modules. Maybe for other graphqls it will be shared across more of them (5-10), so definitely we will reconsider this - and maybe for those it will make sense to generate everything in metadata package.

[Jan Skrasek]

We wouldn't mind having some types duplicated in feature modules. (this would mean forcing a different package)

[mbonnin]

Yea maybe allowing duplicate schema types in different packages is a solution although I'm not sure the consequences of that. It "feels" wrong

[Jan Skrasek]

If I understood it correctly, all this would be fixed by 4039, wouldn't be?

[mbonnin]

4039 will just automate some part of the manual alwaysGenerateTypeMatching logic that needs to be done

[mbonnin]

It will not change the actual codegen. It will "just" compute the alwaysGenerateTypeMatching for different nodes in your module graph automatically

[Jan Skrasek]

Oh yes, that's what we wanna avoid - making us to think what to make shared. Because the current check doesn't tell us that, right?

[mbonnin]

Because the current check doesn't tell us that, right?

The current check will tell you something like:

type 'SomeInputType' is used in sibling modules :feature1 :feature2, use alwaysGenerateTypesMatching in a parent module

4039 is about getting the alwaysGenerateTypesMatching values from a file that can be computed automatically by some task that scans the whole module graph

[mbonnin]

(because there's no other way to know where to generate the schema types without scanning the whole module graph, or at least all the .graphql files)

[Jan Skrasek]

Thank you for thorough explanation and suggestion. 🙂

[mbonnin]

Sure thing! I'm not sure we landed on a good way forward for you though?

[mbonnin]

(thinking out loud) another solution to that problem would be to have a task in the root module that scans all *.graphql files and always generate the schema types in the schema module

[mbonnin]

Of course that's something that's going to be run everytime a single .graphql file is touch but in my experience, parsing GraphQL is relatively fast compared to compiling Kotlin so maybe that wouldn't be too bad

[mbonnin]

But it definitely introduces coupling

[mbonnin]

We wouldn't mind having some types duplicated in feature modules

Feel free to open an issue about this and we can experiment

[Jan Skrasek]

I guess we will duplicate for now - those modules tackle (relatively) different stuff -> user account vs credits, so it make somehow sense not to couple them. Next time I believe the usecase will be different and it will be ok to use .* to generate everything in metadata module.

[Jan Skrasek]

(next time - our different graphql server/schema)

[mbonnin]

Sounds good 👍 At the end of the day, the schema types are relatively slow compared to the operation types so it's certainly ok to duplicate.