I was thinking of wrapping my Apollo client code in a sort of “repository” module, abstracting away ...

# apollo-kotlin

[Jacob Rhoda]

I was thinking of wrapping my Apollo client code in a sort of “repository” module, abstracting away any actual Apollo stuff. However, my generated Apollo fragments still depend on the Apollo APIs and give me errors when I try to use it from another module that doesn’t have any dependency on Apollo. Is there a work around, or should I be copying data out of my fragments and into my own types? Seems inefficient.

[mbonnin]

You can expose apollo-api instead of apollo-runtime to your other modules but it's true some of the Apollo API are exposed in models

[mbonnin]

What's the concern? If it's about domain separation and being able to switch your network stack, Executable.Data is probably a minor thing in the grand scheme of things.

[Jacob Rhoda]

Yessir, domain separation is the idea. I don’t mind exposing the Executable.Data type. How do I go about doing that?

[mbonnin]

You'd have to expose the whole apollo-api as API in your repository module:

dependencies {
  implementation("com.apollographql.apollo3:apollo-runtime")
  implementation("com.apollographql.apollo3:apollo-api")
}

[mbonnin]

It means you now have all the apollo-api symbols in your compile classpath for projects that depend on it but I think it's not that bad?

[mbonnin]

If you really want to only keep Executable.Data (and the other bits that are used like Query, Operation , Adapter), you could strip the apollo-api.jar but I wouldn't really recommend that

[Jacob Rhoda]

That sounds complicated and like it could break easily.

[Jacob Rhoda]

(The stripping of the jar)

[mbonnin]

Yea, definitely not recommend 😄

[mbonnin]

Which leaves you with either wrapping models or exposing apollo-api transitively. Sorry I don't have a much better answer

[Jacob Rhoda]

I’m starting to wonder if it’s really worth doing this abstraction, but that is okay. We’re learning.

[Jacob Rhoda]

I can expose the API for now.

[mbonnin]

If you want to enforce that, you could maybe add a lint rule with detekt or something that checks on import com.apollographql.apollo3 . Not super familiar with this but that would be a way to have the kotlin compiler be able to still read the symbols and no one being able to write code using them

[Jacob Rhoda]

That’s actually a pretty good idea.