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.

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

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

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

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 😁

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

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

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