- How do I use rikudou/psr6-dynamo-db in a Laravel application?
- Install it with Composer and use it as a plain PSR-6 pool or PSR-16 simple cache inside a bounded service, since the package is framework-agnostic and does not depend on Laravel. For application-wide use, wrap it in a class implementing Illuminate\Contracts\Cache\Repository and register that store through Cache::extend in a service provider. Either path requires you to provision the DynamoDB table and AWS credentials yourself. Direct PSR-16 usage is the cheapest and lowest-risk integration.
- Does rikudou/psr6-dynamo-db ship a Laravel cache driver or service provider?
- No. The package provides PSR-6 and PSR-16 implementations only, with no Laravel service provider, facade, or config/cache.php driver out of the box. To make it available as a Laravel cache store you must write a small adapter and register it via Cache::extend, then add an entry to config/cache.php. Budget time for that adapter, its tests, and observability around DynamoDB errors.
- How do I install and configure the DynamoDB cache pool?
- Run composer require rikudou/psr6-dynamo-db, create a DynamoDB table, and construct the cache pool with your AWS SDK client and table configuration. Check the package's composer.json for the exact PHP, PSR, and aws/aws-sdk-php version constraints before installing, because the README is sparse on configuration details. Read the source to confirm which DynamoDB attribute names and partition key layout it expects.
- How does TTL expiry work with this DynamoDB cache implementation?
- DynamoDB's native TTL does not delete items immediately; expired items can linger for hours or days, so a correct PSR-6 implementation must also enforce logical expiry by comparing a stored expiration timestamp on read and treating stale rows as misses. Verify this behavior with contract tests for get, has, and getItem before relying on it. Never treat DynamoDB TTL deletion as a correctness guarantee, especially for anything security-sensitive. Expired items also continue to consume storage and read capacity until DynamoDB removes them.
- Can I use DynamoDB instead of Redis for Laravel caching?
- Only conditionally. It fits AWS-native deployments such as Bref/Lambda, ECS, or multi-region setups where running ElastiCache or Redis adds operational burden, and it is reasonable for tolerant-staleness data like API response fragments, feature flags, and computed values. It is a poor fit for sessions, queues, locks, rate limiters, or anything requiring strict read-after-write consistency, because DynamoDB reads are eventually consistent by default and throttling behaves differently from Redis. Keep Redis or the database cache as your default and fallback store.
- What DynamoDB table schema and IAM permissions does this package require?
- Provision a dedicated table with on-demand capacity, a TTL attribute enabled, and encryption at rest, then grant least-privilege IAM permissions for the item operations the pool actually uses, such as GetItem, PutItem, DeleteItem, and any batch variants. The README does not document the expected partition key strategy, so confirm it in the source and test for hot-partition behavior with your real key distribution. Avoid sharing the table with unrelated workloads so throttling and cost stay attributable.
- Does the package support Laravel cache tags and cache prefixes?
- There is no native cache tag support, because PSR-6 tags are not part of the base interface and Laravel's tagging is a Redis/Memcached-oriented feature. Key prefixing is something you will need to handle yourself, typically in your adapter by prefixing keys before they reach the pool. If you need tag-based invalidation, design explicit key namespaces or versioned keys instead.
- Can I test rikudou/psr6-dynamo-db against DynamoDB Local?
- The package talks to DynamoDB through the AWS SDK, so pointing the client at a local endpoint via the standard endpoint override is normally possible, but the README does not document a DynamoDB Local workflow. Plan to write your own integration tests that run against DynamoDB Local or a disposable test table, and keep a fake PSR-6 pool for fast unit tests. Contract tests for serialization, key normalization, and expiry are essential before production use.
- What are the production limitations and cost risks of caching in DynamoDB?
- DynamoDB caps item size at 400 KB, so large cached payloads must be compressed, chunked, or rejected. Reads are eventually consistent by default, hot partitions can throttle, and every cache read is a billed request, which can cost more than Redis for read-heavy workloads. Under credential expiry or a regional outage your cache calls will fail, so wrap the pool with timeouts, a circuit breaker, and a fallback store.
- Is rikudou/psr6-dynamo-db well maintained, and can I fork it if it stalls?
- Adoption signals are weak, with roughly seven stars and no known dependents, and a recent release alone is not proof of maintenance depth. The MIT license makes forking straightforward, so treat it as a conditional pilot rather than a default Laravel dependency and plan an internal exit strategy. Pin the version, vendor the code if needed, and keep your adapter thin so you can swap in another PSR-6 implementation or the AWS SDK directly.