Client Bundle Laravel Package

Technical Evaluation

Architecture fit. Read the description carefully: this is a Symfony bundle, not a Laravel package. It registers DI services, a configuration tree, and autowiring aliases for rokka/client inside Symfony's kernel. Laravel's service container has no concept of bundles, extension classes, or config/packages/*.yaml trees, so the package cannot be installed into a Laravel app as delivered. The functionally important code is thin — it wires Rokka\Client services from config — which means the value we actually need lives in the underlying rokka/client SDK, not in this repo. 1.4.1 does not change this — it is a compatibility release only, adding Symfony 7 install support and PHP 8.3 test coverage; no new features, no API surface change.

Integration feasibility.

• Symfony target: high, and now higher. 1.4.1 explicitly permits installation on Symfony 7, so the bundle is viable on a current-symfony stack rather than needing a fork or a --ignore-platform-reqs workaround. One composer require, one config block, inject the client. A day or less.
• Laravel target: low for this package, essentially unchanged by 1.4.1. The underlying goal is still achievable — depend on rokka/client directly, hand-roll a ServiceProvider, a config/rokka.php, and optionally a facade. Realistic estimate: 1–3 engineering days for parity, plus testing.
• Non-framework PHP: trivial; just use the SDK.

Technical risk.

• Code risk: low. Small surface area, MIT, thin wrapper over a vendor-maintained SDK. A patch-level release with only constraint and CI changes carries negligible regression risk.
• Adoption/supply-chain risk: moderate. 8 stars, 0 dependents, and a low composite score mean essentially no community validation and no third-party battle-testing. Effectively a single-vendor artifact. This is now the dominant risk — the version-coupling concern below has been materially reduced.
• Version coupling risk: reduced (was moderate). This was our specific yellow flag: a single January 2024 release against a fast-moving framework, with no evidence the maintainer tracked Symfony majors. 1.4.1 answers that directly — Symfony 7 support and PHP 8.3 CI. Residual risk remains: no stated policy on how quickly future Symfony majors (8.x) will be picked up, and the release is ~a month-plus behind Symfony 7's availability rather than same-day. Re-check at each framework major.
• Product risk: moderate-to-high. Rokka is a commercial image CDN. Adopting it is a procurement, cost, and vendor-lock-in decision, not just a library choice. Unchanged.

Key questions.

1. Is the actual target Symfony or Laravel? If Laravel, this package is a non-starter and we should evaluate rokka/client instead.
2. Which Symfony version are we actually on, and does our PHP floor satisfy the bundle's constraint (Symfony 7 requires PHP 8.2+)? Confirm Composer resolves cleanly before the spike.
3. Who owns the Rokka account, contract, and API credentials — us or the vendor?
4. What is the projected monthly cost at our image volume (storage, processing, egress, requests)?
5. Do we need Rokka-specific capabilities (stacks, dynamic metadata, on-the-fly operations), or do we only need resize/format conversion that a cheaper or self-hosted option covers?
6. What is our exit path if Rokka changes pricing or discontinues service?

Integration Approach

Stack fit. Symfony 6/7 is the first-class fit; Symfony 5 remains supported but is out of security support and should not be a target for new work. Given 1.4.1, we can adopt on Symfony 7 without caveats. For Laravel, treat this repo as reference documentation for how to wire the SDK — read the service definitions, then reimplement them idiomatically in a service provider. Do not attempt to shim Symfony's DI into Laravel.

Migration path.

• If we already call Rokka over raw HTTP/cURL, moving to rokka/client (plus this bundle on Symfony) removes boilerplate around signing, URL generation, and stack management.
• If we are choosing Rokka fresh, put it behind an internal ImageService interface from day one so the vendor is swappable.
• If we adopt this bundle and later move frameworks, the bundle is discarded and the SDK usage survives — that asymmetry argues for keeping all Rokka logic in our own adapter layer.

Compatibility. 1.4.1 resolves the two checks that previously gated us: Symfony 7 installability and PHP 8.3 testing. Remaining pre-commit verification: the bundle's exact PHP floor versus our runtime, PSR-18/PSR-17 HTTP client support, and interaction with Symfony's cache and HTTP client contracts. Note that "tested on PHP 8.3" is a CI signal, not a guarantee for 8.4+; if we run a newer PHP, validate locally.

Sequencing.

1. Spike: call rokka/client from a throwaway script; confirm auth, upload, and URL generation work. Run it on our target Symfony/PHP pair so 1.4.1's constraints are exercised in our environment, not just CI.
2. Commercial check: pricing at our volume, plan limits, SLA, data residency (Rokka is Swiss-hosted — confirm that is acceptable or advantageous).
3. Define an internal image-service abstraction with a no-op/local fallback.
4. Wire configuration and secrets through the platform's secret store, not committed config.
5. Implement caching and URL helper conventions; align with frontend/design on transform presets.
6. Roll out behind a feature flag with a subset of assets; measure cache hit rate and latency.
7. Document the exit path and the vendor-neutral interface before scaling traffic.

Pin the dependency at ^1.4.1 (not an open constraint) so we get the Symfony 7 support deterministically.

Operational Impact

Maintenance. Low code churn expected — the wrapper is small and stable. 1.4.1 is a positive maintenance signal: the maintainer is still active and does track framework majors, which lowers (but does not eliminate) the abandonment concern. The bus factor is still low and the community is still invisible. Pin the version, watch the repo for releases, and budget a named internal owner. Our own adapter layer, not this bundle, should be the thing we maintain.

Support. Two channels: Rokka's commercial support (tied to our contract) and GitHub issues on a repo with 8 stars, where answers may be slow or absent. No dependents means no Stack Overflow trail and no peer implementations to copy. Assume self-sufficiency. The fact that 1.4.1 shipped suggests issues do get addressed, but with no published SLA.

Scaling. Image processing, resizing, and delivery shift to the CDN, which is genuinely good for us: it removes CPU and egress load from our origin servers and makes responsive-image variants cheap. URL generation is local and effectively free. The scaling constraints move to Rokka's plan tiers, request quotas, and per-operation pricing — capacity planning becomes a finance conversation as much as an engineering one. Cache hit ratio is the metric to instrument. Nothing in 1.4.1 changes the scaling profile.

Failure modes.

• Upstream CDN/API outage: images fail to render. Mitigate by retaining originals and serving a fallback path; do not make originals unretrievable.
• Credential expiry or rotation: silent 401s across all image URLs. Put key rotation in the runbook and monitor error rates on the image path specifically.
• Cache invalidation mistakes: stale imagery after content updates — an especially visible class of bug for marketing-facing assets.
• Stack/config drift: transforms defined in config diverge from what templates request; version the preset definitions.
• Vendor pricing change or discontinuation: the highest-impact scenario. The abstraction layer and retained originals are the only real mitigations.
• Framework major upgrade: the bundle has now demonstrated it follows Symfony majors, so this is a schedule risk (waiting for a compatible release) rather than a blocking risk. Our adapter layer insulates us either way.
• Dependency constraint surprise: a future patch re-tightening the Symfony or PHP constraint could break our build on an unrelated composer update. Commit the lockfile and let dependency bumps be reviewed changes.

Ramp-up. A Symfony developer is productive in hours — the config schema is the whole learning curve. On Laravel, plan a few days for the service provider, config, and tests. Separately, budget onboarding for product, design, and content teams on Rokka's stack/transform semantics and the asset workflow, since URL conventions become a shared contract across teams rather than an implementation detail.