kami/request-processor
A Laravel package for handling incoming HTTP requests through a structured processing pipeline, helping you validate, transform, and act on request data cleanly while keeping controllers lean and reusable.
kami/request-processor is a single-purpose PHP component that abstracts request handling into a processor/pipeline construct — a chain of discrete steps applied to an inbound request before a response is produced. In Laravel terms this overlaps heavily with what the framework already gives you: HTTP middleware, form requests, Illuminate\Pipeline, and queued jobs. The architectural question is therefore not "does this fit?" but "what does it buy us that the framework does not already provide for free?"
What changed in 1.0. A new release was published and tagged 1.0. That is the entire substance of it: the release notes read "Request processor," which is a restatement of the package name, not a changelog. No breaking-change list, no migration note, no compatibility matrix, no linked diff, no acknowledgement of the three-and-a-half-year gap since the previous release. We have no data describing what is actually in the tag beyond its existence.
Two things follow, and they point in opposite directions. The maintainer is not gone — someone is holding the keys and cutting tags, which is a genuine, if weak, improvement over the "functionally dormant" read in the prior assessment. And release hygiene is poor in a way that is now documented rather than inferred: a project that ships a major version with a three-word release note is telling you how it will communicate the next breaking change. A version number is a claim about stability; it has to be backed by a changelog to be worth anything.
Architecture fit. Unchanged. The pattern is a reasonable one for flows that outgrow a controller method but do not justify a full command bus — multi-stage validation, authorization, enrichment, side effects, and response shaping. Where our services already lean on Laravel middleware and Illuminate\Pipeline\Pipeline, adopting a parallel processor abstraction creates a second, competing mental model for "things that happen to a request." That is the primary architectural cost: conceptual duplication. Fit is strongest in a bounded context where request orchestration is genuinely bespoke and currently smeared across controllers, jobs, and observers. Nothing in the 1.0 tag changes this either way, because we do not know what the tag contains.
Integration feasibility. The surface area is small — a composer dependency, presumably a service provider and a config file, and an interface to implement. A spike is measured in hours, not days. Because it is a library rather than a framework, the integration is reversible if we wrap it behind our own port from the start. Feasibility remains high; desirability remains the open question, and 1.0 does not answer it.
Technical risk. The abandonment risk has softened from "certain" to "demonstrated but uneven." A tag exists; a maintainer exists; there is still exactly one star, zero dependents, no ecosystem validation, no downstream bug reports to learn from, no observable security advisory pipeline, and no evidence of CI, static analysis, or meaningful test coverage from the outside. The 1.0 tag introduces a new, distinct risk that the previous assessment could not have named: unearned maturity signaling. A 1.0 badge causes engineers and procurement checklists to assume semver discipline, BC guarantees, and a stable API. On a project with one release note and no changelog, those assumptions are unfounded. If the prior line was 0.x, then by semver convention 1.0 is permitted to contain breaking changes — and we have no diff, no notes, and no upgrade path to tell us whether it does. We also do not know whether the illuminate/* and PHP constraints were refreshed against a modern stack or simply re-tagged; a version bump is not a compatibility story.
Key questions to answer before any code is written:
1.0 against the last known release commit. If the diff is a composer.json constraint bump and a CHANGELOG.md stub, that is the answer to this entire evaluation.illuminate/* and PHP version constraints raised, or left at 2021-era values? This is the single highest-value fact in the diff.illuminate range.Verdict. Unchanged: evaluate as a reference implementation, not as a dependency. The 1.0 tag is evidence that a person exists, not evidence that the artifact is supported. Take the pattern; the changelog gap is the reason to be more confident in that call, not less.
Stack fit. Assume Laravel/PHP. The component sits either at the HTTP kernel boundary (processor invoked from a route or middleware) or in the service layer (processor invoked from a controller/action). The lower-risk placement is the service layer behind an application-owned interface, so the package never touches routing or the kernel and can be removed without a rewrite.
Migration path. Do not take a floating Packagist constraint, and do not treat ^1.0 as a safe range on a project with one changelog-free release. Three viable paths, in order of preference:
Illuminate\Pipeline. The 1.0 release notes gave us no reason to believe the package contains non-obvious value, so the prior assessment's default holds and strengthens: reimplementation in one to three engineer-days is cheaper than indefinite fork maintenance and produces code the team actually understands.app/Support/RequestProcessing or an internal packages/ directory, drop the composer constraint, and pin it to our PHP/Laravel matrix. This removes the supply-chain risk entirely and turns the question into ordinary internal code ownership. It also sidesteps the fact that no upstream will ever tell us what changed.1.0 by commit SHA. Acceptable only as a time-boxed spike artifact. Never a range, never dev-main, and never without the diff review below.Compatibility. Pin the PHP constraint explicitly, run composer why-not kami/request-processor <target-laravel-version> against the current stack, and add the package to a throwaway branch for a boot test — service provider registration, dispatch of a trivial processor, and one integration test. If it will not install cleanly, that closes the evaluation regardless of the version number. Note that a 1.0 tag does not constitute a compatibility claim; only the boot test does.
Sequencing.
1.0 against the last known release commit. Read the changed lines, not the release notes. Confirm whether constraints moved and whether the public contract shifted (0.5 day, and it may end the evaluation on its own).RequestProcessor port and an adapter implementing it over whichever implementation we choose (1 day).The port is still the whole strategy. It converts a buy-vs-build decision into a reversible one, and it is what makes a single uninformative release tag a footnote rather than a bet.
Maintenance. From the moment it enters the codebase, we own it. One release after a three-and-a-half-year silence does not establish a cadence — it establishes that the repo is not archived. Plan for no further releases. That means every Laravel major upgrade becomes our patch, every PHP minor bump risks deprecations we must fix, and every CVE in a transitive dependency is ours to triage. Fork-and-vendor makes this explicit and budgetable; a Packagist dependency hides it until it bites. Realistic ongoing cost for a small component: a few hours per Laravel major, plus an unbounded tail if the package reaches into framework internals. Add one new line item: because there is no changelog, every upstream release — however rare — costs a full source diff to evaluate. Release hygiene is a maintenance tax we pay whether or not the maintainer ships.
Support. There is no vendor, no SLA, no paid tier, and no community to lean on — one star and zero dependents means the issue tracker is not a support channel, it is a void. A 1.0 tag does not create a support relationship; it creates the appearance of one, which is worse, because it invites engineers to file issues and wait. Internal documentation must be written by us, and the fork becomes the canonical source of truth. Onboarding new engineers means reading our fork, not a README they can find. Brief the team explicitly that the version number carries no support commitment.
Scaling. The package itself is not a scaling concern — it is in-process orchestration and adds roughly object-graph overhead per request. Scaling behavior is entirely a function of what the processors do. Two things to watch: whether processing is synchronous within the request (adds latency linearly with chain length, and one slow step stalls the response), and whether the processor abstraction encourages I/O inside request scope that should have been queued. If the design makes it easy to accidentally run five sequential HTTP calls per request, that is a scaling trap dressed as good architecture.
Failure modes.
1.0 badge causes reviewers to approve an upgrade without reading the diff, and causes ^1.0 to be written into composer.json where a SHA pin belonged. The version number does more damage than the code.Ramp-up. The API surface is small, so day-one productivity is high and the learning curve is shallow — that remains the package's strongest attribute. The real ramp-up cost is organizational, not technical: the team must internalize a bespoke request-processing model that duplicates framework primitives they already know, and must accept that the internal fork, not public documentation, is the reference. The 1.0 tag adds a short but important orientation note: engineers arriving from any other ecosystem will read 1.0 as "mature and supported," and someone has to tell them it is not. Budget a short internal write-up and one design review to prevent the abstraction from spreading into areas where middleware or a job would do.
Bottom line. A 1.0 tag with a three-word release note is not a maturity signal, it is an absence of one. Single maintainer, no changelog, no dependents, and a multi-year gap remain the defining facts. Take the pattern, not the dependency — and if the diff review turns up refreshed constraints and nothing else, skip even the spike.
How can I help you explore Laravel packages today?