API response cache

[maikschneider]

Hey everyone,

I've been considering ways to enhance the performance of the t3api responses. Overall, I'm quite satisfied with the current performance. However, more complex endpoints with multiple relations and filtering can sometimes be slow.

To address this, I created a proof-of-concept extension called t3api_cache. The goal of this extension is to introduce a caching layer for requests. During serialization, the extension adds the corresponding cache tags to the response. These tags are then captured by a middleware that collects them, sets the cache, and cleans up the response.

I would appreciate it if you could take a look at the extension and share your feedback!

Thank you!

[Moongazer]

We're very interested in this feature too! Best would be to have something like this as core-feature, thanks for the proposal.

[klamparski]

Hi @maikschneider, thanks for starting this thread and for sharing your proof of concept — it was a helpful reference while designing this feature, and it confirmed the core idea we also arrived at: collect cache tags while the serializer walks the object graph, so invalidation is driven by the records a response actually contains. That mechanism is exactly what made it into the implementation.

The good news first: a native response cache is coming in t3api 5.0.0 — tracked in #146, with the implementation now up in #147. Feedback there is very welcome, especially from people who already explored this space. @Moongazer — "best would be to have something like this as core-feature" is precisely what happened.

Why configuration lives in the @ApiResource attributes array (a "cache" block) instead of a separate annotation:

• Per-operation control. Cache settings cascade from the resource to each operation, exactly like the existing pagination, persistence and upload settings — so you can cache the collection GET and the item GET differently, cache only one of them, or override single keys (lifetime, conditions) per operation.
• Consistency. All operation/resource settings in t3api are configured through the same attributes taxonomy; a standalone annotation would be the odd one out.
• Future-proofing. We are considering moving all of these settings to dedicated nested annotations at some point — but if that happens, it should happen for pagination, persistence, upload and cache in one coordinated pass, rather than introducing a single new annotation now and migrating it again later.

How the concept grew while generalizing it for core:

• Content-based tagging: every stored response is tagged with each record it actually contains — including nested relations — plus the resource's own table tag (so even an empty collection is invalidated when the first matching record is created).
• Granular invalidation: a plain record update flushes only that record's tag (responses embedding it refresh, unrelated ones survive); creates, deletes, moves and visibility changes flush at table level. Driven by DataHandler hooks and Extbase persistence events — no manual cache clearing in the normal editorial workflow.
• Security stays enforced: security expressions are evaluated on every request, including cache hits, so protected endpoints can be cached safely.
• Expression-based control: readCondition / writeCondition (e.g. skip caching for logged-in users, or a ?refresh pattern for cache warmers), identifierExpressions to vary the cache key (request header, TYPO3 Context aspect, current user), and tagExpressions / memberTagExpressions for dynamic tags (e.g. per-user tags, or tags derived from each entity in the response).
• Declarative write-side invalidation: a sibling cacheInvalidation block on write operations flushes declared tags after a successful POST/PATCH/DELETE — useful when a custom handler writes data that no DataHandler/Extbase event would otherwise report.
• Time-based visibility: a scheduler command invalidates tables where a starttime/endtime passed since its last run.
• Documentation including a debugging/troubleshooting guide ships with it.

Thanks again for the groundwork and the inspiration — it would be great to have your eyes on #147.

[Moongazer]

Holy moly, you have thought about many great details and edge-cases, it sounds amazing! Can't wait until I find some time to test the feature-branch. I'll give feedback ASAP, thank you very much for now! 🙂