Cache implementation: best practices and dealing with queries/mutations that shouldn't be cached

[ajanini]

Versions:

• graphql-laravel Version: 2.1.1
• Laravel Version: 5.7.28
• PHP Version: 7.1.32

I know I'm using old versions and upgrades are in the works.

Question:

I've been looking into setting up a caching system in my GraphQL API and I've done some basic stuff, including extending the GraphQL controller and storing JSON responses in Redis.

I'm not sure, however, how to deal with queries and mutations that should not be cached.

I was thinking of implementing an interface ShouldCache in individual queries and mutations, in a similar manner that Laravel uses the ShouldQueue interface, but I'm not sure how to check if the Query/Mutation class implements this in the Controller, since the execution of the query appears to be isolated in it's own service container.

I had previously dealt with caching in the Query level, but the return values from the resolve() method is pretty complex and it defeats the purpose of caching just the final JSON response. That, and it seems messy to implement at this level.

What are the best practices for caching and GraphQL? Should I use a different approach?

Thanks

[illambo]

I write down useful information for a possible future implementation analysis:

• https://www.apollographql.com/docs/apollo-server/performance/apq/

[illambo]

I have implemented a first pr #701 related to APQ, the next chapter that if I can I would like to see is the caching.

[mfn]

FTR, basic APQ supported is now released with https://github.com/rebing/graphql-laravel/releases/tag/7.1.0

What it could support is regular HTTP caching as:

• you can do GET requests
• you don't have to resend absurd big queries as you just send the hash of it on successive calls

But yes, besides that, there no other kind of built-in caching support at the moment and everything is up to the imagination of the developers.

I would say areas where caching is most effective:

• avoid re-parsing the same queries again and again (APQ could do this, but not the basic version yet just released)
• avoid resolvers being executed, i.e. on a query/mutation and field level

There are likely other ways, but those two came to mind mind first to reduce triggering "expensive" parts of GraphQL.

I'm reclassifying this as feature request issue!

[illambo]

I note my thoughts on this, to move forward on the topic I think it is important to first implement another "thorny" one, the directives (topic of which this package I find is left behind).
See in fact how the cacheControl directive it is used in apollo docs.
Some time ago I tried to write down a PR #703 but I did not have the opportunity to continue and I found it complex.
I write this because maybe someone has the courage to take it in hand.
@mfn what do you think ?

[mfn]

No objections against directives! Looks super user and super complex but also super interesting 😬

[mfn]

avoid re-parsing the same queries again and again (APQ could do this, but not the basic version yet just released)

FTR, this has now been implemented: #740

[mfn]

@ajanini in the latest RC2 we've been working on a new "execution middleware" approach.

The whole request of GraphQL query/mutation now flows through a pipe calling the middlewares in succession like this

graphql-laravel/config/config.php

Lines 222 to 228 in d9c4f12

	'execution_middleware' => [
	\Rebing\GraphQL\Support\ExecutionMiddleware\ValidateOperationParamsMiddleware::class,
	// AutomaticPersistedQueriesMiddleware listed even if APQ is disabled, see the docs for the `'apq'` configuration
	\Rebing\GraphQL\Support\ExecutionMiddleware\AutomaticPersistedQueriesMiddleware::class,
	\Rebing\GraphQL\Support\ExecutionMiddleware\AddAuthUserContextValueMiddleware::class,
	// \Rebing\GraphQL\Support\ExecutionMiddleware\UnusedVariablesMiddleware::class,
	],

This would allow caching like this example from the tests

graphql-laravel/tests/Unit/ExecutionMiddlewareTest/CacheMiddleware.php

Lines 12 to 20 in ff5bf93

	class CacheMiddleware extends AbstractExecutionMiddleware
	{
	public function handle(string $schemaName, Schema $schema, OperationParams $params, $rootValue, $contextValue, Closure $next): ExecutionResult
	{
	return new ExecutionResult([
	'examples' => [['test' => 'Cached response']],
	]);
	}
	}

---

However, thinking about this more, the resolver middleware might almost be more appropriate, see https://github.com/rebing/graphql-laravel#resolver-middleware

It can be applied on an individual query/mutation and you basically intercept the resolve() call and can decide to return something else instead.