I was thinking of wrapping my Apollo client code in a sort o kotlinlang #apollo-kotlin

I was thinking of wrapping my Apollo client code i...

Jacob Rhoda

07/27/2023, 4:31 PM

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

07/27/2023, 4:37 PM

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

07/27/2023, 4:41 PM

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

07/27/2023, 5:29 PM

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

mbonnin

07/27/2023, 5:30 PM

You'd have to expose the whole

apollo-api

as API in your repository module:

Copy code

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

mbonnin

07/27/2023, 5:31 PM

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

07/27/2023, 5:34 PM

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

07/27/2023, 5:34 PM

That sounds complicated and like it could break easily.

➕ 1

Jacob Rhoda

07/27/2023, 5:34 PM

(The stripping of the jar)

mbonnin

07/27/2023, 5:36 PM

Yea, definitely not recommend 😄

mbonnin

07/27/2023, 5:36 PM

Which leaves you with either wrapping models or exposing

apollo-api

transitively. Sorry I don't have a much better answer

Jacob Rhoda

07/27/2023, 5:37 PM

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

Jacob Rhoda

07/27/2023, 5:38 PM

I can expose the API for now.

mbonnin

07/27/2023, 5:42 PM

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

07/27/2023, 5:42 PM

That’s actually a pretty good idea.

🎉 1

Open in Slack

Previous Next