zepfietje/laravel-seeable
Laravel Seeable adds seen/unseen tracking to your Eloquent models. Attach the trait to let users mark records as seen, check whether an item has been viewed, and query unseen records per user—handy for notifications, activity feeds, and read receipts.
Architecture fit. laravel-seeable is a single-purpose, Laravel-idiomatic package: it augments an Eloquent model with a last_seen_at timestamp (typically via a Seeable trait), updates it from a request middleware, and offers a small surface of scopes/accessors for querying "recently active" users. Architecturally that is a clean fit for any conventional Laravel MVC/cookie-session application, and it maps naturally onto the standard Laravel extension points (service provider, publishable migration, trait, global/route middleware). There is no exotic dependency, no queue or event infrastructure requirement, and no proprietary backing service. In pure architecture terms, integration cost is low.
Integration feasibility. Mechanically straightforward: composer require, publish and run the migration, add the trait to the User model, register the middleware. A competent Laravel developer validates this in under a day. The blocker is not technical feasibility but governance: the package is archived, last released 2023-02-14, with 35 stars and a composite health score of 0.1625. That combination will trip most organizations' automated dependency policy checks (archived-repo detection, stale-package rules, maintainer-count rules) and will fail any "is this maintained?" review question. Any real integration must therefore be framed as adoption of vendored source code, not dependency consumption.
Technical risk. The dominant risk is silent compatibility drift. The 2023 release predates multiple Laravel majors; its composer.json constraints, illuminate/* version bounds, and middleware/container API usage may not be valid on current Laravel. That failure mode is quiet — a package can resolve and boot while subtly misbehaving (middleware not firing due to changed priority ordering, timestamp attributes not being recognized). Secondary risks: a per-request UPDATE against the users table creates write amplification and row-contention on hot rows; timezone handling for the "last seen" value is easy to get wrong; and the package almost certainly tracks a single guard/user type, which may not suit multi-guard, multi-tenant, or API-token-authenticated flows. Because it is archived, there will be no upstream security patches or Laravel-version fixes — every future framework upgrade forces an internal patch decision.
Key questions.
users table on every request acceptable at our traffic profile, or do we need throttling, a side table, or async writes?last_activity columns) that covers the same need?Stack fit. The package targets the standard Laravel user-authenticated web application. It fits if — and only if — our requirement is literally "one nullable timestamp per user, updated on authenticated activity." It does not fit if we need audit history, per-session presence, or real-time "online now" indicators.
Migration path. Do not add it as a live Composer dependency. Two viable paths, in preference order:
last_seen_at timestamp to the users table via our own migration; add an internal trait and a terminable middleware that updates the column behind a cache-based throttle (e.g., at most once per 60–300 seconds per user). This removes the dependency entirely, keeps the code under our review and test coverage, and eliminates the "archived package" finding from the dependency report.If someone insists on the package itself for a short-lived spike, scope it to a throwaway branch and treat the resulting code as a reference implementation, not a shipped dependency.
Compatibility. Verify against our exact Laravel and PHP versions before anything else — the 2023 release date makes this a hard gate, not a formality. Check middleware registration behavior under our version's middleware priority rules, and confirm the migration is idempotent and reversible. Confirm no collision with an existing last_seen_at/last_activity column.
Sequencing.
users table contention.Maintenance. Effectively infinite ownership transfer. An archived package means we inherit all future maintenance at the moment of adoption, but without the benefit of having written the code. The native route has the same ownership burden with a smaller, better-understood surface — which is the core argument for reimplementation.
Support. No upstream support channel, no maintainer responsiveness, no CVE pathway. Internal teams must own triage. Low blast radius (a stale timestamp) limits severity, which is the one genuinely favorable operational property here.
Scaling. The architectural weak point is the write path: one UPDATE per authenticated request against a shared table. At moderate traffic this produces lock contention and index churn on users, which is usually the most contended table in a Laravel app. Mitigations are mandatory rather than optional: cache-backed throttling, a separate user_activity table, or deferred/queued writes. Also consider read patterns — "who is online" queries over a low-cardinality timestamp column need an index and will not scale as a naive WHERE last_seen_at > ? scan on large user tables.
Failure modes. (a) Middleware silently not registered or reordered after a framework upgrade — feature appears to work but timestamps freeze; needs an assertion test. (b) Write amplification degrading login/checkout paths sharing the users table. (c) Timezone/UTC drift making the column unusable for analytics. (d) Migration conflicts with pre-existing activity columns. (e) Abandoned package flagged in a future security/compliance audit, forcing an emergency rip-out. (f) Multi-guard or token auth silently bypassing the middleware, producing misleading "inactive" data.
Ramp-up. Negligible. Any Laravel developer understands trait-plus-middleware-plus-migration in hours; no specialized domain knowledge, no new runtime, no new operational surface. This low ramp-up cost is itself the reason not to take on an archived dependency for it.
TPM recommendation. Decline adoption of zepfietje/laravel-seeable as a runtime dependency. The functionality is small enough that build cost is under one engineer-day, while the archived status imposes permanent, uncapped maintenance and compliance cost. Reimplement natively, or vendor the MIT source under internal ownership if speed outweighs cleanliness — and either way, keep the public API shape (last_seen_at, a seen()-style update method, a "recently active" scope) so downstream code is unaffected by the choice.
How can I help you explore Laravel packages today?