Bunnynet Php Laravel Package

Technical Evaluation

Architecture fit. toshy/bunnynet-php is a framework-agnostic SDK wrapping Bunny.net's REST API (pull zones, storage zones, purge, DNS, statistics). It is infrastructure plumbing, not domain logic, so it should sit behind our own port — e.g. a CdnPurgeService or EdgeStorageGateway interface — with the package as one adapter implementation. That boundary is what makes the "60-star community package" risk tolerable: the vendor SDK never appears in controllers, models, or jobs directly.

Integration feasibility. Composer-installable, PSR-18/17/7-oriented, and it builds on Guzzle, which Laravel already ships. There is no first-party Laravel service provider, so we write ~40 lines of our own: a config file, an env-backed credential binding, and a container singleton. A working proof of concept (purge a URL on model save) is realistically 1–2 engineer-days including review.

Technical risk. Moderate-to-high as a raw dependency, low if isolated:

• Single-maintainer community project with a small contributor base and no vendor SLA.
• Broad API surface means partial coverage — some Bunny endpoints will be missing and we'll need the raw-request escape hatch.
• Version bumps can be breaking when Bunny changes its API; release cadence is reactive.
• Repository provenance is unverified in the package metadata — we must confirm the actual source, commit history, CI, and release signing before adoption.
• MIT license is clean for commercial use.

Key questions.

1. Who maintains the repo, and what is the bus factor? Is there a second committer?
2. Does it cover the exact endpoints we need — purge by URL/tag, storage upload, signed URLs, statistics — or only a subset?
3. What is the supported PHP/Laravel matrix, and does it constrain our runtime upgrade path?
4. What is the error model — typed exceptions and DTOs, or raw PSR-7 responses we must parse ourselves?
5. Does it expose a raw-request escape hatch for unwrapped endpoints?
6. How does PSR-18 client discovery interact with our configured Guzzle handler stack (middleware, retries, proxies, timeouts)?
7. What is the test/CI posture upstream, and has anyone audited a release?

Integration Approach

Stack fit. PHP 8.1+ with a PSR-18 dependency; compatible with Laravel 10–12 via a hand-written provider. Guzzle satisfies the HTTP client requirement without introducing a second HTTP stack alongside Http facade usage and Flysystem. No framework coupling, no service-provider conflicts, no config-publishing assumptions to fight.

Migration path. Adopt incrementally and reversibly:

1. Introduce the package only for cache purge on content publish, behind a CachePurger interface with a null implementation for local/test environments.
2. Once that is stable, expand to storage offload (paired with the Bunny Flysystem adapter, which is a separate package — do not conflate the two).
3. Only then consider pull-zone or DNS management, which are higher-blast-radius operations.

If the package is abandoned, we swap the adapter for direct REST calls without touching call sites. That optionality is the whole point of the interface boundary.

Compatibility checks. Confirm the PHP constraint against our runtime, verify the package pulls no unexpected transitive dependencies, and confirm our Guzzle middleware (retry, logging, correlation IDs) applies to SDK calls. Credentials must come from the secret manager, never from a committed config default.

Sequencing.

• Dependency review, license/security scan, provenance verification, and a written accept/reject note.
• Spike: provider binding + one purge call in staging.
• Hardened path: queue-backed purge job on publish/unpublish events, with retries and metrics.
• Staged rollout with cache-hit-ratio and purge-success dashboards.
• Expand scope only after the purge use case clears agreed thresholds.

Operational Impact

Maintenance. We own the wrapper, so we own the maintenance. Pin to an exact version and commit the lockfile; review upstream releases quarterly; document the fork-and-patch procedure before an incident rather than during one. Budget a small standing allocation for adapter upkeep — this is the recurring cost of the low initial integration effort.

Support. No vendor SLA. Support is GitHub issues and community goodwill. Internal ownership must be explicit (platform team), with a pre-agreed escalation: if a bug blocks a release, we bypass the SDK and call the API directly behind the same interface.

Scaling. The library is a thin HTTP client, so scaling is bounded by Bunny's API, not by the package. Real constraints are purge throughput and rate limits. Batch purges, prefer tag or wildcard purge over per-URL storms, and never call purges synchronously on a user request path — everything goes through queued jobs with backoff and idempotency.

Failure modes.

• Silent purge failure → stale content at the edge. Highest-impact and hardest to detect; instrument purge success explicitly and alert on divergence.
• Credential expiry or scope misconfiguration → 401s buried in failed jobs, surfacing as stale content days later.
• API latency/timeouts → queue backlog cascading into publish delays.
• Unhandled error shapes from unwrapped endpoints → 500s inside jobs.
• Dependency abandonment → exposure to breaking Bunny API changes at an arbitrary future date.
• Cache-key/purge-target mismatch → purges that succeed but don't invalidate what you intended.

Ramp-up. Low. Endpoint-per-method design and typed response objects make the library legible in an afternoon; expect ~1 engineer-day to a first production call and roughly one sprint to a hardened, observable pipeline. The real learning curve is Bunny's own concepts — pull zones, edge rules, cache keys, purge semantics — not the PHP code. Plan onboarding around the CDN model, and treat the package as the easy part.