Stream Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for social primitives. Feeds, timelines, follow graphs, and notification inboxes are recurring roadmap items that are expensive to build well (fan-out, ranking, aggregation, real-time, backfill, moderation). This package is the Laravel-side integration cost for buying that capability from GetStream — it turns a multi-sprint infrastructure project into a configuration-and-Eloquent task. The decision it informs is not "do we use this package" but "do we buy managed feed infrastructure at all."
• Roadmap sequencing for engagement epics. If an activity feed, "following" surface, or notification center is in the next two quarters, this package materially compresses the dependency chain: it lets the team ship a thin slice (one feed group, one follow relationship) and learn before committing to custom infra.
• MVP / experiment validation. For a product hypothesis like "a social feed increases D30 retention," buying is the cheapest way to get a testable surface in front of users. The package's Eloquent integration keeps your domain models as the source of truth and only stores activity references, so a failed experiment leaves your core schema intact.
• Feature scoping. The package's surface (feed groups, flat/aggregated/notification feed types, activity enrichment, follow relationships, real-time tokens) is a ready-made checklist for scoping what "a feed" actually means in your product — chronological vs. ranked, per-user vs. per-entity, inbox vs. timeline. PMs should treat it as a capability menu, not an implementation detail.
• Cost and TCO modeling. Adoption forces an explicit per-MAU/connection cost line into the business case, compared against the fully-loaded cost of an in-house Redis/Postgres fan-out service (engineering months + ongoing on-call). This is the single most valuable artifact the decision produces.
• Architecture and exit-cost decisions. Because the wrapper is thin (service provider, facade, config, Eloquent traits), the real lock-in is the vendor, not the package. That argues for a decision to wrap it behind an internal FeedService interface — a cheap insurance policy that should be part of the adoption decision itself.
• Data ownership and compliance review. Centralizing feed state with a third party is a product-visible decision (data residency, deletion/GDPR flows, tenant isolation). Raising it here, early, prevents a late-stage blocker.

When to Consider This Package

Adopt when:

• You are on Laravel (verify the package's Composer constraints against your Laravel/PHP versions — the last tagged release is March 2023, so Laravel 10/11 and PHP 8.2/8.3 support must be confirmed, not assumed).
• Feed, timeline, or notification-center functionality is on the near-term roadmap, and the backend team is small enough that weeks of infra work is a real opportunity cost.
• The engagement loop is important to the product but not your differentiator — you want standard follow graphs, ranked/aggregated feeds, and real-time updates, not bespoke ML ranking.
• Your projected MAU keeps per-user pricing comfortably below the fully-loaded cost of self-hosting, and the pricing curve has been modeled at 12–24 months, not just launch.
• Storing feed relationships and activity references with a third party is acceptable under your data-residency and privacy posture (confirm region options and deletion semantics).
• You are deliberately buying speed to validate a hypothesis, and you have accepted a defined exit ramp (internal interface + export/backfill plan).

Look elsewhere, or use the vendor's PHP SDK directly, when:

• The wrapper's maintenance signals are unacceptable for a long-lived dependency: ~322 stars, effectively zero downstream dependents in the dataset, and no release since March 2023. The wrapper is thin enough that replicating its service provider, facade, config, and Eloquent glue over getstream/getstream-php is a small, bounded task — budget days, not weeks. Treat "use the official SDK" as the fallback plan, not a reason to abandon the buy decision.
• You need on-premises, air-gapped, or strict per-tenant data isolation the vendor cannot provide.
• Scale makes per-MAU pricing dominate: very high DAU with read-heavy, largely chronological feeds is exactly where an in-house fan-out on Redis/Postgres wins on unit economics.
• Your feed is genuinely trivial — "latest N rows from a table, paginated." Eloquent plus a cursor does this; adding a vendor adds cost and a dependency for no gain.
• Ranking, recommendation, or feed composition is the product differentiator and you need full control of the model and feature pipeline.
• You are not on Laravel, or you are on an unsupported Laravel/PHP combination and cannot absorb an unmaintained wrapper.

How to Pitch It (Stakeholders)

For executives — the decision in one page. We are evaluating managed feed infrastructure (GetStream) with this package as the Laravel adapter. The ask is a short, time-boxed spike plus a pricing review, not a commitment. Rationale: activity feeds and notification centers are consistently among the most requested engagement features, they are expensive to build correctly (fan-out, ranking, real-time, backfill), and they are not where our product differentiates. Buying converts a multi-sprint infrastructure build into a configuration task, and moves the cost from engineering headcount to a predictable per-user line item. The risk is vendor dependency and long-term unit economics; we mitigate it by wrapping the integration behind our own interface, confirming data-residency and deletion behavior up front, modeling cost at 12–24 months of projected MAU, and piloting on a single surface before broad rollout. Recommendation: approve the spike, with a documented exit path as a condition of adoption.

For engineering — what it actually costs us. The package is a thin, idiomatic Laravel wrapper: service provider, facade, config file, and Eloquent integration that keeps our models as the system of record and stores only activity references with the vendor. Integration effort is measured in days; the real work is product-side — follow graph modeling, ranking rules, moderation, and backfill. Two caveats to plan around: (1) the last release is March 2023 with a small ecosystem, so pin the version, verify Laravel/PHP compatibility in a branch before committing, and be prepared to drop to getstream/getstream-php directly — the wrapper is a small amount of glue; (2) do not let the facade leak into domain code. Put it behind an internal FeedService interface so switching to the raw SDK or to self-hosted fan-out is a contained change rather than a rewrite.