Hypervel Influxdb Laravel Package

Technical Evaluation

Architecture fit

• This is a Hypervel component, not a vanilla Laravel package. Hypervel is the Laravel-compatible fork built for coroutine runtimes (Swoole/OpenSwoole); the package consumes hypervel/components contracts rather than illuminate/*. Fit is strong only if the target service is already on Hypervel. On Laravel 10/11 it is not a drop-in.
• Core value proposition is an InfluxDB client with two parallel InfluxQL stacks plus a new FailureStore for failed writes. The dual-stack design is the package's main architectural decision and, per the release notes, its main source of debt.

Integration feasibility

• v0.2.0 requires hypervel/components 0.4.x-dev — an untagged dev branch. Adopting this package means pinning the entire framework to a moving branch, not just adding a metrics dependency.
• PHP version is not declared by the package; it is inherited transitively from the framework constraint. This is a real operational trap: PHP bumps arrive as unexplained downstream breakage rather than as a readable requirement.
• Packagist install is now documented (with dated composer pins), which removes the earlier VCS-repository friction but does not remove the stability constraint.

Technical risk — medium-high

• Pre-1.0 (0.2.0) with a breaking change shipped in a minor bump (#52, "keep the twin InfluxQL stacks in step"). Behavior of query construction/parsing may differ from 0.1.3.
• The twin-stack architecture is self-acknowledged debt ("tech debt phase 2/3"). Parallel implementations drift; the breaking change is evidence that drift already occurred and was corrected by hand.
• Dev-branch dependency + minimum-stability implications + lockfile churn = non-reproducible builds if we are not disciplined about commit pinning.
• Positive signal: real InfluxDB integration tests landed in this release. That materially raises confidence versus mocked tests and is the single strongest point in the changelog.

Key questions

1. Is any current or planned service actually on Hypervel, or is this being evaluated against a Laravel/Illuminate stack?
2. What is the 0.4.x-dev → 0.4.0 timeline? Can we wait for a tagged framework release?
3. What exactly broke in the InfluxQL alignment — query semantics, escaping, retention policy handling, or internal structure only?
4. Which of the two InfluxQL stacks is the intended default, and is the other deprecated?
5. What are FailureStore's retry, retention, and overflow semantics? Does it write to disk, memory, or a queue?
6. Why is the PHP constraint not declared directly in this package's composer.json?
7. Bus factor: changelog shows two active contributors and heavy automated CI activity — is there a maintainer commitment beyond 0.x?

Integration Approach

Stack fit

• Greenfield Hypervel service on Swoole: good fit, adopt.
• Existing Laravel/Illuminate service: poor fit. Do not introduce this as a metrics sidecar; the framework coupling makes it all-or-nothing.

Migration path

1. Do not upgrade 0.1.3 → 0.2.0 in place; the breaking change touches the InfluxQL path, so treat it as a re-validation, not a bump.
2. Pin hypervel/components to an explicit commit SHA, not 0.4.x-dev, and record the resolved PHP version in our own CI matrix.
3. Add minimum-stability: dev with prefer-stable: true, or a VCS repository entry — whichever keeps the lockfile auditable. Document the pin date in the repo, mirroring the package's own new practice.
4. Land on one non-critical service first, run both stacks against a staging InfluxDB, and diff query results before cutting over.

Compatibility

• Verify PHP version actually resolved from the framework constraint against our runtime images before scheduling work.
• Confirm InfluxDB server version(s) supported by both stacks — the integration tests define the tested matrix, so read them rather than the README.
• Check FailureStore's dependencies (queue? filesystem?) against our existing failure-handling conventions; we do not want a second, package-specific dead-letter mechanism.

Sequencing Framework tag (or accepted SHA pin) → package pin → staging integration test → FailureStore ops runbook → production. Do not parallelize the framework pin and the package pin; failures will be unattributable.

Operational Impact

Maintenance

• Low-to-moderate and currently noisy: the changelog is dominated by shared-CI file updates and Dependabot action bumps, which means the release cadence overstates functional change. Two named contributors plus automation.
• The "tech debt phase 1/2/3" framing is candid but tells us the package is still being stabilized. Expect at least one more breaking change before 1.0.

Support

• GitHub issues only, no LTS, no vendor SLA, no security policy visible in the notes. Acceptable for internal metrics plumbing; not acceptable for anything on a customer-facing critical path.

Scaling

• Under Swoole, watch connection-per-worker behavior and coroutine safety of the client; validate pool sizing under load rather than trusting defaults.
• Confirm write batching/backpressure behavior — an unbounded in-memory buffer plus FailureStore can mask or amplify memory growth under sustained InfluxDB unavailability.

Failure modes

• Silent metric loss if FailureStore overflows or drops without a counter. Instrument it from day one.
• Unbounded FailureStore growth during a prolonged InfluxDB outage — needs a size cap and an alert.
• Twin-stack divergence producing different query results depending on which path a code location uses.
• Build breakage from the dev dependency — an upstream force-push or branch rename breaks our pipeline with no version-number signal.
• Transitive PHP bump failing CI in a way that points at the wrong package.

Ramp-up

• Two unfamiliar surfaces at once: Hypervel's coroutine runtime and InfluxQL (versus the more common Flux). Budget real ramp time; this is not a same-day integration.
• FailureStore ships without an ops runbook in this release — we will be writing the monitoring, retention, and replay procedures ourselves.

Assessment trigger: revisit to a stronger recommendation once hypervel/components has a tagged 0.4.x release, the package declares its own PHP constraint, and the two InfluxQL stacks are consolidated or one is explicitly deprecated.