Rest Process Bundle Laravel Package

Technical Evaluation

Architecture fit The critical finding for a TPM: this is a Symfony bundle, not a Laravel package. The integration surface is a Bundle class, a DI extension, and a compiler pass that collects Client services into a ClientRegistry keyed by client code; the functional unit is a RequestTask that performs HTTP calls and validates them against a valid_response_code list. That entire contract is expressed in Symfony's container lifecycle. Laravel never boots bundles, never runs that compiler pass, and will ignore the bundle's services.yaml. So there is no "install and go" path — the bundle layer is the thing we would be replacing, not consuming.

What is potentially reusable is the framework-agnostic core: Client, ClientRegistry, RequestTask, MissingClientException. In practice that core is a named-HTTP-client registry plus a response-code validator. Laravel already provides the first half (the Http facade with named clients / macros) and the second half is roughly ten lines of policy code. A TPM should frame this honestly: the package's real value is inseparable from cleverage/process-bundle, and if we are not adopting ProcessBundle, we are buying a registry we could write ourselves.

Integration feasibility Feasible only as a manual re-bind: pull symfony/http-client, instantiate ClientRegistry and Client objects inside a Laravel service provider, and call RequestTask directly. That introduces a second HTTP stack alongside Guzzle (Laravel's default), two sets of middleware, two retry/circuit-breaker idioms, and two observability surfaces. The bundle's explicit service definitions (no autowiring, cleverage_rest_process-prefixed aliases) are good Symfony hygiene but transfer zero value to a Laravel container.

Technical risk

• Evidence of adoption is nil: 0 stars, 0 dependents. We would be the only known external consumer. That is not disqualifying — the README, docs/, changelog and tagged releases show a disciplined internal project — but it means no community fallback, no third-party tutorials, no Stack Overflow answer when something breaks.
• High-velocity BC churn: v2.0 replaced nategood/httpful with symfony/http-client, renamed services, deprecated query_parameters in favour of data, and removed RequestTransformer. v3.0 dropped PHP 8.1 / Symfony 7.3 while adding PHP 8.5 / Symfony 8 support. Deprecations land in minor releases (geUri() → getUri()). If we vendor or fork, we inherit that cadence.
• Semantics are subtle by design: valid_response_code entries for 3xx/4xx/5xx return the body but the task still fails (#35). That distinction is easy to misread and easy to build on incorrectly.

Key questions

1. Are we actually adopting cleverage/process-bundle, or is the pipeline abstraction hypothetical? If hypothetical, this package is the wrong entry point.
2. Does our orchestration need a declarative client registry, or just two or three named outbound integrations?
3. Who owns the fork/re-bind if CleverAge stops maintaining it — and what is the exit cost if we have to reimplement in 12 months?
4. Do we want two HTTP stacks in one application, and who signs off on the resulting debugging complexity?

Integration Approach

Stack fit Laravel 10/11/12 on PHP 8.2+ is the target envelope. The published support matrix is narrow and moving — v2.3 moved to Symfony 7.3 / PHP 8.4, v3.0 dropped PHP 8.1 and Symfony 7.3 while adding PHP 8.5 / Symfony 8. Before any commitment, pin a version and verify it against the PHP runtime we actually deploy, because the project tracks latest stable and LTS explicitly and does not carry long tails.

Migration path Three options, in ascending cost:

1. Don't adopt (recommended default). Implement named clients with Http::withOptions() / macros, and encode valid_response_code expectations as a small explicit policy in the call site or a job middleware. Zero new dependencies, one HTTP stack, full Laravel observability.
2. Selective re-bind. Depend on symfony/http-client plus the package's core classes, register ClientRegistry in a service provider, and treat RequestTask as an internal service. Only justified if we specifically want their response-validation semantics and the duplicate-client-code diagnostics.
3. Adopt ProcessBundle wholesale. A platform decision, not a package decision. Out of scope for a TPM-level evaluation and should be assessed as its own initiative.

Compatibility Expect no Laravel package discovery, no publishable config, no facade, no queue integration. Everything is manual wiring. The classes must be verified as container-agnostic (no ContainerInterface leaks) before option 2 is credible — that is the single spike that de-risks the decision.

Sequencing (a) Two-day spike: boot ClientRegistry + RequestTask in a Laravel service provider, drive one real third-party API through it, and compare the resulting code and log output against the Laravel-native equivalent. (b) If the delta is not material, stop and take option 1. (c) If it is, document the wiring as an internal adapter so the rest of the codebase depends on our interface, not theirs — that isolates us from the churn documented above. (d) Only then evaluate ProcessBundle itself.

Operational Impact

Maintenance Single-vendor project (CleverAge, a French agency), effectively maintained for their own ProcessBundle consumers. The health signals are genuine — docs, changelog, tagged releases, and v3.2 added tests for RequestTask, Client against a mocked HTTP client, MissingClientException, and the DI extension. But bus factor and roadmap are external and unnegotiable. If our fork diverges, we own every future Symfony/PHP bump.

Support GitHub issues only. No SLA, no vendor contract, no commercial backstop. Our on-call runbook cannot say "raise a ticket" — it has to say "we patch it." Budget for that explicitly, even if the estimate is small.

Scaling The HTTP work itself is I/O-bound and symfony/http-client handles it; the ClientRegistry is per-process and cheap. Real scaling is a queue/worker concern (Horizon, concurrency limits, timeouts, backoff) that this package does not address — it executes a call, it does not manage load. Do not let "it has a client registry" be mistaken for throughput capability.

Failure modes to instrument from day one

• Transport errors — historically logged then lost; fixed in #36, so verify the version we run actually contains the fix.
• Non-2xx listed in valid_response_code — body returned, task still fails (#35). Any downstream consumer expecting an empty body must be updated.
• Duplicate client codes — now names both service IDs (#33), which is the fastest signal of misconfiguration.
• MissingClientException — an unregistered code failing at runtime, not at boot. Validate at deploy time.
• Non-array input to RequestTask now throws UnexpectedValueException (#38); anything that previously swallowed a TypeError will start failing loudly.

Ramp-up The API surface is small — a mid-level engineer can read it in a day — but only if they already understand the task/pipeline abstraction it belongs to. Without ProcessBundle context, most of the reading is dead weight, and the subtlety that costs real time is valid_response_code (expected failure vs. success). Plan for: half a day of docs, half a day of the spike in Integration Approach, and a written internal note on the failure semantics before anyone builds on it.