Add in-memory caching to QueryRunner

[chriszarate]

This is a performance and developer experience improvement to remove redundant query executions during a single request. It implements a simple in-memory cache in QueryRunner so that repeated identical queries are quickly resolved from cache.

Why is in-memory caching beneficial?

Mainly, because block bindings with identical queries are often repeated within a remote data block. For example, this remote data block has 7 children core blocks with block bindings, each of which needs the same data from the exact same query:

Currently, for this example, our block binding resolver function executes the exact same query 7 times. Via our Guzzle client, the redundant query executions resolve from object cache. On top of this, WP Core implements its own in-memory cache for object cache, which means that there is only one network request to object cache.

So why do we need this additional caching? Two main reasons:

1. There is additional post-processing that happens after the query is executed. The response is parsed as JSON and traversed recursively by JsonPath in order to extract the values defined by the query's output schema.
   • In aggregate across many blocks (or across many posts on an archive page), this can be expensive.
   • Additionally, the plugin user has the opportunity to define their own callback functions to generate or transform this output, which might contain expensive code. They might have the (very reasonable) expectation that these callback functions would only be called once.
2. While we will soon cache error responses in object cache (Cache error responses for a short time #474), some errors unavoidably manifest as exceptions that must be caught, and therefore cannot be cached by Guzzle middleware. We do not want to repeat these requests many times over within the same request.

It has a small side benefit of removing the appearance of multiple calls in our logging and debugging tools:

Before	After

Why implement in-memory caching here?

The QueryRunner implements query execution and response parsing, so it feels like a natural location. We could implement caching at the block binding level, but use cases that executed queries directly (e.g., custom code, REST API, interactivity API) would not benefit.

Another option is to inject the post-processing logic into our Guzzle middleware and cache the result, but that could result in breakage when processing code is updated. It's much safer to cache the raw API response.

[github-actions]

Test this PR in WordPress Playground.

[ingeniumed]

Just one item that needs to be tweaked, otherwise this is good with me.

[ingeniumed]

I noticed that this is still being referenced in QueryRunner#get_response_metadata, just need to remove that.

[chriszarate]

Opted to restore it for now in 64549e9