Using `3.8.2` I got a root apollo module with ```....

# apollo-kotlin

[Stylianos Gakis]

Using 3.8.2
I got a root apollo module with

...
packageName.set("octopus")
generateApolloMetadata.set(true)
generateDataBuilders.set(true)

Then in a feature module, I got

apollo {
  service("octopus") {
    packageName.set("octopus") // Tried with "octopus.home" too, to have them be different
    generateDataBuilders.set(true)
  }
}

.
In my feature module then in a test, I was trying to create an instance of a response, and it seems like it’s not generating the right thing which comes from my feature module.

So in my root apollo module, I got a query which asks for a type, but only asks for a subset of the fields in there.
The feature module asks for a unique field which wasn’t asked before, and the data builder does not generate the right builder. Basically in one place, for the public fun BuilderScope.buildProductVariant(block: ProductVariantBuilder.() -> Unit) function, the ProductVariantBuilder only contains the fields that are present in the home module queries.

I have confirmed now that adding the field in the root module (despite not needing it there), generates the right data builder, and only the fields that I have there, not the ones that are in the feature module.

Does this sound like something that I am doing wrong, or something that may be wrong with data builders in 3.x? I didn’t check with 4.x atm, but if you know for example that this is solved there then just let me know and I’ll work around it for now until I can go to 4.x.

[mbonnin]

In both v3 and v4 you need to either:
1. generate all types in the root module (alwaysGenerateTypesMatching.set(listOf("*")) )
2. or configure the "back links" so that the root module gets the used coordinates from the feature module

[mbonnin]

2. is significantly improved in v4 so if you're already doing this, it's worth trying with v4

[Stylianos Gakis]

Hmm, how does configuring back links look like? I don’t think I’ve read the docs around that yet 👀

[mbonnin]

Or if you can't just yet, add your field manually with alwaysGenerateTypesMatching.set(listOf("Type.yourField")) (I think this works in V3 but wouldn't put my hand on it)

[mbonnin]

Oh yea, so that's where multimodule gets really hairy

[Stylianos Gakis]

I haven’t been doing any of the above so far because for the time being we always have had the gql files all in the one big module, haven’t split them at all. I am now doing this for the first time basically, hence it’s the first time I meet this issue 😄

[mbonnin]

I would workaround in V3 and only set this up once you're in v4. The configuration is substantially different

[Stylianos Gakis]

Okay that’s good to know. Which part of the docs should I be looking at for this for v4? I can read up so I am ready for when we do the migration 😊

[mbonnin]

That's the v4 docs

[mbonnin]

Data builders are quite complex because multiple modules might contribute fields to the same type so the only solution is to generate it in the root module.

[mbonnin]

There is some stuff in v3 using Gradle apolloUsedCoordinates configurations or so but it's not documented and had a bunch of issues so better wait until v4

[Stylianos Gakis]

Yup, that makes sense.
So in v4, you’ll do X amount of isADependencyOf for X feature modules you got with this configuration + 1 dependsOn per feature module with gql files, and it should then all work well together

[mbonnin]

Yes, exactly.

[mbonnin]

I'm still not completely hyped by this because it feels like there should be a way to express this bi-directional relationship in a single place but AFAIK, Gradle doesn't allow that because it breaks project isolation

[Stylianos Gakis]

Sounds good, yeah. I will add a dummy query in the root module for now which queries the right things, and just not use it. And remove it on v4 then. That should work.

[Stylianos Gakis]

Yeah, I was thinking with this if there’s a way for some in-house convention plugin to make this happen, which would maybe? work?
But would probably be a per-case basis, and not really something you can provide for us I would guess.

[mbonnin]

I've looked at this problem from different angles but didn't find anything. The closest is https://github.com/gradle/gradle/issues/22514 but that wouldn't help us here I think

[Stylianos Gakis]

Like how some convention plugins, like the one from slack I think allows each feature module to do something like

features {
  anvil()
  blahblah()
}

And have that maybe somehow hook everything together. But this is definitely a stretch, I am only imagining here, I do not have anything concrete on my mind.
Seen something like this mentioned here https://androidstudygroup.slack.com/archives/C0SFT151T/p1674252933934949

[Stylianos Gakis]

Or here
https://slackhq.github.io/slack-gradle-plugin/#feature-dsl

[mbonnin]

Oh yea, that's the Groovy/Kotlin DSL interop thingie?

[mbonnin]

That's the "easy" part 😅 The "hard" part is how to do

project(":schema").dependencies {
  add("apolloUsedCoordinates", project)
}

in a way that doesn't break all the Gradle logic

[mbonnin]

BTW, for Groovy/Kotlin DSL interop, the trick is to write all your plugin API using block: Action<T> parameters. Gradle will generate magic bytecode to have your function accept both a Kotlin function type (works out of the box with SAM conversion) and a Groovy closure (requires magic bytecode)

[Stylianos Gakis]

I don’t know. How I understood is just project-specific DSL to setup features quickly. So I imagine perhaps for our app for example I could do

hedvig {
  apollo()
}

Which would setup the dependencies + setup dependsOn(project(":schema"))

Now at that point I don’t know if that convention plugin can also check all those callers who call apollo() and then also setup isADependencyOf accordingly.

A question, if the root module does isADependencyOf for all modules? So that you can just add that and only need to care for the child modules after that? Or does that fail during compilation?

[mbonnin]

I don’t know if that convention plugin can also check all those callers who call apollo() and then also setup isADependencyOf accordingly.

Yea, that's the issue sad panda . I don't think it's safe to iterate the projects from a convention plugin

root module

I try to refer it as the "schema module". It doesn't have to be your root project in the Gradle acceptation of the term

you can just add that and only need to care for the child modules after that

If you can iterate all projects, then it might work but I'm not sure how "project isolation-compatible" this is.

[mbonnin]

My hunch is that if it's allowed to iterate in the "schema module", it's probably allowed to lookup a given module from another one so might as well do everything in the convention plugin

[Stylianos Gakis]

Yes sorry, when I said root module I did in fact mean the root apollo module not the actual root module. That’s what we do too.

[mbonnin]

Yep, I've made the mistake multiple times 🙂 . This is why I'm forcing myself to say "schema module" now. Removes any possible confusion

[mbonnin]

Takes a while to get used to but I'll get there before I replace all the "gradle enterprises" with "develocity" 😄

[Stylianos Gakis]

“Schema module” it is, I like it more, I just couldn’t come up with it myself 😅
Oh boy, the world isn’t ready for Develocity. I certainly am not for one 😂

[Yang]

Would a settings plugin help here?

[mbonnin]

Maybe? Is there anything about settings plugins that make it easier to work with project isolation?

[Yang]

not sure, but IIRC you can do subproject / allprojects etc without breaking project isolation

[Yang]

just read https://github.com/gradle/gradle/issues/22514 again, maybe not 😅

[mbonnin]

We might as well decide to give up project isolation, I'm not sure if this will ever be a reality...

[Yang]

I’m finally starting to migrate to v4 😄 so is there a way to configure the backlink automatically (ignoring project isolation 🙈)?

[mbonnin]

isADependencyOf() should do it!

[mbonnin]

See https://www.apollographql.com/docs/kotlin/migration/4.0/#auto-detection-of-used-types

[mbonnin]

Ah wait, that’s not “automatic”, sorry, even I start getting lost there.

[mbonnin]

dependsOn(dependencyNotation = project(":schema"), bidirectional = true)

[mbonnin]

This is more like what you’re looking for ☝️

[mbonnin]

https://www.apollographql.com/docs/kotlin/advanced/multi-modules#auto-detection-of-used-types

[Yang]

Oh nice!

[Yang]

I like that you have to pick your poison 😬

[mbonnin]

Yeaaa TBH, I feel like it’s not the end of the story but at least should give you a solution to configure everything in your convention plugin if needed

[Yang]

while we’re here, doesn’t this dependsOn also break project isolation?

[mbonnin]

I don’t think so because it only uses the “name” of the other project

[mbonnin]

Just like doing

dependencies {
  implementation(project(":schema"))
}

would be compatible

[mbonnin]

I’d love to enable PI on some of my projects but it’s really hard right now. I think KGP has “some” support for JVM only projects but last time I tried I bumped into corner cases that made projects fail

[Yang]

I see, so bidirectional needs to resolve more things from schema when configuring the project?

[mbonnin]

Yep

[mbonnin]

here

[mbonnin]

It’s actually getting an instance of the project and mutating stuff on it

[mbonnin]

(dependencies.project(":schema") doesn’t return a Project instance, Project.project(":schema") does)

[Yang]

trying out bidirectional, is it only meant for the modules that has a schema, or does it also work on the other modules that produces metadata e.g. for sharing fragment?

[mbonnin]

It's meant for modules that do not have a schema. They depend on the schema module with a double link so that the schema module can get the used types

[Yang]

sorry I mean the “target”

[Yang]

for example I have a :feature module that has dependsOn on :schema, but also another dependsOn on a :sdui module with GraphQL fragment

[Yang]

should I have dependsOn(project(":schema"), bidirectional = true) and dependsOn(project(":sdui"), bidirectional = true) ?

[mbonnin]

Gotcha. In that case, no need 👍

[mbonnin]

You still need it in your sdui module

[mbonnin]

In a future version, we may have intermediate "nodes" but as of today all types get generated in the schema module

[Yang]

Cool, that brings us back to the “client schema composition” thing but I won’t hijack the thread 😬

[Yang]

BTW with this optimization is the build time improvement and presumably binary size reduction only expected on the schema modules?

[mbonnin]

Yes, mostly. You pay a small price in each feature module (because of the IR serialisation/serialization) that should pay off for the schema module (because no need to generate, and compile unused types

[mbonnin]

Although I must say this is really hard to measure. If you have a large codebase, would love to hear about numbers there

[Yang]

yeah doing some basic tests now

[mbonnin]

I think the biggest gain is incremental builds. If you change only one module, no need to recompile the other ones

[mbonnin]

(unless you add a new type...)

[Yang]

you mean changing the graphql documents in a feature module right?

[mbonnin]

Yep!

[mbonnin]

Changing the schema most likely recompiles everything but that's supposed to happen less often

[Yang]

hmm this seems to have no effect at all, I’m pretty sure we have unused types 😅

[Yang]

even the size of build folder is identical

[mbonnin]

Did you remove alwaysGenerateTypesMatching ?

[Yang]

yeah we had alwaysGenerateTypesMatching.set(listOf(".*")) and I removed it immediately

[Yang]

can confirm we have unused types in the schema