Analytics Core Api Laravel Package

Technical Evaluation

Architecture fit liberusoftware/analytics-core-api is explicitly a presentation adapter — a thin HTTP/JSON layer that sits in front of an analytics domain core rather than implementing analytics itself. That is a defensible architecture (transport concerns isolated from domain logic), but it means the package is only valuable as part of a matched set. Adopting it implies adopting the Liberu module family: a modular Laravel monolith convention (service-provider registration, module namespacing, likely nwidart/laravel-modules-style layout) plus an analytics core domain package that owns the actual query, aggregation, and metric-definition logic. For a TPM, the practical read is: this is not a feature you buy, it is a wire you connect. If the domain core isn't already in the stack, this package delivers no standalone capability.

Integration feasibility Mechanically low-friction: Composer install, package auto-discovery, routes registered by the service provider. The real feasibility question is contractual, not technical — the adapter's usefulness is bounded by the stability of the domain-layer interfaces it calls. Expect to spend the first sprint reading source rather than reading docs, because the repository signals (zero stars, zero dependents, description-only README framing) indicate there is essentially no consumer-facing documentation or worked example.

Technical risk

• License is unresolved (NOASSERTION). This is the single hardest blocker. It is not a "review later" item; redistribution or SaaS use of a package with an unidentifiable license is a legal exposure that must be cleared in writing before it enters a production dependency graph.
• Zero adoption. No stars, no dependents, no downstream issues to mine for failure patterns. You will be the first serious integrator, which converts every unknown into your team's discovery cost.
• Bus factor of one, effectively. Single-vendor, single-maintainer module with no community backstop.
• Release metadata is anomalous. A 2026-10-26 last-release date is in the future relative to normal consumption patterns; treat the tag as unverified until you confirm what it actually contains (signed tag, CI artifacts, changelog).
• Presentation layers are where authz bugs concentrate. An adapter that registers routes by default can unintentionally widen your API surface if middleware, throttling, and tenancy scoping are not explicitly reasserted in your app.

Key questions

1. What license governs the code, and will the maintainer state it in writing?
2. Which exact domain package and version range does this adapter require, and are those interfaces semver-stable?
3. Does it ship migrations, config publishes, or queue jobs — or is it purely controllers/resources?
4. What is the auth and multi-tenancy model, and are routes registered conditionally?
5. Does it ship a contract/feature test suite I can run against my own install?
6. Who consumes the analytics output — internal dashboards or external tenants — and does that data include PII?

Integration Approach

Stack fit Assumes a modern Laravel application (PHP 8.2+, Laravel 10/11-era conventions) organized as modules. If your application is a conventional app/ monolith, introducing one module's directory and provider conventions for a single adapter is a poor structural trade — the module scaffolding cost exceeds the code you inherit.

Migration path There is no migration path to this package in the usual sense; there is only an integration decision. Two viable paths:

• Adopt-in-place — you are already running Liberu modules; pull the adapter to avoid reimplementing controllers, and accept the coupled upgrade cadence with the core.
• Reference implementation — do not install it; read it as a specification for your own three or four controllers over your existing analytics service. Given the size of a presentation adapter, this is usually cheaper than the governance overhead of a new third-party dependency.

Compatibility Pin an exact version, not a caret range. With no dependents, no release history to speak of, and no maintainer semver track record, floating constraints are uninsurable. Verify framework constraints in composer.json against your actual Laravel version before committing; presentation adapters frequently lag framework majors by a release cycle.

Sequencing

1. Legal gate — resolve the license question before any engineering time is spent.
2. Sandbox spike — install in a throwaway branch, boot the app, enumerate every registered route (route:list) and diff against expectations.
3. Contract tests — write your own request/response tests against the adapter's endpoints; these become your regression net and your fork-safety harness.
4. Wrap, don't scatter — expose it behind a single internal facade or your own interface so the vendor package is swappable in one commit.
5. Shadow mode — run behind auth and feature flags internally before any tenant-facing exposure.

Operational Impact

Maintenance You should budget as if you are the maintainer. Expect to fork within twelve months, at minimum to patch dependency constraints and to add the license header the upstream lacks. Assign explicit ownership; an unowned adapter in the request path becomes an unowned security surface.

Support There is no commercial support and no meaningful issue-tracker history to lean on. Internal escalation is your only escalation path. Document the fork process and the upstream-sync cadence on day one.

Scaling The adapter itself is not the bottleneck — it is I/O-thin. All scaling cost lands on the analytics core and the underlying datastore: aggregation queries, cache hit rates, and export payload sizes. TPM-level mitigations belong upstream (query timeouts, result caps, pagination enforcement, cache TTL policy), and you should verify the adapter does not defeat caching by default.

Failure modes

• Silent route exposure — endpoints registered without your auth middleware; caught only by a route:list audit.
• Upstream interface drift — core package refactor breaks the adapter at runtime with no compile-time warning in PHP; caught only by contract tests.
• Unbounded result sets — analytics endpoints returning full datasets and timing out the worker.
• Missing publishables — config or migrations never published, yielding default (often permissive) behaviour.
• Abandonment — no commits for a year with your app still on it; mitigated by the wrapper facade.

Ramp-up Code-reading effort is low; domain effort is high, because the analytics semantics live in a separate, equally undocumented package. Estimate one engineer-week to first confident internal endpoint, plus legal turnaround, plus ongoing fork maintenance of roughly a day per quarter.

Verdict Conditional at best. Score (19.8/100) and the zero-adoption signals are consistent with a package that is architecturally reasonable and operationally unsupported. Recommend proceeding only if the Liberu module family is already a load-bearing part of the stack and the license is resolved in writing; otherwise, treat the repository as a reference implementation and write the thin adapter yourself — it is a few controllers and a route file, and you keep the IP clean.