Laravel Followers Laravel Package

Technical Evaluation

Architecture fit

• Standard Laravel package shape: service provider (auto-discovered), publishable config and migrations, and Eloquent traits (typically CanFollow / CanBeFollowed) applied to any model. This composes with existing domain models rather than imposing a new one — low architectural footprint.
• The relationship model is a polymorphic many-to-many pivot, so a single table associates arbitrary pairs of models (User→User, User→Team, User→Tag). That is the right primitive for a "follow" concept and avoids a table-per-relationship explosion.
• Fits cleanly inside a modular monolith or as a small bounded context in a service-oriented app. It does not dictate HTTP, UI, or feed-generation concerns, which is appropriate separation — but it also means the product-level features (feeds, notifications, counts) are ours to build.
• Trait-based design is idiomatic Eloquent but does create implicit coupling: model classes inherit the full API surface, and removing the package later is a non-trivial refactor across every model that used it.

Integration feasibility

• Install path is conventional: composer require, publish config/migrations, add traits to target models, run migrations. Realistically a half-day spike and 2–5 days to production-grade for a single team.
• Config-driven model swapping (if present) is a plus; verify it before assuming.
• Main friction points: naming collisions with any existing follows/followers table, and the need to add composite indexes and a uniqueness constraint the package likely does not ship.

Technical risk

• Maintenance risk is the dominant risk. 12 stars, a single maintainer, and a last release of 2023-02-21 means the package is effectively in maintenance-only or dormant status. It is not a dependency I would take without an internal ownership plan.
• Version-matrix risk. Composer constraints almost certainly do not cover current Laravel/PHP releases. Expect either to pin the framework or to fork.
• Mitigating factor: MIT license and small surface area make a fork-and-vendor strategy cheap — arguably cheaper than the diligence required to depend on it. The traits are a few hundred lines, not a framework.
• Correctness risks to validate: duplicate follows (race conditions), orphaned pivot rows after model deletion, and morph-map alias vs. FQCN drift.
• Low direct security surface (no HTTP layer, no deserialization, no auth), but it inherits whatever transitive dependencies its constraints pull in.

Key questions

1. Which Laravel and PHP versions are actually supported by the current composer.json constraints, and do they include our target?
2. Does the shipped migration include a unique composite index on (follower_type, follower_id, followable_type, followable_id)? If not, duplicate follows are a data-integrity bug we inherit.
3. Does it support richer semantics we may need soon — follow requests/approval, blocking, muting — or only unconditional follow/unfollow?
4. Are domain events dispatched on follow/unfollow (for notifications and feed fan-out), and are they reliable?
5. What is the test coverage, and is CI green against current framework versions?
6. Which models must be followable in our product (User, Team, Tag, Collection), and do we need per-type counts?
7. Is the maintainer responsive to issues/PRs, and is there a credible plan if they are not?

Integration Approach

Stack fit

• Natural fit for a Laravel app already using Eloquent, Sanctum/Breeze/Jetstream auth, and standard migrations. No opinion on frontend (API or Blade), so it slots under an existing SPA/mobile API without rework.
• Complements, rather than replaces, notification and feed infrastructure — those remain our build.

Migration path

• Greenfield: publish config and migration; immediately amend the schema to add composite indexes and a unique constraint before the first row is written. Cheaper now than after backfill.
• Brownfield (existing custom follow table): write an explicit data migration mapping legacy columns onto the polymorphic shape. Backfill *_type with morph-map aliases, not FQCNs, and register those aliases via Relation::morphMap() before backfilling — otherwise every subsequent refactor of a namespace silently breaks relations.
• Decommissioning path: because the API is trait-based, plan for an internal FollowRepository/service that wraps the trait calls. That gives a single seam to swap in a fork or a bespoke implementation later.

Compatibility

• Verify composer.json constraints against our PHP (8.1/8.2/8.3) and Laravel versions. If unsupported, choose deliberately between (a) pinning the framework, (b) forking with widened constraints, or (c) reimplementing the ~200 lines in-house. For a package at this maturity level, (b) or (c) is usually correct.
• Audit the transitive dependency tree in CI; a dormant package is a magnet for stale transitive constraints that block future upgrades.

Sequencing

1. Timeboxed spike in a throwaway branch — install, publish, exercise follow/unfollow/followers/following against our models.
2. Confirm the version matrix and decide depend vs. fork vs. reimplement. Record the decision.
3. Finalize schema (indexes, unique constraint, timestamps, optional status column) and register morph map.
4. Wrap the trait behind a repository/service interface; keep package calls out of controllers and jobs.
5. Backfill from any legacy data; validate counts against source of truth.
6. Roll out behind a feature flag with instrumentation on write volume and error rate.
7. Add deletion observers to clean pivot rows when followable models are removed.

Operational Impact

Maintenance

• Treat this as internally owned code from day one. Assume zero upstream responsiveness; budget a small recurring allocation for dependency bumps and framework-upgrade compatibility.
• Pin exactly (no ^ on a dormant package) and let Dependabot surface constraint drift. Semver discipline in a single-maintainer project is not a guarantee.
• Maintain a fork readiness checklist so a takeover is a one-day operation, not a one-week one.

Support

• No SLA, no paid support, community issues only. Escalation path is our own engineers reading the source — acceptable for a small, readable package; unacceptable for anything load-bearing that we have not read.
• Designate a named internal owner and document the decision record for why this package versus a bespoke implementation.

Scaling

• Pivot table growth is linear in follow actions. At 1M users × 50 follows, expect ~50M rows: this is fine for a well-indexed relational table but not for unindexed polymorphic scans.
• Mandatory indexes: (follower_type, follower_id) and (followable_type, followable_id); both are read paths for "who do I follow" and "who follows me."
• withCount on polymorphic relations is workable at low cardinality but degrades for high-follower accounts. Beyond roughly 10k followers per entity, denormalize counts (counter column or Redis) and reconcile asynchronously.
• Feed generation must not do per-request pluck() over the following list. Use chunked, queued fan-out or pull-on-read with caching; the package gives you the relationship, not the feed strategy.
• Polymorphic foreign keys cannot be enforced by the database. Orphan-row cleanup is our responsibility and must be an explicit, tested behavior.

Failure modes

• Duplicate follows inflating counts (missing unique constraint or unsynchronized concurrent writes).
• Orphaned pivot rows after model deletion, producing ghost followers in listings and counts.
• Morph-map mismatch — a class rename or namespace move silently breaks all relations with no error until read time.
• N+1 query explosions in follower/following listings if eager loading is not enforced by the wrapper layer.
• Framework upgrade blocked by the package's version constraints, discovered late in an upgrade cycle.
• Silent behavioral change on an accidental minor/major bump because upstream is not actively reviewed.

Ramp-up

• Low learning curve: the public API is a handful of trait methods, and a mid-level Laravel engineer is productive within half a day from the README.
• The real onboarding cost is not the package — it is the internal conventions we must layer on top: morph map discipline, repository seam, count denormalization, and deletion cleanup. Budget for documenting those, because they are what makes this safe to operate.