I have a huge number of REST microservices and we use OpenApi codegen to create clients and models for our mobile apps to use. So android, for example, developers are used to calling this sort of client API
public interface DetailsApi {
@GET("foo/bar")
Call<MyObject> getFoo();
}
We’re moving to GraphQL and Apollo client and giving developers query results based on our new schema and queries. So developers are using client APIs like this:
fun getFoo(): ApolloResponse<FooQuery.Data> {
return apolloClient.query(FooQuery()).execute()
}
Developers are unhappy that we have a combination of object models and mixing REST response objects and ApolloResponse<Data>
There’s a lot of concern that as we migrate to Apollo there’s going to require a lot of re-work of our app because there is no standard object model. I keep playing defense around the idea that we add some sort of normalization layer in our data access layer so the front end developers only work with a standard object model. That seems like a huge amount of bug prone overhead.
I was wondering if there was any solution to this I’m missing. It would be great if I had a sift and kotlin client that could call a REST service and return an ApolloResponse. I can’t just ask the backend guys to pump the gas on putting graph in front of the REST apis.