Product Decisions This Supports
- Engagement-feature scoping. It gives a single answer to "how do we ship save/bookmark, like, follow, and recently-viewed?" — one polymorphic
favorites table plus a trait on any Eloquent model. That supports a decision to treat these as one reusable engagement primitive rather than four separate feature tickets.
- Roadmap sequencing. Because the primitives are cheap to stand up, the PM question shifts from "can we build it?" to "is engagement worth a phase-1 slot at all?" Useful for staking out a thin social-proof layer (like counts on cards, save-for-later, follow for an activity feed) as a fast follow rather than a differentiator.
- Build vs. buy. This is commodity CRUD — roughly 1–3 engineer-days in-house (migration, trait, toggle endpoints, uniqueness constraints, counters). The package is a buy only if the team wants a pre-agreed schema and method naming (
favorite(), toggleFavorite(), isFavorited()) to avoid design bikeshedding.
- Data-model and analytics decisions. Adopting it commits you to a polymorphic
favoritable_type / favoritable_id schema. That's fine for UI toggles, awkward for warehouse joins and per-type reporting — worth deciding up front whether engagement data feeds dashboards.
- Counter strategy. The package's count helpers read live; at scale you'll need denormalized counters or caching. That's an infrastructure decision, not a package feature.
- Follow graph as a platform bet. Follow is the one primitive here with downstream leverage (feeds, notifications, recommendations). If follow is on the roadmap, decide now whether it lives in this table or in a dedicated graph model.
When to Consider This Package
Consider it when:
- You're prototyping or in early-stage build and need all four primitives quickly with consistent semantics.
- You want a reference implementation of the polymorphic pivot pattern to copy — arguably its best use today.
- Your stack is Laravel 5.x/6.x era, or you're prepared to fork and verify on modern Laravel/PHP.
- You deliberately want a small, MIT-licensed, readable dependency rather than an internal abstraction.
Look elsewhere when:
- You're on Laravel 9+/PHP 8.1+. Last release was October 2019 — no maintenance for roughly six years, no CI signal on current framework versions. You will own the code.
- You only need one primitive. A ~100-line in-house trait plus migration is cheaper than adopting and maintaining a dependency.
- Scale or query complexity matters. No first-class counter caching, no batch/eager-load helpers; high-traffic feed and card rendering will need custom work.
- You need auditability, moderation, or rate limiting. There's no event history, no per-type constraints, no abuse controls.
- Procurement or security review flags abandoned dependencies — expect friction, and budget for a fork or replacement.
Maintained alternatives in the same space (e.g., cybercog/laravel-love) or an in-house build are the realistic comparison set.
How to Pitch It (Stakeholders)
To executives: Favoriting, liking, and following are commodity table-stakes features, not differentiators. This package would save us perhaps one to two engineer-days on schema and boilerplate — real but small. The material risk is that the library has been frozen since 2019, so adopting it means we own it indefinitely. My recommendation: treat it as a design reference and build the roughly 150 lines ourselves, or fork it deliberately if we need it this quarter. Either way, it should not be on the critical path for a roadmap commitment.
To engineering: It's a trait-based polymorphic favorites/likes/follows/remembers implementation with a small, readable surface. If we adopt, expect to pin it, verify against our Laravel and PHP versions, add a unique index on (user_id, favoritable_type, favoritable_id), and plan for counter caching and N+1 avoidance ourselves. If we build, we copy the schema and method naming and skip the dependency lifecycle risk — my preference unless someone is already running it in production.