Guzzle Bundle Laravel Package

Getting Started

Install the bundle with Composer (this predates Symfony Flex, so expect manual registration):

composer require playbloom/guzzle-bundle

Register it in app/AppKernel.php (Symfony 2/3 era) — and only in dev/test environments unless you actually want the overhead in prod:

// app/AppKernel.php
if (in_array($this->getEnvironment(), ['dev', 'test'])) {
    $bundles[] = new Playbloom\Bundle\GuzzleBundle\PlaybloomGuzzleBundle();
}

The first place to look is the bundle's DependencyInjection/Configuration.php and the Resources/config/ folder — the docs are thin, and the config tree is the real API. Define a client:

# app/config/config.yml
playbloom_guzzle:
    clients:
        github:
            base_url: "https://api.github.com"
            timeout: 5

That gives you a service named playbloom_guzzle.client.github. Your first useful use case: call it from a controller, then open the "Guzzle" panel in the web profiler to see the request/response, timing, headers, and status — this is the entire value proposition of the package.

Implementation Patterns

Inject named clients by service ID. There is no autowiring; reference playbloom_guzzle.client.<name> in your service definitions or controller get() calls. Wrap it in a thin gateway class per external API rather than injecting the raw Guzzle client into many services.

One client per upstream service. Configure base_url, default headers (auth, Accept), and timeouts per client. This keeps credentials out of code and makes the profiler panel readable — you will see which upstream a slow request hit just from the client label.

Middleware for cross-cutting concerns. Attach Guzzle middleware (logging, retry, circuit breaking) to a specific client from a compiler pass or a factory service. Keep the bundle config declarative and push logic into a small factory if the YAML gets unwieldy.

Profiler as debugging workflow. The typical loop: reproduce the slow/failing behavior in dev, open the profiler, inspect the Guzzle panel, check the request body and response headers, then fix the caller. This is much faster than dumping responses in the controller by hand.

Test with a mock handler. Because the bundle just wires Guzzle, swap in GuzzleHttp\Handler\MockHandler in test service definitions to assert your service makes the right requests without hitting the network. The bundle itself doesn't provide testing helpers, so do this at the DI level.

Custom clients. For anything the YAML config cannot express (complex handler stacks, signed-request middleware), define the client as a service and rely on Guzzle directly — the bundle's only real addition is the profiler hookup, so nothing is lost.

Gotchas and Tips

This package is effectively legacy. It was built for the Symfony 2 / early Symfony 3 era and Guzzle 3/5. Modern Guzzle (7.x) and Symfony 4+ with Flex use completely different wiring (no AppKernel, PSR-18/HttpClientInterface). Treat it as a reference for how to profile Guzzle in an old app, not something to introduce into a new project.

Version pinning is essential. The bundle historically pinned Guzzle major versions tightly. Run composer why playbloom/guzzle-bundle and inspect the resolved Guzzle version before upgrading anything — a seemingly harmless Guzzle bump can break the middleware the profiler relies on.

Profiler overhead is real. The data collector wraps every client and stores request/response data. Keep the bundle out of prod, or explicitly disable the profiler integration if it is loaded there. Large response bodies captured by the collector can bloat the profiler store.

Sensitive data in the profiler. Request and response bodies are captured verbatim. If you use this against APIs with tokens in headers or PII in payloads, add scrubbing middleware or restrict the profiler to trusted environments.

Debugging when the panel is missing. Usually the collector isn't registered (bundle disabled, or profiler disabled), or the client wasn't created via the bundle's service ID. If you instantiate new GuzzleHttp\Client() in a service, the profiler will never see it — always resolve clients from the container.

Extension points are limited. There is no rich event system — the collector hooks Guzzle's own middleware stack. For custom behavior (tagging requests, redacting fields), write a Guzzle middleware and register it on the client; that is the intended extension path.

Migration advice. On modern stacks, use Symfony's HttpClient (which has a first-class profiler panel) or, if you must stay on Guzzle, adapt it via symfony/http-client + psr18 bridging so its requests show up in the built-in profiler. That gives you the same debugging experience without the abandoned bundle.