Forgive me if this is a really dumb question. I’ve...

# apollo-kotlin

[Jacob Rhoda]

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.

[bod]

But in case of polymorphism what would happen? E.g.

query Animal {
  ... on Dog {
    bark
  }
  ... on Cat {
    meow
  }
}

[Jacob Rhoda]

Hmm, I forgot about polymorphism. I suppose It would be nice if you could leverage polymorphism from the language.

[bod]

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 😁

[mbonnin]

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

[mbonnin]

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

[Jacob Rhoda]

Yeah, I am remembering now reading about that. I can also imagine that it might make things hard for the normalized cache as well.

[mbonnin]

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

[mbonnin]

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

[mbonnin]

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