Php Centrifugo Laravel Package

Technical Evaluation

Architecture fit. The package is a thin outbound HTTP adapter, which is the right shape: real-time fan-out belongs in Centrifugo, not in the Laravel process. It occupies a single seam in a Laravel app — an egress client called from controllers, jobs, and console commands — and its "composable client / DI-friendly" design lets you hide it behind your own RealtimeBroadcaster interface so domain code never imports vendor classes. That is the only defensible way to adopt a package this old: treat it as an implementation detail behind a boundary you own.

Integration feasibility. Composer-installable and framework-agnostic, so no Laravel service provider, config publishing, or facade is provided — you write the binding, config, and singleton registration yourself (roughly an hour of work). The real feasibility question is dependency compatibility, not code: a 2018 release will likely pin Guzzle 6 and a PHP ^7.0/^7.1 constraint, which collides with Laravel 9+ (Guzzle 7) and PHP 8.1+. Verify with composer why-not before estimating anything. A --ignore-platform-reqs install is a smell, not a fix.

Technical risk. High, concentrated in API drift rather than code quality.

• Protocol version: a 2018 client almost certainly targets Centrifugo's legacy /api endpoint and its v2-era auth header. Centrifugo has since reworked the HTTP API (/api/publish, API-key headers, revised response envelope) and dropped the legacy endpoint in recent majors. The failure mode is silent 404/401 at runtime, not a compile error.
• Abandonment: no upstream releases since April 2018, no security response, no PHP 8 or Guzzle 7 support. You inherit the maintenance.
• Scope gap: this library only publishes. Connection auth, JWT subscription tokens, presence, and history are Centrifugo server config — teams routinely assume the client handles them and are surprised.
• Low bus factor: one maintainer, 38 stars, negligible community signal; no ecosystem pressure to keep it current.

Key questions.

1. Which Centrifugo major version is deployed, and does it still expose the endpoint this client calls?
2. Does composer.json constrain PHP and Guzzle in a way that blocks our target Laravel/PHP version?
3. Is real-time a product differentiator (justifying ownership of a fork) or a nice-to-have (justifying a 100-line internal client instead)?
4. Who owns this code when the upstream is dead — a named engineer, not a team?
5. Do we need delivery guarantees (retry, idempotency, ordering) beyond fire-and-forget publish?

Integration Approach

Stack fit. Good conceptually, poor in packaging. Laravel's queue workers and HTTP kernel are already the right call sites; publishing to Centrifugo from a job is a two-line operation. What is missing is everything Laravel teams expect: config file, env-backed credentials, facade, health check. Plan to supply all of it in a thin app/Realtime wrapper.

Migration path. Do not adopt the package directly into domain code. Sequence: (1) define a narrow internal interface — publish(string $channel, array $payload): void and a batch variant; (2) implement a CentrifugoBroadcaster adapter around this library; (3) if the dependency audit fails, swap the adapter for centrifugal/phpcent (the vendor-maintained client) or a hand-rolled Guzzle call — the interface makes either swap a single-file change. Given the client is small, forking it in-house or replacing it outright is often cheaper than fighting its constraints. Budget the fork as the default, not the fallback.

Compatibility. Pin the Centrifugo server version alongside the PHP dependency, and record both in the ADR. Lock the package version exactly. Add a contract test that hits a dockerized Centrifugo instance in CI — that is the only thing that will catch protocol drift, since the PHP code will happily send a payload the server now rejects.

Sequencing.

1. Dependency spike: composer require against the real app skeleton, on the real PHP version. Kill the initiative here if it fails; do not patch around it.
2. Stand up Centrifugo in Docker; confirm endpoint, auth scheme, and response shape by hand.
3. Build the interface + adapter + config + DI binding, with one happy-path and one failure-path test.
4. Wire a single low-risk producer (e.g., a notification) behind a feature flag.
5. Expand producers once the failure semantics are proven in staging.

Operational Impact

Maintenance. The package is frozen; every future PHP, Guzzle, or Centrifugo upgrade is your problem. Assign a named owner and schedule a quarterly compatibility review. Realistically, plan to fork to a private VCS or vendor the ~10 relevant classes — at this size the fork is a day of work and removes the supply-chain ambiguity entirely.

Support. No upstream support, no issue triage, no CVE path. Internal support means whoever wrote the adapter, plus runbooks for the Centrifugo server itself, which is the harder operational surface (separate process, Redis engine, presence/history retention). Staff the server side, not just the client.

Scaling. The PHP client is stateless and cheap: each publish is one HTTP round trip, well-suited to queue workers, and batch publishing keeps request counts low during fan-out bursts. The scaling ceiling is Centrifugo and its Redis engine, not this library. Watch connection counts on the Centrifugo node and HTTP timeout settings on the PHP side — a slow Centrifugo will otherwise back up queue workers.

Failure modes.

• Centrifugo unavailable → publish throws; decide explicitly whether that fails the job (retry) or degrades silently (log and drop). For notifications, drop; for chat, retry with an idempotency key or you will duplicate messages on redelivery.
• Protocol drift after a Centrifugo upgrade → 4xx at runtime, invisible until a user notices missing updates. The CI contract test is the mitigation.
• Auth expiry/misconfiguration → same silent-4xx class; add a startup health check that publishes to a canary channel.
• Timeout retries amplifying load → set conservative Guzzle timeouts and cap retries; batch publishes to reduce blast radius.

Ramp-up. Low for the client itself — the API surface is a few methods and a competent Laravel engineer is productive in under an hour. The real ramp is Centrifugo operations and the real-time UX contract (what "live" means when a publish is dropped), which is a multi-day learning curve for whoever carries the pager. Budget for that, not for the wrapper.