Stream Laravel Package

Product Decisions This Supports

• Build vs. buy for feed infrastructure. Stream (getstream.io) is a hosted activity-feed / news-feed backend; this package is the PHP SDK that wires a Laravel or PHP app into its Feeds v2 API. Evaluating it forces the explicit decision: pay for a managed feed service versus building fan-out, ranking, aggregation, and real-time delivery in-house.
• Feature scoping for social and notification surfaces. Supports roadmap items like activity timelines, follow graphs, notification inboxes, and "activity stream" UIs — the classic cases where a managed feed backend saves months of engineering.
• Vendor and tech-stack selection. This is one candidate in a feed-backend bake-off (alongside Pusher/Ably-based builds, self-hosted Stream-Framework, or bespoke Redis fan-out). Its deprecation status is itself a decision input.
• Migration and tech-debt planning. For teams already on Feeds v2, this package anchors a "when do we move to Feeds v3 (getstream-php)" roadmap item and a risk register entry.
• Integration effort estimation. A small, single-purpose SDK with a thin surface keeps the "time to first feed" estimate low — useful when sizing a spike or MVP.

When to Consider This Package

Only consider it if:

• You are maintaining an existing Laravel/PHP product already integrated with Stream Feeds v2, and a coordinated migration to getstream-php (Feeds v3) is not yet funded.
• You need a short-lived prototype against an existing Stream account that is already pinned to the v2 API.
• Your team has deliberately accepted the maintenance-mode risk with a dated migration plan attached.

Look elsewhere if:

• You are starting a new project — use the vendor's current SDK (getstream-php, Feeds v3) or another provider outright. Do not onboard a package the maintainer has publicly superseded.
• You need active bug fixes, security patches on the vendor's roadmap, or responsive upstream support.
• You require long-term vendor stability guarantees or a documented LTS window.
• You want a broad, actively maintained ecosystem (large dependent base, frequent releases, community answers) — this package has effectively zero dependents, so you will be debugging alone.
• Your feed needs are simple (e.g., a single chronological list) — a native Eloquent/Redis implementation will be cheaper than any vendor integration.

How to Pitch It (Stakeholders)

To executives: Stream is a managed feed backend that lets us ship social-style timelines and notification inboxes without building fan-out infrastructure. This specific PHP SDK, however, is in maintenance mode and has been superseded by the vendor's Feeds v3 client. My recommendation is not to adopt it for new work; its value to us is as a migration artifact for any legacy integration. The commercial decision — buy vs. build feed infrastructure — remains worth evaluating, but it should be evaluated against the current SDK.

To engineering: Treat get-stream/stream as frozen. It is a thin, BSD-licensed client for the v2 API with no dependent ecosystem, so there is no community safety net. If we have v2 traffic, scope a migration to getstream-php (Feeds v3) with a clear cutover date and an auth/token-refresh test plan; if we don't, exclude it from new repositories and document the exclusion so it doesn't get pulled in by copy-paste from older projects.

Bottom line for the roadmap: a no on adoption, a yes on a time-boxed migration ticket if legacy usage exists, and a maybe on a broader feed-backend evaluation using the vendor's current SDK.