Caching GraphQL POST requests

[rafatwork]

#487 allowed page caching GraphQL requests.

As far as I can see this only applies to GET requests since Drupal's \Drupal\Core\PageCache\DefaultRequestPolicy uses the \Drupal\Core\PageCache\RequestPolicy\CommandLineOrUnsafeMethod() rule which eventually decides in \Symfony\Component\HttpFoundation\Request::isMethodCacheable() that only GET and HEAD requests are cacheable.

I would like to cache GraphQL POST requests in one of my projects. I was able to achieve this by swapping out \Drupal\Core\PageCache\DefaultRequestPolicy with a custom implementation that extends \Drupal\Core\PageCache\RequestPolicy\CommandLineOrUnsafeMethod(), explicitely allowing caching GraphQL POST requests, as such:

  /**
   * {@inheritdoc}
   */
  public function check(Request $request) {
    if (!$this->isCli() && $request->getMethod() === 'POST' && $request->attributes->has('_graphql')) {
      return static::ALLOW;
    }

    return parent::check($request);
  }

Has anyone already tried doing the same? Perhaps in a different way? Any potential issues I should be wary of?

Is this a feature that might be worth looking into adding to the GraphQL module, especially since POST is more or less the default behaviour in GraphQL?

[LennardWesterveld]

Hi,

I was looking at the same some hours ago :)
The results are also cached with the caching backend from graphql (cache.graphql.results). And they have also build-in there own RequestPolicyInterface see DenyQuery. So i think we rely on the caching table for graphql it self instead of the page_cache or dynamic_page_cache. But yes what you mentioned for the page_caching they have removed that from the DenyQuery tagging so maybe i could work with the page_cache :) but it won't advice it for post request especially when graphql have there own checks and caching backend.

[fubhy]

Hi,

I was looking at the same some hours ago :)
The results are also cached with the caching backend from graphql (cache.graphql.results). And they have also build-in there own RequestPolicyInterface see DenyQuery. So i think we rely on the caching table for graphql it self instead of the page_cache or dynamic_page_cache.

Exactly, the dynamic page cache is not sufficient for graphql query result caching. Instead, we have our own cache handler that is better suited for graphql requests and just as fast and effective otherwise.

[fubhy]

https://github.com/drupal-graphql/graphql/blob/8.x-3.x/src/GraphQL/Execution/QueryProcessor.php#L207-L209

[rafatwork]

Thanks for the great info.

Exactly, the dynamic page cache is not sufficient for graphql query result caching. Instead, we have our own cache handler that is better suited for graphql requests and just as fast and effective otherwise.

OK! But, and I probably had to go deeper into this when creating this ticket, what if you have a cache in front of your Drupal installation. GraphQL cache vs page cache won't make much of a difference performance wise I assume, but a CDN/Varnish will certainly do.

[fubhy]

If you want to cache in Varnish or with a CDN you will need to use persisted queries anyways at which point you are sending GET requests instead of POST requests which solves all of that.

[rafatwork]

If you want to cache in Varnish or with a CDN you will need to use persisted queries anyways at which point you are sending GET requests instead of POST requests which solves all of that.

Not entirely true. We are using varnish & caching POST requests is pretty trivial, eg. https://docs.varnish-software.com/tutorials/caching-post-requests/ . But I guess persisted queries are more popular in that regard.

[fubhy]

I didn't say that caching POST requests was not possible. It's actually also possible in CDNs. But you really don't want that with graphql. Persisted queries are the way to go for that.

[rafatwork]

Persisted queries have been an idea on our side, we just didn't get to it yet. Thanks for bringing it up.

But you really don't want that with graphql.

This phrase caught my attention though. Can't immediately find any information about this. Did you have bad experiences with this?