Cqrs Http Laravel Package

Product Decisions This Supports

• API surface architecture. The package encodes a specific HTTP contract: read endpoints map to Query objects, write endpoints map to Command objects. Adopting it is effectively a decision that the API's route taxonomy, versioning, and caching strategy will be CQRS-shaped rather than resource-shaped — that ripples into CDN rules (GET/cacheable vs POST/non-cacheable), rate limits, and idempotency keys.
• Build vs. buy for the glue layer. The genuinely useful artifact here is the pattern — a thin controller/middleware that hydrates a Command or Query from the request, dispatches it on a bus, and maps the result or exception to a response. That is on the order of a few hundred lines of first-party code. The decision this package forces is whether to take a dependency for that glue or own it.
• Dependency versioning discipline. The 3.0.0 release is a breaking-major: it raises the floor to PHP 8.1, adopts newer language features, and changes method signatures. That tells us the HTTP→handler seam is not a stable contract across majors, so if we ever vendor it we must pin an exact tag and treat upstream signature changes as a migration, not an upgrade. This is a governance cost to price into the build-vs-buy call.
• Refactor sequencing on the roadmap. It defines a concrete intermediate state for the "fat controllers → handlers" migration: controllers become adapters, business logic moves behind CommandBus/QueryBus, and the HTTP edge stays stable while the internals churn. Useful for phasing a multi-sprint refactor behind an unchanged public contract.
• Use-case fit. Best value in back-office/admin panels, internal tools, and backend-for-frontend APIs where read and write models genuinely diverge, or where several teams need one shared request→handler convention. Low value for straightforward CRUD that Laravel resource controllers already cover.
• Cross-team standardization. The real ROI is convention enforcement — a single place for validation, authorization, error envelopes, and idempotency across many endpoints — not raw functionality.
• Opportunity read. The relatively high opportunity signal against near-zero adoption suggests a market gap for Laravel-native CQRS-over-HTTP tooling, not that this package is ready to fill it. A single major release that only modernizes the language floor — with no feature, performance, or interoperability work — reinforces that read: the space is underserved, this artifact is not the answer.

When to Consider This Package

Consider it when:

• Your team has already committed to CQRS and needs a uniform HTTP→handler convention rather than bespoke controllers per service.
• You are on LMC's lmc/cqrs base abstractions, so the contracts line up without adapters — and you can absorb the 3.0.0 signature changes at the same time.
• Multiple teams/services need an identical, documented request-dispatch convention and the cost of divergence is measurable.
• You intend to use it as a reference implementation to copy patterns from, with the source pinned to an exact tag (3.0.0 specifically, not a floating constraint) and vendored rather than installed.

Look elsewhere when:

• Single application, no CQRS commitment. Laravel's container plus invokable controllers, form requests, or lorisleiva/laravel-actions deliver the same ergonomics with no additional dependency.
• Maintenance posture matters. One star, zero dependents, last release 2022-04-27, no visible community. Treat this as effectively unmaintained: no security response, no PHP 8.2+/Laravel 10–11 compatibility guarantee, and you inherit the fork.
• Signature stability matters. 3.0.0 is a breaking change to method signatures with no documented upgrade path and no subsequent patch cadence to signal the API has settled. Anything bound to it inherits that churn.
• You need async execution. Queued commands, retries, middleware pipelines, and failure transports are out of scope — reach for Laravel's bus/queue or Symfony Messenger.
• You need event sourcing, aggregates, or projections. Use EventSauce, Spatie event-sourcing, or Ecotone.
• You need schema generation, auth integration, or validation contracts. Also out of scope; you will build those regardless.
• Supply-chain policy is strict. A dormant single-maintainer package at your HTTP boundary is an avoidable audit item — and a major version bump that only raises the PHP floor is not evidence of renewed stewardship.

How to Pitch It (Stakeholders)

To executives: This is a small open-source helper that standardizes how our API turns an incoming HTTP request into a business operation. Its substance is a few hundred lines of convention, not new capability. Its most recent release (3.0.0, April 2022) is a breaking major that raises the minimum PHP version to 8.1 and changes internal method signatures — housekeeping, not new functionality, and nothing has shipped since. Because it is a 2022-vintage package with essentially no adoption and no active maintenance, my recommendation is to use it as a design reference and implement equivalent glue in-house on top of Laravel's existing command bus — roughly one engineering day, no third-party maintenance exposure, and no deviation in delivery timeline.

To engineering: It codifies HTTP→Command/Query dispatch: request mapping, handler resolution, response mapping, exception-to-status translation. The abstraction cost is low and the pattern is sound. The distribution risk is high. Note that 3.0.0 is a breaking release: PHP 8.1 floor, new language features, and changed method signatures with no upgrade guide — so the seam is not stable upstream, which is exactly what we don't want pinned at our API boundary. Proposal: lift the pattern into an app/Shared/Messaging namespace — one CommandBus/QueryBus contract, one middleware that hydrates from the request, one exception map — while keeping Laravel's validation, authorization, and middleware untouched. We get identical ergonomics, retain full control of the HTTP contract, and avoid pinning a dormant dependency at our API boundary. If we do reference the source, vendor it against the 3.0.0 tag and treat its signatures as inspiration rather than a contract. Revisit only if we split into multiple services and need a shared cross-service dispatch contract.