Interactions Laravel Package

Product Decisions This Supports

• Build vs. buy for engagement features: laravel-interaction/interactions provides a polymorphic interaction layer (views, likes, favorites, and custom interaction types) that attaches any model to any actor. This lets us ship engagement mechanics — "liked by", "viewed by", counters, "who viewed my post" — without designing a schema or writing per-feature pivot tables.
• Roadmap sequencing for social/engagement surfaces: because interaction types are configuration-driven rather than hard-coded, the same package backs multiple roadmap items (likes → bookmarks → follows → reactions) instead of a new migration per feature. Useful when engagement is a multi-quarter theme rather than a one-off.
• Scope control on "activity feed" and "recently viewed" style features: these are typically deceptively expensive (polymorphic joins, deduplication, counter caches). A vetted package shortens the estimate and reduces the surface area our team owns.
• Forward-compatibility commitments: the 3.5.0 release adds support for Laravel 13, PHP 8.5, and PHPUnit 12. That makes the package a safe dependency to plan against for the next major framework upgrade cycle — it removes the "we'll be stuck on this library when we move to Laravel 13" objection from the upgrade roadmap.
• Non-decision: this package does not replace analytics/event pipelines. It is application-level relationship bookkeeping, not product telemetry. Do not let it be pitched internally as an analytics solution.

When to Consider This Package

Adopt when:

• We need many-to-many or polymorphic "who interacted with what" relations and want to avoid hand-rolling the pivot tables, indexes, and query scopes.
• We expect more than one interaction type and want them governed by a single, consistent API rather than a growing set of bespoke tables.
• The team is already on a maintained Laravel major (10–13) and wants a dependency that tracks upstream framework releases closely — the 3.5.0 changelog shows active CI against current PHP and Laravel versions.
• The interaction data is first-party and low-to-moderate volume (likes, saves, follows), where Eloquent-level modeling is the right level of abstraction.

Look elsewhere when:

• We need high-throughput counters (millions of views/day) — a denormalized counter store or event stream will outperform per-row Eloquent interactions.
• We need historical/event-sourced audit trails with replay, segmentation, or funnel analysis — that is an analytics warehouse problem, not an Eloquent relation problem.
• We require strict deduplication and idempotency guarantees under concurrency — verify the package's unique-constraint story before committing; otherwise we own that logic anyway.
• We already have an engagement model in production that the package would have to be backfilled into — migration cost likely exceeds the savings.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk open-source component that lets us add "like / save / view" style engagement features without building the underlying data plumbing ourselves. The latest release (3.5.0) is a maintenance release — it adds compatibility with the next Laravel version, PHP 8.5, and PHPUnit 12, with no breaking changes. That means adopting it now does not create a future upgrade liability; it actively reduces one. Estimated effort saved is measured in days-to-weeks per engagement feature, not months.

To engineering: 3.5.0 is purely additive compatibility work: Laravel 13 support, PHP 8.5 support, PHPUnit 12 support, a orchestra/testbench constraint update, and routine CI/dependency bumps. No API changes, no deprecations, no migration required. It sits cleanly within the existing 3.x line, so it is a safe minor-version upgrade. The main engineering caveats to validate before adoption: index and uniqueness strategy for high-volume interactions, and whether counter caching is handled at the application layer (it likely is — plan for it). We should not treat this package as an analytics or audit-log solution; it is a relationship-modeling convenience, and we retain responsibility for throughput, retention, and deduplication semantics.