Support apollo client?

[mweststrate]

Currently, mst-gql is based on graphql-request. Not using apollo client has a few benefits

• much smaller footprint
• easy / simple setup

However, using apollo might have soon benefits as well

• gradual adoption, if the apollo client can be used as networking layer
• benefit from features not present in mst-gql, or which are in a more mature state in apollo
• It could be interesting to research whether the mst-gql RootStore could act as appollo's caching layer, as it is serializable out of the box for example.

Using apollo as transportation layer is possibly already easy to achieve, by creating an { request(query, variables): Promise } object, that wraps around apollo client, and providing that as httpGqlClient when creating a store

[danielkcz]

Using the whole apollo-client might be overkill indeed. However, apollo-link alone is nicely made (build on top of observables) and I am fairly certain it can be used without client to facilitate the whole communication layer including batching or query deduplicating.

The client main selling point is the management of cache and that's not something this package needs.

It's important to realize that hardcoding HTTP transport isn't the best approach. When writing app tests, the ability to replace network request by using different link composition to facilitate mocked response is priceless.

[elie222]

Not sure how apollo-link fits in here, but Apollo Client accepts different cache mechanisms. An article on it: https://medium.com/homeaway-tech-blog/creating-your-own-apollo-cache-for-perf-and-profit-8f786849e5f6

And some cache implementations: In Memory Cache (Apollo default): https://github.com/apollographql/apollo-client/tree/master/packages/apollo-cache-inmemory Hermes: https://github.com/convoyinc/apollo-cache-hermes

[danielkcz]

@elie222 The cache is not composable. You would have to use customized MST cache for a whole project (or keep separate client instances). That makes the gradual adoption much harder.

I think the graphql-request can be used by default, but with an option to supply client instance that should be used for running queries. Possibly other adapters for alternative solutions.

[RXminuS]

Just my 2cts...I don't think it might be worth (at least for now) putting in a lot of gradual adoption code from Apollo. I think if we instead focus on making MST & mstQL work really great on their own there will be enough of an audience that simply switch over in a larger refactor (like us). Especially since the MST way of structuring your application is VERY different from Apollo's component first approach.

[barbalex]

Switching over from apollo right now, I see how great it is that after loading, data is automatically refreshed wherever it is referenced.

Maybe I was doing it wrong but in apollo I had to refresh/update the cache for every query that fetched the data in question.