Graphql-flutter: Pass Client object as parameter, or let client object define query methods

[ened]

Currently, I have code like this:

lib/main.dart:

void main() {
  client = new Client(
    endPoint: 'https://api.github.com/graphql',
    cache: new InMemoryCache(),
  );
  client.apiToken = "...";

  runApp(new MyApp());
}

And somewhere in the app, I will then simply run my query like so:

return Query(
      readRepositories,
...
)

This is very simple, client & query are loosely coupled.
The client variable is actually a global.

I think it would be preferable to not have a global client object, and instead have it available as a (named) parameter to the Query or other objects.

Client could also define newQuery or newMutation methods for convenience.

[HofmannZ]

@ened Thanks for the suggestion. @eusdima I think we discussed this internally.

Both solutions don't seem ideal. Providing the client with each query or mutation is too cumbersome. And a global client variable is not useful if you might want connect to multiple endpoints.

Instead I propose to create a GraphqlProvider widget that takes a client as a param, and exposes it to all its children trough the context. This would mimic the behaviour of the ApolloProvider

What do you think?

[eusdima]

Creating a provider and passing client as context seems good, but you will not be able to use the client outside of the provider so maybe support both: GraphqlProvider and the old way.

We have to do performance measurement to make sure that the memory and cpu usage are not higher after switching to the GraphqlProvider.

So should we keep both or just GraphqlProvider?

[HofmannZ]

Well you can always declare the client somewhere in main.dart then pass that client to the GraphqlProvider. Now you can still use the client variable directly as needed.

We can also use ApolloConsumer to acces the compete client within the context tree.

[ened]

GraphqlProvider & GraphqlConsumer seem to be the most flexible. People could still put the client in a global variable, but TBH that seemed like a stop-over solution anyway.

I do not understand how this could impact performance in a substantial way?

[HofmannZ]

Lets do that, I’ll start on a PR later today. We have to setup some test to track the performance impact on the queries. ✌🏼

[HofmannZ]

👆🏼 Early feedback is much appreciated

[HofmannZ]

@ened,
I just finished PR #24, it implements the GraphqlProvider & GraphqlConsumer. I though you might want to have a look and give some feedback, since you brought the issue to light.

[ened]

@HofmannZ awesome! I'm on holiday right now 🍷🍷 and will check once back to desk.