Product Decisions This Supports
- Build vs. buy for social/interaction features.
eloquent-interactions provides a generic, reusable Eloquent relationship for "model A interacts with model B" patterns (likes, favorites, bookmarks, follows, upvotes, subscriptions). The PM decision it most directly informs is whether to hand-roll a bespoke polymorphic pivot table + trait + query scope for each new interaction, or standardize on one package. The former is ~1–2 days of engineering plus ongoing duplication each time; the latter is a single dependency and one consistent schema.
- Feature scoping and time-to-market. Because interactions become a configuration exercise rather than a schema migration project, this lowers the marginal cost of interaction-flavored features in a roadmap. That changes prioritization: "let users save articles," "add reactions to comments," and "let users follow creators" stop being three separate epics and become one thin feature layer.
- Roadmap sequencing against framework upgrades. The headline of v1.0.0 is Laravel 7–10 compatibility. If the platform roadmap includes a Laravel 9 → 10 upgrade, this release removes a blocker and puts the package on the "safe to carry forward" list rather than the "must replace before upgrading" list.
- Dependency posture / stability commitment. The 0.x → 1.0.0 bump is a semver commitment: the public API is considered stable and breaking changes now require a major version. That is the signal a PM needs to green-light depending on it in production code rather than treating it as an experiment.
- Buy vs. build on adjacent capability. This package is a relationship primitive, not a feature. It does not decide feeds, ranking, counters, or moderation. That distinction is useful when scoping: adopt it as infrastructure, and budget separately for the product surface built on top.
When to Consider This Package
Adopt when:
- You need standard, symmetric interaction types (like/favorite/bookmark/follow) across multiple models and want one polymorphic schema rather than N pivot tables.
- You are on Laravel 7, 8, 9, or 10 and want a dependency with an explicit, tested support matrix for that range.
- You value semver stability and want a 1.x contract rather than tracking a 0.x package's churn.
- The interaction data is product-facing but not analytically central — you need "did this user like this post," not a full event-sourced interaction history.
- You want the option to fork or replace cheaply: the package is thin, sits on plain Eloquent relationships, and its data lives in ordinary pivot tables, so the exit cost is low.
Look elsewhere (or build in-house) when:
- You are on Laravel 11 or later — this release's tested range stops at 10, so verify compatibility or plan a fork before committing.
- You need high-volume counters, ranked feeds, or weighted reactions. Aggregate counts and ordering should be a deliberate denormalization/caching decision, not an implicit
COUNT(*) on a polymorphic pivot.
- You need audit trails, moderation state, or per-interaction metadata (timestamps with reason, soft deletes, review status) beyond a simple presence relationship — that argues for a first-class domain model.
- You need fine-grained authorization semantics (who may interact with what, quotas, rate limits) — that belongs in your policy layer, not the package.
- Maintainer concentration is a concern. This is a small, single-maintainer package. Because the surface area is small this is a manageable risk, but it should be an explicit accepted risk rather than an unnoticed one.
- The interaction is core-domain and likely to diverge from a generic shape within a quarter. Generic primitives become leaky abstractions when the domain gets specific.
How to Pitch It (Stakeholders)
To executives: We're standardizing a small, dependency-light library for user interaction features — likes, favorites, follows, bookmarks — instead of rebuilding that plumbing for every feature. Version 1.0.0 marks it as API-stable and confirms it runs on the Laravel versions we use today, which also clears one item from our upcoming framework upgrade. Cost is near zero; the payoff is turning several would-be epics into one shared building block, and the exit cost is low because the data stays in ordinary database tables we control.
To engineering: zachflower/eloquent-interactions v1.0.0 gives us a polymorphic many-to-many interaction relationship out of the box, so we stop writing a new pivot table, trait, and query scope per interaction type. The 1.0.0 tag means semver stability — breaking changes now require a major — and the support matrix is Laravel 7–10. Two caveats to note: it is not tested against Laravel 11, so if our upgrade path goes past 10 we should validate or fork; and it is a thin single-maintainer package, so we should pin the major, keep the integration behind our own trait/interface boundary, and treat it as replaceable. It is a relationship primitive only — counting, ranking, feeds, and moderation remain our responsibility and should be designed explicitly rather than inferred from this package.