Symfony Aop Cache Bundle Laravel Package

Getting Started

Before reaching for this in a Laravel app, note the name: tourze/symfony-aop-cache-bundle is a Symfony bundle, not a Laravel package. There is no extra.laravel.providers auto-discovery, no service provider, and no facade. First step is to confirm it is even relevant to your stack — if you are on Laravel, treat this as a source of ideas (attribute-driven method caching via AOP) rather than a drop-in dependency.

If you are working inside Symfony (or a Laravel app that embeds Symfony components), the minimal path is:

1. composer require tourze/symfony-aop-cache-bundle
2. Register Tourze\Symfony\AopCacheBundle\AopCacheBundle in config/bundles.php.
3. Ensure the AOP foundation is present (this bundle depends on the Tourze AOP layer / ray/aop-style proxying) — it wires a compiler pass that rewrites service definitions into proxy classes.
4. Annotate a service method with the cache attribute and confirm the proxy is generated by inspecting var/cache/dev after the first request.

First use case: caching an expensive, pure-ish service method (e.g. a repository lookup or an external API call) at the method level instead of hand-rolling Cache::remember() around every call site. The value proposition is declarative caching without touching call sites.

Because the release shipped only a changelog link (0.1.2...0.2.0) with no description of what changed, verify behavior against the actual composer diff / tag comparison before adopting — see Gotchas.

Implementation Patterns

Declarative method caching. The intended workflow is to put the cache attribute on the service method and let the AOP proxy intercept invocations. Callers stay ignorant of caching; the proxy computes a key (typically class + method + serialized arguments), checks the cache pool, and either short-circuits or stores the result.

#[Cache(ttl: 300)]
public function findProduct(int $id): Product { /* ... */ }

Pool wiring. The bundle's compiler pass injects a Symfony cache pool into the generated proxy. In a Symfony app you configure the pool in config/packages/cache.yaml and the bundle picks up its configured service. This is the main integration seam — if the attribute appears to do nothing, check which pool the proxy received.

Key strategy. Arguments are serialized into the cache key, so patterns that work well are scalar-argument methods and DTOs with stable __toString/serialization. For methods with object arguments, either implement __serialize deterministically or bypass caching for those calls.

Layering with AOP. Because this is an AOP cache, it composes with other Tourze AOP aspects (logging, transactions, rate limiting). Ordering matters: caching typically wants to sit inside transaction/logging aspects but outside the actual business method. Audit aspect priority if you stack more than one attribute on a method.

Laravel bridging (if you must). You would need to (a) install the Symfony cache + DI + AOP packages, (b) build a bespoke ServiceProvider that boots the AOP kernel and registers proxy-compiled services, and (c) fight Laravel's container resolution, which does not understand Symfony compiled service definitions. In practice it is cheaper to replicate the pattern with a Laravel middleware/decorator or a simple Cache::remember trait than to bridge the bundle.

Gotchas and Tips

• 0.x instability. 0.2.0 is still pre-1.0. Semver gives you no promise of backwards compatibility; a minor bump can rename attributes or change the proxy/compiler-pass contract. Pin the exact version and read the diff, not the changelog.
• The changelog is a black box. The release notes are literally just a compare URL. Treat 0.1.2 → 0.2.0 as unknown risk: run composer update tourze/symfony-aop-cache-bundle --dry-run -v, diff the src/ tree, and check for renamed attributes or constructor-argument changes to the cache attribute before upgrading.
• Proxy generation is the #1 debugging pain. AOP bundles rewrite services into generated proxies. If caching silently stops working after a deploy, clear both the container cache and the AOP proxy directory, and confirm the generated class actually contains the intercepted method. Stale proxies across deploys are the usual culprit.
• Opcache + generated classes. In production with opcache.validate_timestamps=0, regenerated proxies may not take effect until a PHP-FPM reload. Build proxies (or prime the cache) during deploy, not on the first request.
• Not Laravel-native. No facade, no config/aop-cache.php, no auto-discovery. Do not expect php artisan vendor:publish to produce anything. Every config quirk you hit has to be read from the bundle's DependencyInjection extension and Resources/config.
• Attribute vs annotation. Newer Tourze bundles use PHP 8 attributes; older docs may show Doctrine annotations. On 0.2.0 assume attributes only, and confirm the exact class name (Tourze\...) via the source — a wrong use statement fails silently when attributes are not resolvable.
• Extension point: the cache key generator and the pool service are the two things you will realistically want to override. Override the key-generator service definition in your own services.yaml rather than patching the bundle, so upgrades don't clobber your customization.
• Verification tip: write one integration test that calls the annotated method twice with a mutable fixture and asserts the second call does not hit the underlying code (e.g. increment a counter inside the method). This single test catches proxy failures, pool misconfiguration, and key-generation regressions after any 0.x bump — which, given the opaque changelog, is your best safety net.