Cache queries

[k0ka]

• Added or updated tests
• Documented user facing changes
• Updated CHANGELOG.md

Changes

Query caching has been added: the result of GraphQL\Language\Parser::parse() will be serialized and stored in the Laravel cache. It can be disabled in the config.

I tested it on my production queries and it shows about 5-10% performance boost. I use Relay with a lot of fragments.

I use sha256 hash of query as a key. So we may develop it further towards implementing Apollo Automatic persisted queries. While Relay currently uses md5 hashes for their Persisted queries, I guess they will change it soon to a better hashing algorithm.

Breaking changes

GraphQL::executeQuery() is deprecated and should be removed in the next version. parseAndExecuteQuery() or executeParsedQuery() should be used instead. This PR has a simple executeQuery() stub that executes one of above methods depending on the query type.

[spawnia]

Suggested change

	The GraphQL schema doesn't affect query parsing, so you have to flush query cache only on the package update.
	Make sure to flush the query cache when you deploy an upgraded version of the dependency `webonyx/graphql-php`:
	some-one-liner that clears the cache?

[k0ka]

I can add another command like lighthouse:query:cache:clear but it only clears the cache store. So I guess it's easier to just use the laravel default command.

[spawnia]

That Laravel command clears all caches?

[k0ka]

it fully clears the default store. If the user specified non-default store for query cache they should add an argument to the command
php artisan cache:clear --store=query_cache_store

[spawnia]

I need to think about the deprecation of executeQuery() and the naming of the new methods.

Perhaps we should extract a method parse(string $query): DocumentNode?

[k0ka]

Perhaps we should extract a method parse(string $query): DocumentNode?

This method might also throw a SyntaxError which must be caught and wrapped in the ExecutionResult. So it's better to leave parseAndExecuteQuery() and it is not too big and complex to split it.

[spawnia]

I could imagine the memoized parse() method being useful by itself.

[k0ka]

I extracted the GraphQL::parse() method

[spawnia]

Like the extracted method, just a few more nits regarding the docs.

Considering Automated persisted queries, would you foresee further changes to the proposed API?

[k0ka]

Considering Automated persisted queries, would you foresee further changes to the proposed API?

I don't thinks this API will have any changes. We will have to add another method like getParsedQueryByHash(string $sha256hash): DocumentNode. It should get the corresponding cache value and return apollo compatible error if this value is not present in the cache.

[spawnia]

The API of the GraphQL class is one thing that might have to change, but I am also concerned about the configuration format. We have some questionable structure in the config file (schema.register...) already. I would like to implement both features at once to make sure they fit together nicely, The config for APQ would probably overlap with query_cache quite a bit.

I can look into this myself, but am also quite happy if you push it further.

[k0ka]

I added the APQ support. webonyx/graphql-php already supports it so it was quite easy.

As for config schema: I guess the better cache format will be like this:

'cache' => [
    'schema' => [
          'version' => env('LIGHTHOUSE_CACHE_VERSION', 1),

          // other parameters that are currently in the cache.*
    ],

    'query' => [
          // parameters from query_cache
    ],

    'validate' => [
         // future parameters for https://github.com/nuwave/lighthouse/issues/2018
    ],
]

But it will break backward compatibility. So I guess it's easier to leave as is and refactor it in the next major version.

[spawnia]

Awesome job!

[spawnia]

@k0ka invited you as a collaborator. If you would like to join our Slack, I can add you to our collaborator chat as well.