Expedia Kotlin library supports GraphQL server and client. Kobby is focused on GraphQL client only. Thus, it is correct to compare only the client parts of these frameworks.
Both Expedia and Kobby are codegenerator plugins. But Expedia generates only predefined GraphQL queries. That is, you need to know all the queries you want to execute at compile time. For more details see here:
Whereas Kobby generates a GraphQL query generator. You get an engine that allows you to generate any GraphQL query at runtime by your GraphQL schema.
What advantages does this give us? We can distribute the engine generated with Kobby as a client library. Imagine you are writing a microservice with the GraphQL API. We can divide this microservice into 2 modules - API and implementation. In the API module, we will place the GraphQL schema, and, using Kobby, we will generate the GraphQL query generator by this schema. Next, we publish the API module to the Maven repository, and any client of our microservice can add dependency to this artifact to itself in order to perform the GraphQL queries it needs. We do not know what kind of queries the clients of our microservice will need, but we do not need to know this - Kobby allows to generate any query at runtime.
The client of our microservice can be either another microservice or an Android application. But to be honest, I haven’t tried using the client generated with Kobby in an Android app yet. You can be a pioneer in this.
Another unobvious advantage of Kobby is its adherence to the “fail first” paradigm. Imagine that you are participating in the development of a large microservices platform. If you change the API of your microservice, then your clients will know about it at compile time, not at runtime, as is the case with REST or the “usual” GraphQL API.
An example of a GraphQL microservice, split into 2 modules, and publishing its API through the Maven repository, you can see here: