Reusing existing data classes in GraphQL Client

[ianmichell]

Hopefully I word this question correctly with enough context to get the correct answer.

I have a suite of micro services that produce individual GraphQL endpoints that are federated downstream by apollo. A lot of these services take advantage of a shared object model (I'm a sucker for keeping code duplication to a minimum). Most of these services maintain current state of immutable mutations for their respective models (event sourcing).

Now I'm in the awkward position whereby I need to share data and whilst I am usually fairly happy with maintaining a current state of "shared" objects across each of the micro services when they get picked up off kafka, if anything goes wrong in that scenario I will end up with a few synchronisation issues (and whilst I could reprocess the events in that scenario, I want to explore an alternative).

These micro services all register in a consul service mesh on kubernetes for configuration and discovery. My current thinking is to take advantage of that to query respective items from those services, rather than maintaining local state for each service.

So my question is pretty simple (bearing in mind I am not planning on using the gateway for queries), can I configure the kotlin graphql client in such a way that I can take advantage of the existing model classes? Or am I still going to need to generate them from each of the service schemas? It's not immediately clear in the documentation if this is possible and whilst I noted that there is something for custom clients, it's not entirely clear if I still need to generate objects from these schemas?

[dariuszkuc]

In general, GraphQL clients will always generate the data classes based on the queries + schema as that ensures type safety of the generated model and also clients only get the data model that corresponds to their queries. Auto generated code for graphql-kotlin-client cannot use any of the your existing data models.

GraphQL request consists of three fields -> query String, operationName String (optional) and variables map of anything so technically you can just POST a request with those fields and marshall the response back using your data models.