⭐ [Enhancement]: "Complete" Cache Features

[JerryNixon]

What is it?

• Introduce cache headers
• Add support for stored procedures
• Introduce level 2 cache: Redis/Garnet
• Enable caching through the CLI

Today, in-memory caching is enabled globally and at the entity level.

{
  "runtime": {
    "caching": {
      "enabled": true,
      "ttl-seconds": 10
    }
  }
}

And then at the entity level:

{
  "entities": {
    "Book": {
      "caching": {
        "enabled": true,
        "ttl-seconds": 10
      }
    }
  }
}

Proposal 0: Support Stored Procedures

There’s no technical reason to omit procs.

In a recent Dab community poll, 25% of exposed objects were stored procs.

Proposal 1: CLI Enhancement

1. Add caching to the add and update verbs.
2. When enabled for an entity, auto-enable globally.

This is not a breaking change, as caching was not previously in the CLI.

Proposal 2: HTTP Headers

Add support for Request Headers:

1. Cache-Control: no-cache: Forces a query submission to the database.
2. Cache-Control: no-store: Prevents caching the response.
3. Cache-Control: only-if-cached: Returns 504 Gateway Timeout if unavailable.

⚠️ These request headers are always echoed back in the response headers.

Add support for Response Headers:

1. When caching is involved, always add Cache-Control: public/private, max-age: {ttl-seconds}.

This would introduce the following configuration:

{
  "entities": {
    "Book": {
      "caching": {
        "enabled": true,
        "ttl-seconds": 10,
        "response-directive": "<string> (default: empty)" // new
      }
    }
  }
}

All DAB does is echo back in the configuration response-directive setting unique for this entity in the HTTP response header named Cache-Control. If this setting is Empty or missing, the header will NOT be returned.

Example Cache-Control

Cache-Control="public, max-age=604800, stale-while-revalidate=86400"

The configuration setting can contain any string, and it will be echoed in the Response.

Proposal 3: Level 2 Caching

Level 2 caching means using a distributed cache that is available beyond just the session context in which it was created. In other words, multiple nodes that are in separate containers are able to access the cached data that a different node creates when making various queries via dab. This means that expensive queries generated by one node can be cached and used by other nodes with other session context.

We currently use Fusion Cache, which has native support built in for Redis (https://redis.io/).

Related Issues to Close

• [Enhancement] Cache Find Many Support #2300
• [Enhancement] Cache - Stored Procedure Support #2299
• ⭐ [Enhancement]: "Complete" Cache Features #2253
• 🥕[Enhancement]: Enable caching through CLI #2235
• [CLI]: dab update Cache Settings #1919

[seantleonard]

fyi for cache http headers https://github.com/Azure/data-api-builder/blob/main/docs/design/query-caching.md#disclaimer-about-applicability-to-this-design-doc