Guzzle Psr18 Adapter Laravel Package

Product Decisions This Supports

• API Standardization: Enables consistent HTTP client usage across Laravel/PHP services, reducing technical debt and improving maintainability. Aligns with PSR-18 adoption for long-term compatibility with modern PHP ecosystems (e.g., Symfony, Laravel 10+).
• Decoupling for Scalability: Facilitates swapping HTTP clients (e.g., Guzzle ↔ Symfony HTTP Client) without refactoring business logic, critical for microservices or serverless architectures.
• Roadmap for Modernization: Supports gradual migration from raw Guzzle to PSR-18 in legacy Laravel monoliths, enabling incremental adoption of PSR standards (e.g., PSR-15 middleware).
• Build vs. Buy: Justifies not building a custom PSR-18 adapter, saving 2–3 dev weeks while leveraging a tested, lightweight solution. Ideal for teams prioritizing core features over HTTP infrastructure.
• Use Cases:
  • Laravel API Clients: Standardize HTTP calls in Laravel services (e.g., Http facade → PSR-18).
  • Third-Party Integrations: Simplify API consumers (e.g., payment gateways, SaaS hooks) with PSR-18 interfaces.
  • Testing: Mock HTTP clients in PHPUnit/Pest tests using PSR-18 interfaces (e.g., Mockery or Laravel Mocks).

When to Consider This Package

• Adopt if:
  • Your Laravel/PHP app uses Guzzle and needs PSR-18 compliance (e.g., for Symfony interop or future-proofing).
  • You prioritize minimal boilerplate (adapter adds ~0 dependencies beyond Guzzle).
  • Your team values interface-based design (e.g., dependency injection, testability).
  • You’re migrating from raw Guzzle to PSR standards without rewriting HTTP logic.
• Look elsewhere if:
  • You’re not using Guzzle (e.g., Laravel’s built-in Http client or Symfony’s HttpClient).
  • Your project requires advanced Guzzle features (e.g., custom middleware, plugins) not exposed via PSR-18.
  • You need active maintenance (last release in 2021; consider forking or alternatives like php-http/guzzle8-adapter).
  • Your stakeholders demand vendor lock-in avoidance (PSR-18 is evolving; evaluate long-term strategy with php-http/client).

How to Pitch It (Stakeholders)

For Executives: "This tiny package lets us standardize how our Laravel services call APIs—cutting bugs and tech debt. It’s like a universal adapter for HTTP calls, so we can switch tools later if needed. Zero risk, big payoff for our API-heavy products like [X] and [Y]."

For Engineering (Laravel Teams): *"We’re using Guzzle everywhere but want PSR-18 for consistency. This adapter wraps Guzzle in 5 minutes, giving us:

• PSR-18 interfaces for easier testing and DI (e.g., mocking HTTP calls in tests).
• Zero Guzzle code changes—just replace Client with Psr18Adapter.
• Future flexibility to swap clients (e.g., for performance or cost). Tradeoff: Last updated in 2021, but it’s a thin layer. We’ll prototype it in [Service Z] first and monitor alternatives."*

For Architects: *"This solves Laravel’s ‘HTTP client sprawl.’ By adopting PSR-18 via this adapter, we:

1. Decouple business logic from Guzzle specifics (e.g., easier to replace with Symfony’s HttpClient).
2. Future-proof against PSR updates (e.g., Laravel 10+ PSR-18 support).
3. Simplify dependency management—one interface for all HTTP calls. Caveat: Not actively maintained, but the surface area is small. We’d fork if needed or switch to php-http/guzzle8-adapter later."*

For PMs: *"This is a low-effort, high-impact way to modernize our HTTP layer. It:

• Reduces risk in API integrations (e.g., payment gateways) by standardizing clients.
• Enables faster hiring—PSR-18 is a known standard for PHP devs.
• Aligns with Laravel’s roadmap (PSR-18 adoption in v10+). Ask: ‘Do we need this now, or can we wait for Laravel’s built-in PSR-18 support?’"*