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

Jacob Rhoda

10/13/2023, 5:59 PM
Forgive me if this is a really dumb question. I’ve been thinking about ergonomics for data fetched from a GraphQL API with Apollo. I find it kind of weird that you have to do this dance where you reach into an object, then have to reach into the fragment if you’re using fragments, rinse and repeat. This can be quite cumbersome if you have a lot of nested fragments. From what I see in our web clients, the JS library doesn’t have to do that sort of thing. You use the objects like the data is just there, as if fragments don’t exist. This is nice because your client code doesn’t have to worry about the implementation details at all. In fact, with TypeScript you “just” define an interface and conformance, and then you use the object without having to copy things and the implementation is unimportant. I’d love something like this with Apollo Kotlin–but perhaps I’m thinking about it wrong.
b

bod

10/13/2023, 6:07 PM
But in case of polymorphism what would happen? E.g.
Copy code
query Animal {
  ... on Dog {
    bark
  }
  ... on Cat {
    meow
  }
}
j

Jacob Rhoda

10/13/2023, 6:23 PM
Hmm, I forgot about polymorphism. I suppose It would be nice if you could leverage polymorphism from the language.
b

bod

10/13/2023, 6:28 PM
So there actually is a way to do that, with the responseBased codegen. Here is some reading material about it: https://www.apollographql.com/docs/kotlin/advanced/response-based 😁
👀 1
m

mbonnin

10/13/2023, 8:49 PM
There's one fundamental difference between TS and Kotlin which is that the TS types are mostly erased at runtime. The compiler and runtime work is a lot easier for TS
responseBased
has a bunch of issues like this one for an example.It works well in simple cases but complex queries become really hard to handle
j

Jacob Rhoda

10/13/2023, 9:05 PM
Yeah, I am remembering now reading about that. I can also imagine that it might make things hard for the normalized cache as well.
m

mbonnin

10/14/2023, 12:07 PM
Normalized cache should be relatively independent of how we model the Kotlin classes. It doesn't know about fragments. All it sees is flat lists of Records
The pain point is really that GraphQL is very expressive and the size of the generated class hierarchy grows exponentially with the nesting of fragments
I think TS can handle it better because the compiler doesn't have to generate all this bytecode. But even in TS limits are reached sometimes: cf this issue