Weave Code
Rokka Io Api Platform Bridge Laravel Package
terminal42/rokka-io-api-platform-bridge
A bridge that connects Rokka.io’s image CDN with API Platform, helping expose optimized Rokka image URLs in your API resources. It streamlines integrating Rokka image stacks and transformations into API Platform-powered applications.
Provides collection and item providers, data persisters and more to easily integrate ApiPlatform and rokka.io
Frequently asked questions about Rokka Io Api Platform Bridge
- Is terminal42/rokka-io-api-platform-bridge a Laravel package?
- No. Despite often being listed alongside Laravel packages, it is a Symfony and API Platform integration for the Rokka.io image CDN. It ships no Laravel service provider, facade, or config publishing, so a composer require drop-in for a Laravel app will not work. Laravel teams should use the vendor's plain PHP SDK or a Flysystem adapter instead.
- How do I install terminal42/rokka-io-api-platform-bridge?
- Installation is Composer-only: run composer require terminal42/rokka-io-api-platform-bridge and make sure the Rokka PHP client is available. There is no schema, infrastructure, or runtime service added beyond the Rokka dependency you would already have. Pin an explicit version constraint such as ^1.1 so a future minor release cannot silently enter via composer update.
- Which API Platform versions does this bridge support?
- The 1.1.0 changelog is silent on which api-platform/core majors are supported, so this needs confirmation from the maintainer. API Platform 3 reworked the media and upload internals that a bridge like this hooks into. If the package targets API Platform 2.x only, adopting it plants a second migration debt behind your Symfony upgrade.
- What PHP and Symfony versions are supported?
- Release 1.1.0 adds PHP 8.* and Symfony 5 and 6 support, building on 1.0.5. Those are stated as ranges rather than a documented, tested CI matrix, so treat them as a floor and not a guarantee. Verify PHP 8.3 and 8.4 behavior and confirm the Symfony 6 claim on 6.4 LTS before committing.
- What does this package actually provide?
- It supplies collection and item providers, data persisters and related helpers that wire Rokka image handling into API Platform's resource conventions. The goal is to keep Rokka image stacks and transformation logic out of your application code. It is intentionally a thin adapter rather than a full media management platform.
- Can I use this bridge in a Laravel application, and what is the alternative?
- No, this is a framework mismatch and the integration path is not supported. The equivalent Laravel approach is the vendor's plain PHP SDK (rokka-io/rokka-client-php) or a Flysystem adapter behind your own storage abstraction. That requires more code, but it avoids fighting a Symfony-first package inside Laravel.
- Does release 1.1.0 help me upgrade from PHP 7.x and Symfony 4.4?
- Yes, that is essentially the entire business value of 1.1.0. It is a compatibility release adding PHP 8 and Symfony 5 and 6 support without changelog-documented API surface changes, so it removes the bridge as the blocker in a framework upgrade. Upgrade in order: PHP 8.x first, then Symfony 5.4 LTS, then Symfony 6.4.
- How are Rokka credentials and signed URLs handled by the bridge?
- Rokka stack operations use signed URLs backed by a secret, and the bridge does not remove that responsibility from you. Secret handling, rotation, and cache-invalidation behavior remain yours to own regardless of what the package does. Keep Rokka configuration in environment variables and rotate secrets on a defined schedule.
- Is the package actively maintained and safe to use in production?
- Expect medium-to-high maintainer risk: it is a single-agency package with low cadence, and the jump from 1.0.5 straight to 1.1.0 suggests episodic releases. There is no published response-time track record, so assume you may need to fork and patch. The bigger long-term dependency is commercial continuity of the Rokka CDN itself, so confirm your agreement and exit path.
- How should I test resources that return Rokka image URLs, and can I swap the CDN later?
- Avoid calling the CDN in tests; assert the generated URLs and transformation parameters behind your own interface instead. Keeping Rokka calls behind an application-owned abstraction makes a future swap to Cloudinary, imgix, or self-hosted storage a bounded change. Mock that interface in unit tests and keep a small integration test against a real Rokka stack for confidence.
Weaver
How can I help you explore Laravel packages today?