Discussion Views Laravel Package

Product Decisions This Supports

• Feature scope: social proof on discussion lists. View counts are a cheap engagement signal that can inform whether we surface "X views" next to replies, add a "Most viewed" sort, or feed a trending widget. This package is the smallest possible experiment to validate that hypothesis before committing roadmap.
• Build vs. buy for engagement telemetry. If the only requirement is a per-discussion counter, adopting a single-purpose MIT extension is materially cheaper than building and maintaining an event pipeline. This package defines the "buy" pole of that comparison; anything more (unique viewers, funnels, retention cohorts) pushes us toward "build."
• Ranking and discovery logic. "Hot," "trending," and "popular this week" surfaces need a view signal as an input. Deciding to adopt a counter now is a prerequisite for those roadmap items later.
• Content operations decisions. Which categories get traffic, which discussions deserve pinning or featuring, where to invest moderator time — view counts are a lightweight proxy when we don't have a real analytics stack.
• Commercial/inventory decisions. If the forum carries sponsorships or advertising, view counts become a defensible inventory metric rather than an estimate.
• Dependency posture decision. A package with ~1 star, 0 dependents, and a low composite score is a decision about acceptable vendor risk for a non-differentiating capability — useful as a forcing function on whether we fork, pin, or skip.

When to Consider This Package

Consider it when all of the following hold:

• The product is a Flarum forum. This is a Flarum extension, not a general Laravel package — it plugs into Flarum's extension API and asset pipeline, not a standard Laravel service provider. It will not drop into an arbitrary Laravel app.
• We need simple per-discussion view counts and nothing more. No unique-viewer deduplication, no cohort analysis, no export.
• We accept an MIT-licensed, community-maintained dependency with effectively no public adoption signal, and are prepared to pin the version and fork if abandoned.
• Traffic is moderate. View counting is inherently write-heavy; at high read volumes this needs caching or batching, which the extension may not provide out of the box.
• Flarum and PHP version compatibility can be verified against our current runtime before rollout.

Look elsewhere when:

• We need an analytics product — event streams, dashboards, retention, attribution. Use a dedicated analytics tool and keep it out of the forum database.
• We have privacy/GDPR constraints requiring anonymized or consent-gated tracking; view-counting extensions typically write viewer-linked rows and may retain IPs.
• We need an SLA, security review, or named maintainer. Zero dependents and single-digit stars means no downstream battle-testing and no ecosystem pressure to keep it patched.
• The target stack is plain Laravel or a different forum platform — this is not portable.
• Data quality is a concern. The metadata here is internally inconsistent (a release dated in the future, near-zero adoption). Treat the version and maintenance claims as unverified until checked against the repository and packagist directly.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source add-on that puts a view counter on forum discussions. It costs nothing to license and very little to evaluate, and it gives us a first, cheap read on what content actually gets attention — which informs what we feature, pin, and eventually monetize. The risk is not financial; it's maintenance. The project has essentially no public adoption, so I'd frame this as a time-boxed pilot, not a platform commitment: two weeks, one environment, a clear kill criterion, and a fork-and-own fallback if we decide to keep it.

To engineering: Narrow surface area — it's a Flarum extension with a migration, a listener or middleware, and a frontend component, installed via Composer. It is not a Laravel package in the conventional sense, so it will not follow our normal service-provider integration pattern. Two things to check before we commit: (1) write amplification on the discussion table under real read volume, and whether counts can be batched or cached; (2) compatibility with our pinned Flarum and PHP versions, since there is no downstream ecosystem to catch breakage. Recommend pinning the exact version, adding a smoke test on the discussion list endpoint, and confirming we can remove it cleanly without schema damage.

Bottom line: Low cost, low blast radius, low adoption signal. Worth a scoped pilot if view counts are genuinely on the roadmap; not worth adopting speculatively.