hey quick question do apolloUsedCoordinates support multiple

Question

hey quick question do apolloUsedCoordinates support multiple services ``` gt 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

mbonnin · Answer

That should work Do you mind sharing more about your module layout

agrosner · Answer

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

agrosner · Answer

ok so our module layout is like this ```schema module1 gt schema module2 gt schema``` where ```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`

mbonnin · Answer

Damn you are 100 right

mbonnin · Answer

Same thing goes the other way too confused We can t have a feature module using 2 services referencing two different schema modules

mbonnin · Answer

Now the good new is that there is certainly a workaround let me try

mbonnin · Answer

Maybe this ```dependencies add apolloApi1UsedCoordinatesConsumer project module1 add apolloApi2UsedCoordinatesConsumer project module1 add apolloApi2UsedCoordinatesConsumer project module2 ```

mbonnin · Answer

trying to work on a reproducer

mbonnin · Answer

mbonnin · Answer

The reproducer has only one service in each feature module but it s the same idea

mbonnin · Answer

It s using the low level configurations instead of the catch all apolloMetadata and apolloUsedCoordinates configurations

mbonnin · Answer

The only important thing is to put add the dependencies after registering the services or else the configurations are not created yet

agrosner · Answer

Ahh interesting I ll try it out Thank you I was out sick past couple days so apologies for late acknowledgment

mbonnin · Answer

No worries at all thanks for bringing that up I hope you re feeling better

agrosner · Answer

this worked i made a convenience function ``` 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 ``` api1 project homepage graphql project homepage graphql project graphql ```

agrosner · Answer

also from the <https github com apollographql apollo kotlin releases tag v3 7 0|docs on 3 7 0> it was not quite clear that we needed `implementation` on our schema alongside `apolloSchema` and `apolloMetadata`

agrosner · Answer

might be fun to added a combination configuration that or named better is like ```apolloSchemaConsumer project schema ``` that does `implementation` `apolloSchema` and `apolloMetadata`

mbonnin · Answer

Awesome Glad to hear it worked

mbonnin · Answer

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>

mbonnin · Answer

In the end it s going to look like this ``` 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 ```

mbonnin · Answer

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

agrosner · Answer

ahh niceee

agrosner · Answer

thats really cool

agrosner · Answer

one more question for the used coordinates do intermediate modules we have common graphql modules also need to declare `apolloSchema` im guessing yes

agrosner · Answer

say we have schema gt module a gt module b module b declares queries module a declares reusable fragments

mbonnin · Answer

Yes the schema is required in both module a and module b

agrosner · Answer

cool thanks

mbonnin · Answer

Sure thing

agrosner · Answer

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 infinity

mbonnin · Answer

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

agrosner · Answer

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 ``` gt java io FileNotFoundException Users project graphql build generated usedCoordinates apollo api1 usedCoordinates json No such file or directory ```

agrosner · Answer

if i run `generateApiApolloUsedCoordinates` itll then work

mbonnin · Answer

Mmm that rings a bell

agrosner · Answer

maybe i need to manually link up the gradle tasks to another one

mbonnin · Answer

Mmm I was thinking <https github com apollographql apollo kotlin issues 4565|this one> maybe but since you re on 3 7 4 it should be fixed already thinking face

mbonnin · Answer

Can you share the full stacktrace when this happens

agrosner · Answer

oops im on 3 7 1 in this branch let me pull our latest dev which should have 3 7 4 now

mbonnin · Answer

Ah

mbonnin · Answer

crossed fingers

agrosner · Answer

and yeah we use configuration cache so its probably related

mbonnin · Answer

Looks really similar

agrosner · Answer

thank you again

mbonnin · Answer

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

mbonnin · Answer

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

agrosner · Answer

ah thank you we don t have separate metrics for before and after because we ve had modularization from the start smirk 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

agrosner · Answer

```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