I'll just throw these out there as an alternative, or in addition to: https://www.apollographql.com/docs/link/links/rest.html https://www.apollographql.com/doc

I'll just throw these out there as an alternative, or in addition to: https://www.apollographql.com/docs/link/links/rest.html https://www.apollographql.com/docs/link/links/rest.html https://www.apollographql.com/docs/link/links/state.html https://www.apollographql.com/docs/link/links/state.html The "apollo-link-rest" API makes it very easy to map, then query, your JSON APIs as a GraphQL service. So, no more mangling different query approaches for a client. Then, simply add "apollo-link-state" to query/mutate local data using GraphQL as well. This allows you to have 1 query/mutation language for both remote and local client state. This is much easier to deal with than adding yet another API to access your data. Another positive is that you just might find yourself with the ability remove some redux boilerplate too as your local state can now be managed via Apollo's HOCs. So, after writing this... What would be nice is to perhaps have the BlueChip API have an adapter layer that would allow it to read from something like the Apollo cache. This would allow for the implementation of resolvers on the client side to allow more fine grained control of the data being returned in a query (query parameter for filtering, cursoring and the like).