Laravel Users Online Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Laravel utility — a service provider, a middleware that records user activity, and an Eloquent scope/query for "online" users — so its architectural footprint is small and it slots cleanly into a conventional Laravel MVC monolith with session-based auth. It targets nothing exotic (no queue infrastructure, no event sourcing, no multi-tenant awareness), which makes it easy to reason about but also limits it: it assumes a single app, single auth guard, and a shared session store. There is no clean story for distributed deployments beyond what the underlying session driver already provides.

Integration feasibility. Installation is standard Laravel: Composer require, auto-discovered service provider, vendor:publish for config and migration. The logic surface is small enough to read and audit in an afternoon, which is a genuine advantage — if the package is incompatible, the fallback (vendor the ~200 lines of middleware + model scope) is cheap. The real integration question is not effort but version compatibility.

Technical risk. This is the dominant concern and it is high:

• Staleness. Last release 2019-10-07, which places it in the Laravel 5.x/6.x era. Laravel has since shipped 8 major versions; PHP has moved from 7.x to 8.2+. Composer constraints almost certainly exclude Laravel 9+, and the code likely assumes PHP 7 semantics (untyped properties, old container signatures, $dates, deprecated facade helpers).
• Unmaintained. No releases in ~6 years with only 197 stars and an opportunity score of 1.9 signals a package with limited users and no active maintainer. We would own every bug and every framework upgrade.
• Session coupling. Online-tracking correctness depends entirely on the session driver and last_activity semantics. With Redis/database sessions this can behave differently than with file sessions, and multi-node deployments need a shared store or the "online" count fragments.
• Write amplification. If it writes last_activity on every request (the common pattern), that is a DB write per authenticated request — a real cost at scale and a source of lock contention.
• False positives. No bot filtering, no activity threshold tuning, timezone handling, and stale rows that never get cleaned up all produce misleading "online" numbers.

Key questions for engineering.

1. Which Laravel/PHP versions are we actually on, and does the package's composer.json constraint allow them as-is?
2. Does it write to users.last_activity, a dedicated table, or the session store? What is the per-request write cost?
3. Does it hook the session driver, an Authenticate middleware, or a global middleware — and does that conflict with our existing audit/activity logging?
4. How are stale "online" records expired, and is there a scheduled cleanup, or does the query rely purely on a time-window filter?
5. Multi-node behavior: is the activity source shared (Redis/DB sessions) or node-local?
6. Is there a test suite, and does it run on our PHP version?
7. Can we meet the same requirement by extending Laravel's built-in session/Auth primitives or our existing activity log rather than adding a dependency?

TPM read. Low opportunity score (1.9) + 2019 release date + small surface area points to a "don't adopt, re-implement or fork" decision rather than a dependency bet. The feature is genuinely small; the risk is in the dependency, not the problem.

Integration Approach

Stack fit. Fits a standard Laravel monolith on the same major version it was built for (≈ Laravel 5.5–6, PHP 7.1–7.4). On Laravel 10/11/12 the package will not install cleanly; the logic is still reusable but the package as shipped is not.

Migration path. Two viable routes, chosen by our current framework version:

• If we are on a supported legacy Laravel (≤6): Install as-is, publish config and migration, register middleware on the web group, add a scheduled cleanup command, and put the "online count" behind a feature flag. Accept that we are now the de-facto maintainer.
• If we are on modern Laravel (recommended assumption): Fork or vendor. Copy the middleware + model scope into our app (or a first-party app/Support/OnlineUsers module), upgrade signatures to PHP 8, replace deprecated helpers, and drop the external dependency. This preserves the feature, removes the abandonment risk, and gives us control over write cost.

Compatibility. Validate before committing: Composer constraint vs. our laravel/framework and PHP versions, presence of deprecations ($dates, getDateFormat, container bind signatures), and whether the published migration collides with an existing users schema. Run the package's tests (if any) on our PHP version as a smoke check — expect failures on 8.2+.

Sequencing.

1. Spike (0.5 day): Read the source, confirm the tracking mechanism, measure per-request cost, test install against our framework version.
2. Decide (go/no-go): Adopt fork, or re-implement in-house. Default to re-implement given the risk profile.
3. Implement (1–2 days): Middleware to stamp activity (batched/cached, not a raw write per request), a query scope with a configurable window, and a scheduled cleanup job.
4. Harden (0.5–1 day): Shared cache/session for multi-node, bot filtering, timezone normalization, feature flag.
5. Roll out: Staging validation of the "online" count against reality, then production behind a flag with a metric to compare reported vs. expected.

Operational Impact

Maintenance. This is the headline cost. Adopting the package means inheriting an unmaintained dependency with no upgrade path across eight Laravel majors. Every framework bump becomes our bug. Forking transfers that burden explicitly, which is arguably better than discovering it silently. Budget ongoing ownership either way — there is no "install and forget" here.

Support. Effectively none from upstream: last release 2019, low star count, low opportunity score, no signal of an active maintainer. Internal support requires someone who has read and understood the tracking logic — keep it small, documented, and owned by the platform team.

Scaling. The naive implementation (write last_activity per request) does not scale gracefully: it adds a write to every authenticated request, drives DB contention, and inflates the "online" query cost as the users table grows. Mitigations: batch activity stamps (e.g., only update if last write > N seconds ago), push the "who is online" set into Redis with TTL, and index the activity column. Multi-node correctness depends on a shared session/cache store — file sessions will fragment the count per node.

Failure modes.

• Stale counts: no cleanup job → users appear online forever; time-window filter mitigates but does not eliminate.
• Write storms / lock contention: per-request DB writes under load.
• Fragmented counts: multi-node with node-local sessions.
• False positives: bots, keep-alive polling, and long-lived tabs counted as "online."
• Silent breakage on upgrade: the package simply fails to install or throws deprecation errors after a framework/PHP bump.
• Timezone drift: activity windows computed inconsistently between app and DB.

Ramp-up. Low learning curve — the feature is simple and the codebase is small — but ramp-up is dominated by compatibility and hardening work, not comprehension. Realistic effort: ~0.5 day to evaluate, 1–2 days to fork/fix or re-implement, ~0.5–1 day to harden for multi-node and cleanup. The TPM recommendation is to treat this as a small in-house capability rather than a third-party dependency, since the logic is cheap to own and the package's staleness and low opportunity signal make adoption a net liability.