Cqrs Http Laravel Package

Technical Evaluation

• Architecture fit: lmc/cqrs-http remains a thin CQRS-over-HTTP transport helper, not a full CQRS framework and not a Laravel-native package. It may fit a Laravel system that already separates commands and queries and needs shared base implementations for HTTP-bound commands/queries. It is a poor fit for a conventional Laravel monolith, a CRUD application, or a team without existing CQRS conventions. Laravel already provides strong primitives for command dispatch, queues, HTTP clients, validation, and events; this package should only be adopted if it removes real boilerplate around HTTP command/query contracts. The 3.0.0 release does not change this positioning — it is a language-modernization release, not a capability release.
• Integration feasibility: Moderate-to-low, and now gated on runtime version. Composer installation and MIT licensing are straightforward, but 3.0.0 requires PHP 8.1+, so any team still on PHP 8.0 cannot adopt this line at all without upgrading the runtime first. Laravel integration will still likely require a custom service provider, container bindings, configuration, HTTP client adaptation, serialization conventions, authentication propagation, and error mapping. The package has no visible Laravel ecosystem adoption, so assume no auto-discovery, no Laravel-specific documentation, and no community recipes. Feasibility depends on whether its abstractions are PSR-friendly and whether they can be hidden behind internal interfaces.
• Technical risk: High, and the 3.0.0 notes reinforce rather than reduce it. 3.0.0 is a breaking release ("[BC] Use new language features and change method signatures") with no migration guide, changelog detail, or deprecation path visible. Combined with 1 GitHub star, 0 dependents, a very low package score, and the fact that 3.0.0 (April 2022) is still the newest release, the signal is a maintainer who made one modernization pass and then stopped. The main risks are abandonment, PHP/Laravel version incompatibility, undocumented coupling to lmc/cqrs or specific HTTP clients, insufficient test coverage, and security/compatibility drift. Treat the package as source code the team may need to own rather than a maintained dependency.
• TPM recommendation: Conditional no-go for strategic adoption, unchanged. Allow only a time-boxed spike or isolated use behind an internal abstraction, and only on PHP 8.1+. Do not make it a foundational dependency for critical command/query flows without a fork-and-own decision. If a fork is chosen, base it on the 3.0.0 tag rather than 2.x so the team inherits the modern language features instead of owning a backport.
• Key questions: What exact interfaces/classes does it expose, and which method signatures changed in 3.0.0? Is there a migration guide or diff summary for 2.x → 3.x? What are its Composer dependencies and PHP/Laravel version constraints beyond the new PHP 8.1 floor? Does it require lmc/cqrs or another LMC package, and are those also PHP 8.1-compatible? How are request/response serialization, validation, auth, retries, idempotency, and correlation IDs handled? What is the test coverage and CI status, and did CI run on 8.1 for this release? Are there open security or compatibility issues? Does 3.0.0 remain compatible with our supported Laravel versions, or does the 8.1 requirement force a broader platform upgrade? Who owns maintenance if the upstream project is inactive? Can we replace it with Laravel's HTTP client plus a small internal command/query contract with less risk?

Integration Approach

• Stack fit: Use it only as an isolated transport layer for HTTP commands and queries. Keep Laravel-native validation, authorization, events, queues, and persistence in the application. Wrap the package behind internal interfaces such as HttpCommandBus and HttpQueryBus so the application does not depend directly on LMC classes. This matters more after 3.0.0: the BC method-signature changes are exactly the kind of churn the internal interface should absorb. If the package's abstractions leak into domain code, reject it.
• Migration path: Start with a branch or proof-of-concept module, not the main application. Confirm the platform is on PHP 8.1+ before investing — if not, the 3.x line is out of scope and there is nothing to evaluate. Add the dependency, inspect its API, build a Laravel service provider adapter, and implement one low-risk query and one low-risk command against a non-critical downstream service. Compare the result against a minimal custom implementation using Laravel's HTTP client. If any 2.x prototype or spike code exists internally, treat it as throwaway and re-implement against 3.0.0 rather than attempting an in-place upgrade. Promote only if the package materially reduces code and passes contract tests.
• Compatibility: Verify composer.json constraints before committing, with specific attention to the new PHP 8.1 floor and any transitive dependency bumps that came with it. Test against the team's current PHP and Laravel versions, and check for conflicts with Symfony/PSR packages already in the lockfile — a PHP 8.1-gated release may pull newer major versions of those libraries than the rest of the application uses. Because the last release is from 2022 and the ecosystem has moved on through PHP 8.2/8.3 and later Laravel majors, run a full compatibility matrix. If incompatible, either fork with explicit ownership or do not adopt.
• Sequencing: First confirm the PHP 8.1+ runtime baseline is approved and scheduled. Then inventory commands and queries that actually cross HTTP boundaries. Define internal contracts and failure semantics. Then prototype the adapter and contract tests for request shape, response mapping, auth, timeout, retry, idempotency, and error classification. Canary one endpoint in a non-critical path, observe for a release cycle, then decide whether to adopt, fork, or replace with custom Laravel code. Keep a rollback path throughout.

Operational Impact

• Maintenance: High relative to likely value. With 1 star, 0 dependents, and a single breaking 3.0.0 release that appears to be the project's last, the team should assume it owns upgrades, security review, and compatibility patches. Pin the exact version, document the fork policy, and avoid broad usage until the package proves stable in the target Laravel version. Record the 3.0.0 method-signature changes in the fork notes so a future maintainer knows what was inherited.
• Support: Minimal external support. There is no meaningful community or vendor backing visible, and a BC release with no visible migration guide means upstream will not help with upgrade questions. Incidents will be resolved by internal engineers reading source code. Assign an internal owner before adoption and require runbooks for HTTP failures.
• Scaling: The package itself is probably stateless, so scaling depends on the HTTP transport and downstream services. CQRS over HTTP adds network hops, latency, retry behavior, and partial-failure handling. Use timeouts, bounded retries with idempotency keys, circuit breakers, connection pooling, and asynchronous commands via Laravel queues where appropriate. Avoid synchronous HTTP command chains on user-facing critical paths.
• Failure modes: Expect timeouts, duplicate command delivery, partial successes, auth expiry, serialization/version mismatch, downstream 5xx responses, ambiguous 4xx responses, and stale dependency incompatibility. Commands need idempotency and compensation strategy; queries need caching/fallback where possible. Add one more mode specific to this release: silent behavior changes from the 3.0.0 signature refactor, where new language features (typed properties, constructor promotion, enums, readonly) alter expected input shapes or nullability without a documented migration note. Instrument correlation IDs, structured logs, metrics, and dead-letter/retry queues before production use.
• Ramp-up: Conceptual CQRS ramp-up is moderate; package-specific ramp-up is higher because documentation and examples are likely sparse, and the 3.0.0 API surface is undocumented relative to 2.x. Budget one senior Laravel/PHP engineer for a 1–2 week spike, plus additional time for production hardening, observability, and contract tests. Add a small allowance for reading the source diff to establish what the BC changes actually were. Do not spread the dependency across multiple teams until the isolated pilot has passed operational review.