Dispatcher Laravel Package

Technical Evaluation

Architecture fit. Poor. Hoa\Dispatcher is not a utility library that slots into Laravel — it is a competing dispatch stack. It brings its own router (hoa/router), HTTP abstractions (hoa/http, hoa/stream), channel/controller resolution, and a hoa/consistency bootstrap layer. Laravel already owns this entire surface through Illuminate\Routing, the HTTP kernel, middleware pipeline, container resolution, and route model binding. Adopting Hoa\Dispatcher means either running two dispatch paths side by side or deliberately stepping outside Laravel's request lifecycle — both are architectural regressions, not enhancements.

Integration feasibility. Low. A technical integration is possible in the narrow sense: register a service provider, instantiate a Hoa\Dispatcher\Basic, and hand it a request. But anything dispatched through it bypasses Laravel middleware, so auth, CSRF, session, throttling, and exception rendering do not apply unless manually re-implemented. That is a security-relevant gap, not a convenience gap. Realistically the only defensible use is as an isolated adapter around a legacy Hoa-based subsystem during a migration.

Technical risk. High, concentrated in dependency health:

• Last release 2017-05-02; roughly seven years without maintenance.
• 12 stars, 0 dependents — no community validation, no downstream projects proving it works on modern PHP.
• The package pulls a chain of equally dormant hoa/* packages (consistency, router, stream, protocol, zformat, event). PHP 8.x compatibility is unverified and historically problematic for this suite (removed E_STRICT, dynamic properties, older type semantics).
• Composer resolution is the sharpest risk: one abandoned transitive dependency can block framework upgrades for the whole application, not just the feature that uses it.
• No security response capability upstream. Any CVE is ours to fix.

Key questions.

1. What specific capability motivated the evaluation — channel-based dispatch, a legacy controller convention, or something Laravel's router plus a small custom resolver cannot do in a day?
2. What PHP version is the target platform, and has a throwaway compatibility spike actually run on it?
3. Is there existing code already written against Hoa\Dispatcher, or is this greenfield? (Greenfield should be an automatic no.)
4. Are we prepared to fork, vendor, and own the full hoa/* dependency chain indefinitely?
5. Does the value survive if the answer to (4) is no?

Integration Approach

Stack fit. Mismatched. Laravel 10/11 target PHP 8.1+/8.2+; Hoa\Dispatcher predates that entirely. Expect Composer platform-constraint conflicts and a need for --ignore-platform-reqs or a fork — both of which undermine reproducible builds. Even where it runs, the idioms clash: Hoa uses its own event/consistency bootstrap, not Laravel's container or facades.

Migration path. Two options, and the recommendation is the first:

1. Rewrite into Laravel primitives (recommended). Map Hoa routes to routes/web.php / routes/api.php, Hoa controllers to invokable or resource controllers, and channel logic to middleware or a dedicated service class. This is typically small, bounded work and eliminates the dependency permanently.
2. Isolated adapter (fallback only). If a legacy subsystem cannot be rewritten on the current timeline, mount it behind a single route group with a prefix (e.g., /legacy/*) and one adapter class that constructs the Hoa dispatcher and translates request/response. No other code may import Hoa\*. Wrap it in a feature flag and a deprecation ticket with an owner and a date.

Compatibility. Assume breakage until proven otherwise. Run a two-day spike on the exact target PHP version: composer require, boot a minimal dispatch case, and confirm no deprecation fatals. Also run composer why-not against the current Laravel constraint to quantify blast radius before committing.

Sequencing.

1. Compatibility spike (1–2 days, timeboxed).
2. Capability gap analysis against native Laravel routing — most "dispatcher" needs collapse to route groups plus middleware.
3. If the gap is real and legacy code exists: adapter isolation behind a flag, with tests at the boundary.
4. Deprecation and rewrite tracked as normal debt, not backlog trivia.
5. Do not sequence this ahead of any framework upgrade; the dependency chain is more likely to block an upgrade than to enable a feature.

Operational Impact

Maintenance. Effectively zero upstream. If adopted, we own the code, the fork, the security patches, and the Composer constraint fights. Plan for a vendored fork in repositories with an internal maintainer named — an unowned fork is a latent outage.

Support. No meaningful community: 12 stars and no dependents means no Stack Overflow corpus, no third-party tutorials, no one else hitting our bugs. Internal support cost is entirely ours, and it is concentrated on whoever last touched the adapter.

Scaling. The dispatch operation itself is cheap; throughput is not the concern. The concerns are: interaction with long-lived workers (Octane/queue workers) where Hoa's static bootstrap state may not reset cleanly between requests, and loss of Laravel's observability — dispatched requests will not appear in standard middleware-based logging, tracing, or timing unless instrumented by hand.

Failure modes.

• Dependency freeze (highest impact): an abandoned transitive package blocks a Laravel or PHP upgrade for the whole application.
• Middleware bypass (highest severity): routes dispatched outside Laravel's pipeline miss auth/CSRF/throttling, creating a silent security hole.
• PHP upgrade fatals: deprecation-to-error conversions break dispatch at runtime, likely in production first.
• Silent behavioral drift: Hoa's routing semantics differ from Laravel's (trailing slashes, parameter binding, method handling), producing bugs that look like application bugs.
• Bus factor: one engineer understands the adapter; when they leave, the subsystem becomes untouchable.

Ramp-up. High relative to the value delivered. The API is non-idiomatic Laravel, documentation is sparse and Hoa-specific, and every engineer who touches it pays a learning tax for a capability Laravel already provides. Onboarding cost is not amortized because the surface is small but the mental model is foreign.

TPM recommendation. Do not adopt. The package scores 2.25 with 0 dependents and no release in seven years — that is a maintenance liability dressed as a library. Approve only a timeboxed spike to confirm the capability gap is real; if it is, close it with native Laravel routing or a small internal service. If legacy code forces an adapter, isolate it behind one boundary, flag it, assign an owner, and schedule its removal.