Http Batch Guzzle Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound HTTP orchestration: Confirms whether to adopt a maintained batching layer over hand-rolled Guzzle promise pools — the new RecordingHttpClient materially lowers the "buy" cost by removing custom test scaffolding.
• Testability as a first-class roadmap criterion: The v3.1.0 spy turns HTTP interaction verification (requests, responses, exceptions, chronological history, batch-level tracking) into a native capability, so features that depend on third-party APIs can be validated in CI without live sandbox credentials.
• Integration-heavy roadmap bets: Supports decisions to pursue features like dashboard data aggregation, multi-provider API fan-out, bulk webhook delivery, and enrichment pipelines — all patterns that require many concurrent outbound calls with observable behavior.
• Reliability and observability investment: The filtering APIs (successful vs. failed requests, per-request tracking within a batch) inform whether to prioritize partial-failure handling and retry/backoff work in the next cycle.
• Use-case validation: Enables product teams to prototype batch API aggregation and measure real concurrency behavior early, before committing engineering capacity.
• Supplier/architecture risk review: ClientInterface compatibility in the new spy signals a stable extension seam, reducing the risk of a future migration away from this package.

When to Consider This Package

Adopt when:

• The product makes multiple concurrent outbound HTTP calls per user action or job (aggregation, fan-out, enrichment).
• The stack is Laravel/PHP on Guzzle, where this package's abstractions map cleanly onto existing clients.
• Test coverage of third-party integrations is a gating requirement — the spy directly addresses that need without bespoke mocks.
• You need batch-level and per-request inspection for debugging production or CI behavior.
• You want to avoid maintaining in-house promise-batching and recording utilities.

Look elsewhere when:

• The product issues only single, isolated HTTP requests — batching adds indirection with no payoff.
• The team standardizes exclusively on Laravel's Http facade and does not touch Guzzle primitives.
• You require a pure PSR-18 client without Guzzle coupling.
• Outbound work is better modeled as queued jobs with retry semantics rather than synchronous batches.
• You are unwilling to depend on a smaller community-maintained package for critical integration paths (mitigate with an internal adapter over ClientInterface).

How to Pitch It (Stakeholders)

For executives: This release adds a testing spy to a package we would otherwise have to replicate in-house. It means integration-dependent features — dashboards, third-party data aggregation, bulk notifications — can be built and verified faster, with fewer production surprises and less custom test infrastructure to maintain. Net effect: shorter time-to-market on integration-heavy roadmap items and lower ongoing engineering overhead, with no breaking changes from v3.0.0.

For engineering: v3.1.0 introduces RecordingHttpClient, a drop-in ClientInterface implementation that records requests, responses, and exceptions for both single and batched calls, with filtering and chronological inspection APIs. It is fully backward-compatible with existing clients, so adoption is additive. Use it to write deterministic tests asserting exact outbound payloads and partial-failure behavior inside batches — replacing ad-hoc mocks and sandbox dependencies. Recommended rollout: introduce the spy into the integration test suite first, then standardize on this package wherever concurrent HTTP fan-out is required, keeping an internal adapter over ClientInterface to preserve optionality.