If the dApp is using Apollo Client, the context object passed into the resolvers will contain a client property, which is the Apollo Client instance. This will allow the resolvers to query the subgraph for data. This isn't apart of the GraphQL standard and is something specific to Apollo Client. If resolvers depend on this context.client object being present it'll cause complications if the dApp chooses to not use Apollo.
I propose that, if we detect context.client is not present, we add it for the resolvers. This context.client would simply have a query(...) method, same signature as Apollo. This query(...) function could end up executing the query using the query-engine, or an HttpLink we construct for the resolvers to use. Additionally, createMutations could have an optional queryExecutor argument, the same way it currently has a mutationExecutor argument so dApps can stub out all interal Apollo usage.
If the dApp is using Apollo Client, the context object passed into the resolvers will contain a client property, which is the Apollo Client instance. This will allow the resolvers to query the subgraph for data. This isn't apart of the GraphQL standard and is something specific to Apollo Client. If resolvers depend on this context.client object being present it'll cause complications if the dApp chooses to not use Apollo.
I propose that, if we detect context.client is not present, we add it for the resolvers. This context.client would simply have a query(...) method, same signature as Apollo. This query(...) function could end up executing the query using the query-engine, or an HttpLink we construct for the resolvers to use. Additionally, createMutations could have an optional queryExecutor argument, the same way it currently has a mutationExecutor argument so dApps can stub out all interal Apollo usage.