Laravel Follow Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin Eloquent concern: two traits (CanFollow on the actor, Followable on the target) plus a single polymorphic pivot table (followers with follower_id/type and followable_id/type). It sits directly in the application's persistence layer with no service, queue, or external dependency.
• Because it is polymorphic on both sides, it models a heterogeneous follow graph (User→User, User→Tag, User→Team), which is more flexible than a user-to-user-only design. That makes it a good fit for social features, subscription-to-entity, or "watch" semantics without a bespoke schema.
• Scope boundary to set expectations: this is a relationship store, not a feed engine. It provides no activity stream, fan-out, notifications, ranking, or block/mute semantics — those remain product-owned.

Integration feasibility

• composer require hypefactors/laravel-follow, publish config + migration, migrate, add the traits. Integration surface is small and reversible; a credible spike is 1–2 engineer-days including authorization wiring and API exposure.
• Works with standard Eloquent query patterns (followers(), followings(), isFollowing(), count helpers), so it composes with policies/gates and API resources rather than fighting them.

Technical risk

• Maintenance signal is the dominant risk: ~49 stars and a last release of 2023-07-22 means no evidence of Laravel 11/12 or PHP 8.3+ support. Treat it as "adopt-and-own," not "adopt-and-forget."
• Correctness risks common to this pattern: duplicate follows without a unique composite index, check-then-insert races in toggle operations, N+1 on follower listings, and orphaned pivot rows if models are deleted without FK/cascade or cleanup.
• Low supply-chain risk (BSD-3-Clause, small dependency-free codebase) but equally low bus factor; no CVE process or SLA.

Key questions

• Which Laravel/PHP versions are actually verified in CI (not just composer constraints)?
• Are UUID/ULID primary keys supported on both sides of the polymorphic relation?
• Does it emit Followed/Unfollowed events for notifications, auditing, and cache invalidation?
• Is there a unique constraint preventing duplicate follows, and what are the pivot indexes?
• Are count helpers live queries or denormalized? How is drift handled?
• What happens on model deletion — cascade, cleanup job, or orphans?

Integration Approach

Stack fit

• Native Laravel/Laravel-adjacent PHP stack, MySQL/Postgres/SQLite. No infrastructure change, no new runtime. Fits an existing Eloquent domain model regardless of whether the API is REST or GraphQL.
• Complementary rather than competing with existing auth and policy layers; authorization for "who may follow whom" stays in the app.

Migration path

• Greenfield: publish migration, run, add traits, ship.
• Brownfield (existing follows table): map legacy columns onto follower_*/followable_*, backfill, and run a dual-write or cutover window. Backfill is a straightforward INSERT ... SELECT but must dedupe and be idempotent.
• Ensure the pivot table lands with the right composite unique key and indexes from day one — retrofitting indexes on a large table is the expensive part.

Compatibility

• Pin the package version in composer.json and add a CI job that runs the trait's behavior on the targeted Laravel major. If the project is on Laravel 11/12 or PHP 8.3+, validate before committing; otherwise vendor/fork the two traits (permissive license makes this viable).
• Check DB-specific concerns: utf8mb4 index length on MySQL, string key lengths for UUIDs, and collation consistency between the pivot and target tables.

Sequencing

1. Spike: install, migrate, exercise follow/unfollow/toggle/count on a throwaway model.
2. Confirm events, uniqueness, UUID support, and Laravel version support.
3. Ship migration + indexes to staging; backfill legacy data if any.
4. Add traits to the first domain model; wrap in policies and expose via API resource.
5. Add eager-loading/withCount conventions and a cache strategy for counts.
6. Load test on a realistic follow graph (including high-fan-out targets) before production.

Operational Impact

Maintenance

• Ownership is effectively transferred to your team. Pin the version, and if upstream goes quiet, the fork cost is modest (small, dependency-free trait set). Budget a small recurring line item for Laravel-major upgrades.

Support

• Community-only. No vendor escalation path. Documentation is the README; treat gaps (events, edge cases) as your team's to close. BSD-3-Clause gives clean legal footing for a fork.

Scaling

• Growth is O(follow relationships), not O(users); a celebrity/"follow the whole org" pattern creates write hotspots on a single followable row and inflates reads for its follower list.
• Live count queries will not survive scale — denormalize counts or cache them (followersCount/followingsCount on the model, refreshed on follow/unfollow or via queued job).
• Index the pivot in both directions (follower_id/type, followable_id/type); paginate follower/following lists with cursor pagination.

Failure modes

• Duplicate follows from missing unique constraint or concurrent toggle.
• Orphaned pivot rows after model deletion.
• N+1 queries and slow follower-list endpoints if relations aren't eager-loaded.
• Count drift between live and cached values.
• Silent breakage on a Laravel major upgrade with no upstream release.
• Backfill duplicates or partial migration during brownfield cutover.

Ramp-up

• Very low for a Laravel-comfortable engineer: half a day to read the README and integrate; 1–2 days including tests and authorization. The real learning curve is not the package — it's the follow-graph sizing, indexing, and count-strategy decisions the package doesn't make for you.