Phpcent Laravel Package

Product Decisions This Supports

• Real-time roadmap sequencing. phpcent makes server-initiated push a small, well-bounded backend task: publish and broadcast are single calls, and presence, history, channel enumeration, and batch operations are exposed as ordinary methods. That lets you sequence live notifications, activity feeds, presence indicators, live dashboards, and in-app alerts by user value rather than by infrastructure risk.
• Build vs. buy, at two levels. First: buy/operate Centrifugo instead of building a WebSocket server. Second: adopt the vendor’s PHP client instead of hand-rolling a cURL/Guzzle wrapper. The second decision is minor — the library is thin — but it keeps the integration aligned with Centrifugo’s HTTP API and release cadence.
• Scope correction for estimates. phpcent is server-to-server only. It publishes messages and mints JWTs; it does not open browser connections, manage reconnects, or replace a frontend client. Any roadmap estimate that treats this package as “the real-time layer” is missing a frontend workstream: Centrifugo’s JS client plus a Laravel token endpoint.
• Channel access model as a product decision. Connection tokens and subscription tokens — with optional TTLs — let you choose between public channels (fast to ship) and private, per-user channels (safer to ship). Decide before launch; retrofitting authorization onto public channels is a client-breaking change.
• Managed vs. self-hosted real-time. This package presupposes that you run Centrifugo. If operating another stateful service is unacceptable, that is a vote for Pusher, Ably, or Firebase — and against this package. The PM decision is not “phpcent or not”; it is “Centrifugo or managed provider.”
• Use-case fit. Strong fits: Laravel queued jobs or domain events publishing status changes; live notifications and badges; presence (“who’s online”); activity feeds; live operational dashboards; chat or collaboration indicators where the hard real-time work is delegated to Centrifugo. Weak fits: a single badge counter that polling already handles, or products where real-time is the core differentiator and latency/transport control must be validated against managed providers first.
• Maintenance as a roadmap line item. phpcent 6 targets Centrifugo 5; phpcent 5.x targets Centrifugo 4. The server HTTP wire format changed across majors. Treat Centrifugo as an infrastructure dependency with a recurring upgrade task, not a one-time install.
• Vendor-official but low-footprint dependency. MIT licensed, maintained by the Centrifugo team, with a modest star count and no listed dependents. That is acceptable for a thin, replaceable client, but it will not satisfy a procurement bar that requires broad adoption. The stronger signal is that it is the vendor’s own client.

When to Consider This Package

Adopt when:

• Your backend is PHP/Laravel and you already run — or have decided to run — Centrifugo. This is the official client, released in step with the server.
• Your needs are server-initiated push plus token minting: a Laravel job, listener, or controller publishes an event, and a token endpoint issues connection or subscription JWTs.
• You want the smallest integration surface: a few HTTP calls inside existing Laravel services, queues, events, and CI — no new protocol or backend language.
• You need presence, presence stats, history, channel enumeration, batch publish, subscribe/unsubscribe, or forced disconnect. Each is a one-liner here and fiddly to reproduce by hand.
• You want real-time work to remain with the existing PHP team rather than creating a new platform owner.

Look elsewhere when:

• You want a fully managed real-time service with no servers to operate. Pusher, Ably, or Firebase remove the Centrifugo deployment but require a different client.
• Your backend is not PHP. Centrifugo ships official clients for Go, Python, JS, Ruby, and others; use the native one.
• Someone assumes phpcent handles browser connections. It does not, and the frontend work does not shrink because of it.
• You need sub-50ms tuning, custom protocols, or transport-level control. That is Centrifugo configuration or a different product, not this library.
• Real-time matters in exactly one narrow place and polling is good enough. Adding a stateful service for a single counter is a net loss.
• Procurement requires a broad dependents base or multiple maintainers. This is a small, vendor-maintained library; official status helps, but it will not clear a strict “widely adopted” bar.
• Your team cannot own another stateful service, its upgrades, and its operational runbooks.

How to Pitch It (Stakeholders)

Executives: “We can add live notifications, presence, and live dashboards without building or operating a custom WebSocket server. This is the official PHP client from the team behind Centrifugo — MIT licensed, no lock-in, version-matched to the server. Engineering cost is days, not months; ongoing cost is one small service we run next to the Laravel app. The trade-off is explicit: we either take on that service and its upgrades, or we pay a managed provider instead. I need a decision on which, because it determines the whole real-time line on the roadmap.”

Engineering: “Thin, boring, and correct — the right kind of dependency. Install with composer require centrifugal/phpcent:~6.0, bind phpcent\Client as a singleton in a Laravel service provider using config from environment/secret storage, and wrap it in one small CentrifugoService so transport stays swappable. You get publish/broadcast, subscribe/unsubscribe/disconnect, presence/presenceStats/history/channels/info/batch, and connection/subscription JWT generation with optional TTLs. It uses cURL underneath with configurable connect/request timeouts, SSL and custom-cert options, and setUseAssoc(true) for array responses. Two caveats: (1) it is server-to-server HTTP only — the browser still needs centrifuge-js and a Laravel token endpoint, so resource both sides; (2) match majors to the server (phpcent 6 ↔ Centrifugo 5) and upgrade them together, since the wire format changed between server majors. Keep the API key and JWT secret in the secret store, not config files, and log publish failures — silent drops are the main failure mode we would have to debug.”

Product managers: “Pick the two or three places where live updates actually change user behavior — notifications, presence, a live dashboard — and scope the frontend token flow and JS client at the same time as the backend publish calls. Decide public vs. private channels before launch; subscription tokens with TTLs are the safe default for anything user-specific. Budget a small recurring maintenance line for Centrifugo upgrades, and do not promise browser behavior from this package alone. If operating Centrifugo is not acceptable, stop here and evaluate a managed provider; phpcent is the cheap part, and the real decision is where the real-time service runs.”