Pusher Chatkit Server Laravel Package

Technical Evaluation

Architecture fit

pusher/pusher-chatkit-server is a thin server-side REST wrapper around Pusher Chatkit's hosted API — it is not a chat implementation, not a persistence layer, and not a Laravel package. It ships no service provider, no facade, no publishable config, and no queue/event integration, so it does not align with how Laravel applications expect to consume third-party services (container bindings, config/*.php, Http client or Guzzle via the container). Adopting it means hand-rolling all glue code in a custom service provider, which is the easy part; the hard part is that the package has no functionality without the upstream Chatkit service.

The decisive technical fact is that this SDK targets a decommissioned product. Pusher publicly deprecated Chatkit and has since shut the service down; the repository is archived with no maintainer, and it has 0 dependents on Packagist — a strong signal that no one has shipped it to production in a way that surfaces in dependency graphs. An SDK for a dead API is not an integration risk, it is a non-starter: every call path terminates in a 404, DNS failure, or authentication error.

Integration feasibility

• Composer install: trivial (composer require pusher/pusher-chatkit-server), but it will pin older Guzzle/PSR-7 constraints that fight with a modern Laravel 10/11 lockfile — expect dependency resolution conflicts or forced downgrades of shared HTTP packages.
• Runtime viability: none, absent a live Chatkit endpoint. Any prototype would have to be mocked end-to-end, which produces a demo that proves nothing about production behaviour.
• Auth model: Chatkit used its own instance-locator + key pair and issued per-user tokens; there is no OAuth/SSO story and no alignment with Laravel's Sanctum/Passport or existing user tables beyond a manual ID mapping.

Technical risk (rated: critical / blocking)

Key questions to resolve before any decision

1. Is there a specific requirement behind this evaluation (e.g., a legacy system still pointed at Chatkit), or is this a greenfield "add chat" brief where Chatkit surfaced as a search result?
2. Do we already have production data in Chatkit that must be exported before we can consider any path forward?
3. What is the actual product requirement — 1:1 messaging, group channels, presence, typing indicators, read receipts, moderation, attachments, push notifications? That list is what should drive vendor selection, not this package.
4. Who owns the equivalent capability today (Pusher Channels + custom, Laravel Reverb, Stream, Sendbird, Ably, Matrix)? Is there an existing enterprise agreement we can lean on?

Recommendation: do not adopt. Treat this as a replacement evaluation, not an integration evaluation.

Integration Approach

Stack fit

Poor, and not fixable by wrapper work. Chatkit's hosted model also conflicts with common Laravel architecture preferences: chat history and message content live in Pusher's cloud, not in our database, which breaks our ability to join chat data to our own reporting, moderation, and GDPR/DSAR deletion workflows. For a Laravel shop, the natural fits are:

• Laravel Reverb + Laravel Echo (first-party, self-hosted WebSockets) — no vendor, full data ownership, but we build message persistence, presence, and moderation ourselves.
• Pusher Channels (the surviving Pusher product) — keeps the realtime transport with an official, maintained Laravel broadcasting driver; we own persistence in MySQL/Postgres.
• Managed chat-as-a-service (Stream Chat, Sendbird, Ably) — fastest to feature-complete, but repeats the same data-residency/lock-in trade-off that Chatkit just imposed on us.

Migration path

If legacy code already depends on this package, the migration is an exit, sequenced as:

1. Inventory all call sites: token issuance, user creation/sync, room creation, message send/history, webhook handlers. The SDK surface is small, which keeps this bounded.
2. Extract behind an interface — define an internal ChatService contract (createUser, issueToken, sendMessage, listMessages, createRoom) and wrap the existing SDK calls behind it. This is the single highest-leverage step: it isolates the dead dependency to one adapter class and makes the eventual swap a one-file change.
3. Freeze and export — pull whatever message/user data still matters out of Chatkit while any export path or vendor contact remains available; assume this window is closed or closing.
4. Re-point the adapter to the chosen replacement, then delete the package and its pinned Guzzle constraints from composer.json.
5. Verify auth — replace Chatkit token issuance with Sanctum/Passport-issued tokens or the replacement vendor's token endpoint, and confirm the client-side (JS) library is swapped in the same release; server and client SDKs must move together.

Compatibility

Assume PHP 7.x-era constraints. Do not attempt to run this on PHP 8.2+/Laravel 11 without auditing the transitive tree; a security review of the lockfile diff is mandatory if it stays in the build for any period. Pin it, isolate it, and set a hard removal date.

Sequencing

Run the interface extraction and the vendor decision in parallel; they are independent. Do not sequence the vendor selection behind the abstraction work — the abstraction is the safety net, not a prerequisite for choosing.

Operational Impact

Maintenance

Effectively unmaintainable. Archived upstream plus zero dependents means every future PHP upgrade, Guzzle CVE, or Laravel major becomes our problem to patch in a fork we did not write. The realistic steady-state cost is not "low, it's just an SDK" — it is an unplanned fork-and-own project, plus a standing security exception on the dependency scanner.

Support

None. No vendor support (product discontinued), no maintainer triage, no issue response. Internal escalation path terminates immediately. If a message-routing bug appears in production, there is no one to call and no upstream fix to wait for — the only remedy is our own code.

Scaling

Moot for the package itself (it is a stateless HTTP client, so it never was the bottleneck). The scaling question belongs to the replacement: self-hosted Reverb pushes connection-count and horizontal-scaling decisions onto our infra team (sticky sessions, Redis pub/sub, presence state); a managed vendor pushes it onto a contract and a per-MAU bill. Flag the cost curve explicitly — chat pricing is usually per monthly active user, and it is the line item most likely to surprise finance at 10x growth.

Failure modes

Dominant failure mode is total, not partial: not "degraded chat" but "chat does not exist," surfacing as hard failures on token issuance and message send. Secondary modes worth designing for in the replacement: WebSocket reconnect storms after a deploy, presence state going stale on ungraceful disconnect, message ordering across multiple app servers, and webhook delivery gaps causing our DB and the vendor's state to diverge. Mitigations to bake in from day one: idempotency keys on message send, a durable outbox for webhook-driven writes, and a health check that distinguishes "realtime down" from "chat down."

Ramp-up

Learning cost for this package is near zero and near-worthless — it is a few hundred lines of HTTP calls. The real ramp-up is on the replacement: roughly 1–2 sprints for a competent Laravel team to stand up an interface-backed chat service with persistence, presence, and moderation, plus client-side work in the same window. Budget the interface extraction as a half-sprint line item and treat it as the risk-reduction deliverable that makes the vendor choice reversible.

Bottom line for the roadmap: close this evaluation as "rejected — upstream product end-of-life." Re-open as a build-vs-buy decision on chat (Reverb vs. Channels vs. managed vendor) driven by the actual feature list, data-residency requirements, and the per-MAU cost curve.