https://kotlinlang.org logo
#apollo-kotlin
Title
# apollo-kotlin
a

agrosner

02/14/2023, 7:15 PM
hey quick question. do apolloUsedCoordinates support multiple services?
Copy code
> No matching variant of project :domain was found. The consumer was configured to find a usage of 'apollo-used-coordinates' of a component, as well as attribute 'com.apollographql.service' with value 'api' but
but we only use the service from
api2
in that module.
m

mbonnin

02/14/2023, 10:16 PM
That should work. Do you mind sharing more about your module layout?
a

agrosner

02/15/2023, 12:05 AM
Sure I’ll do so in the morning ! It was just a schema module with two schemas in different services. And having different modules included as used coordinates. They utilize 1 or both services
ok so our module layout is like this:
Copy code
schema
module1 -> schema
module2 -> schema
where:
Copy code
schema: service("api1", "api2")
module1: service("api1", "api2")
module2: service("api2")
module1 and module2 add
apolloSchema
+
implementation
on
schema
while
schema
declares
apolloUsedCoordinates
of each
module1
and
module2
m

mbonnin

02/15/2023, 5:45 PM
Damn you are 100% right...
Same thing goes the other way too 😕 We can't have a feature module using 2 services referencing two different schema modules....
Now the good new is that there is certainly a workaround... let me try
Maybe this:
Copy code
dependencies {
    add("apolloApi1UsedCoordinatesConsumer", project(":module1"))
    add("apolloApi2UsedCoordinatesConsumer", project(":module1"))
    add("apolloApi2UsedCoordinatesConsumer", project(":module2"))
}
(trying to work on a reproducer)
The reproducer has only one service in each feature module but it's the same idea
It's using the low level configurations instead of the catch-all "apolloMetadata" and "apolloUsedCoordinates" configurations
The only important thing is to put add the dependencies * after * registering the services or else the configurations are not created yet
a

agrosner

02/18/2023, 9:12 PM
Ahh interesting. I’ll try it out. Thank you! I was out sick past couple days, so apologies for late acknowledgment
m

mbonnin

02/19/2023, 12:46 AM
No worries at all, thanks for bringing that up! I hope you're feeling better!
a

agrosner

02/27/2023, 3:40 PM
this worked! i made a convenience function:
Copy code
/**
 * Declares apollo used coordinates for our schema. Rather than defining a bunch of "always generate types"
 */
fun DependencyHandler.api1(
    vararg projects: ProjectDependency,
) {
    projects.forEach { apolloUsed("api1", it) }
}

fun DependencyHandler.apolloUsed(service: String, project: ProjectDependency) {
    add("apollo${service.capitalized()}UsedCoordinatesConsumer", project)
}
then we just queue it up:
Copy code
api1(
        project(":homepage-graphql"),
        project(":homepage-**-graphql"),
        project(":**-graphql"),
    )
also from the docs on 3.7.0 it was not quite clear that we needed
implementation
on our schema alongside
apolloSchema
, and
apolloMetadata
might be fun to added a combination configuration that (or named better) is like:
Copy code
apolloSchemaConsumer(project(":schema"))
that does
implementation
,
apolloSchema
and
apolloMetadata
m

mbonnin

02/27/2023, 3:45 PM
Awesome! Glad to hear it worked !
And sorry about the multiple configurations, etc... I know it's a bit messy. I'm reorganizing things for 4.x so that it's easier. See https://github.com/apollographql/apollo-kotlin/pull/4694
In the end it's going to look like this:
Copy code
# feature
apollo {
  service("service") {
    packageName.set("feature")
    dependsOn(project(":schema")
  }
}

# schema
apollo {
  service("service") {
    packageName.set("schema")
    # naming is up for grabs
    isADependencyOf(project(":feature")
  }
}
It's a bit unfortunate that we can't "doubly link" projects to make the
isADependencyOf
completely optional but I didn't find a way for this with Gradle configuration cache and proejct isolation aruond
a

agrosner

02/27/2023, 4:16 PM
ahh niceee
thats really cool
one more question: for the used coordinates. do intermediate modules (we have common -graphql modules) also need to declare
apolloSchema
? im guessing yes
say we have schema -> module a -> module b module b declares queries module a declares reusable fragments
m

mbonnin

02/27/2023, 4:18 PM
Yes, the schema is required in both module a and module b
a

agrosner

02/27/2023, 4:20 PM
cool. thanks
m

mbonnin

02/27/2023, 4:20 PM
Sure thing!
a

agrosner

02/27/2023, 4:21 PM
i think the above approach is solid. love the change (when it lands!) also to note, the coordinates approach drastically simplified our schema modules gradle file. thank you ♾️ !
m

mbonnin

02/27/2023, 4:23 PM
Nice! TBH, this is (was?) one of the most hairy part of the codegen. Making everything work together and dealing with the multiple Gradle APIs was quite the beast.
a

agrosner

02/27/2023, 4:23 PM
one separate bug to report, if it is one. so ive linked up the used coordinates for first time in the project, using the configuration
apolloApi1UsedCoordinatesConsumer
. Hit build, and run into this error:
Copy code
> java.io.FileNotFoundException: /Users/**/project/**-graphql/build/generated/usedCoordinates/apollo/api1/usedCoordinates.json (No such file or directory)
if i run,
generateApiApolloUsedCoordinates
itll then work
m

mbonnin

02/27/2023, 4:23 PM
Mmm that rings a bell
a

agrosner

02/27/2023, 4:24 PM
maybe i need to manually link up the gradle tasks to another one?
m

mbonnin

02/27/2023, 4:25 PM
Mmm I was thinking this one maybe but since you're on 3.7.4 it should be fixed already 🤔
Can you share the full stacktrace when this happens?
a

agrosner

02/27/2023, 4:26 PM
oops. im on 3.7.1 in this branch. let me pull our latest dev which should have 3.7.4 now
m

mbonnin

02/27/2023, 4:26 PM
Ah !
🤞
a

agrosner

02/27/2023, 4:27 PM
and yeah we use configuration cache. so its probably related
m

mbonnin

02/27/2023, 4:27 PM
Looks really similar
a

agrosner

02/27/2023, 4:27 PM
🙏 again!
m

mbonnin

02/27/2023, 4:28 PM
Also separate thing but if you have some insights about how modularization helps you, I'd love to hear any kind of feedback. It's typically really hard to measure this but if you had number like maybe "build time after changing a query in a feature module" vs "build time after changing the schema module"
If you're interested, we could even run a joint blog post or something. I feel like there's a lot to tell about the modularization story with GraphQL and you're way ahead of many teams
a

agrosner

02/27/2023, 4:42 PM
ah thank you! we don’t have separate metrics for before and after, because we’ve had modularization from the start 😏 some high level insights: 1. modularization has enabled us to logically separate our graphql queries out into feature related pieces 2. we can reuse our graphql fragments in feature modules very nicely. this works extremely well for a reusable component experiences framework ive developed at wayfair. We can then reuse fragments from union types in different queries with minimal effort to integrate UI with minimal effort. I wish i could share more publicly nod
Copy code
If you're interested, we could even run a joint blog post or something. I feel like there's a lot to tell about the modularization story with GraphQL and you're way ahead of many teams
would be happy to chat about it
49 Views