Buzz Bundle Laravel Package

Getting Started

Read this first: gremo/buzz-bundle is a Symfony bundle, not a Laravel package. It has no service provider, no facade, no config/*.php file, and no Laravel auto-discovery. Last release was 2015-08-31, the repo is archived, and it targets Symfony 2.x/3.x and PHP 5.3–7.x. On a modern Laravel app (Symfony 6/7 components, PHP 8.1+) composer require gremo/buzz-bundle will fail on constraints, and even if forced it pulls in kriswallsmith/buzz 0.x, which is abandoned and superseded.

So "getting started" realistically means one of two things:

1. You inherited a Symfony app that already uses it. Then start at:

   • README.md — the canonical gremo_buzz: YAML keys (client, timeout, proxy, ignore_errors, max_redirects).
   • DependencyInjection/Configuration.php — the actual config schema; trust this over the README.
   • Resources/config/services.xml — the service IDs you'll inject (buzz, likely buzz.client / buzz.browser).
   • DependencyInjection/GremoBuzzExtension.php — how config maps onto Buzz\Client\Curl setters.

2. You're a Laravel dev evaluating it. Don't install it. Take the idea — a single, pre-configured HTTP client injected everywhere instead of ad-hoc file_get_contents/curl_exec — and implement it with Laravel's built-in HTTP client, which is Guzzle-backed and already global:

// app/Providers/AppServiceProvider.php
use Illuminate\Support\Facades\Http;

Http::macro('api', fn () => Http::baseUrl(config('services.api.url'))
    ->timeout(10)
    ->retry(2, 200)
    ->acceptJson());

First use case either way is identical: replace scattered raw HTTP calls with one configured client, so timeout/redirect/error semantics are consistent across the codebase.

Implementation Patterns

The two-tier pattern (the bundle's actual value)

The bundle's design separates Browser (convenience layer: builds requests, parses status/headers/content) from Client (transport: curl vs file_get_contents). Day to day you almost always inject the Browser:

// Symfony: inject the browser, not a raw curl handle
use Buzz\Browser;

final class PriceFetcher
{
    public function __construct(private Browser $buzz) {}

    public function fetch(string $sku): array
    {
        $response = $this->buzz->get("https://api.example.com/prices/{$sku}");

        if (!$response->isSuccessful()) {
            throw new \RuntimeException("Upstream {$response->getStatusCode()}");
        }

        return json_decode($response->getContent(), true, flags: JSON_THROW_ON_ERROR);
    }
}

Reach for buzz.client (the Buzz\Client\ClientInterface) only when you need to bypass request-building — streaming, odd verbs, or setting raw curl options.

Config-driven defaults

Everything that should be uniform goes in config, not in call sites:

# config/packages/gremo_buzz.yaml  (verify keys against Configuration.php)
gremo_buzz:
    client:
        timeout: 10
        max_redirects: 5
        ignore_errors: false
        verify_peer: true
        proxy: ~          # set in staging only

Then per-environment overrides: ignore_errors: true in dev (so a 500 doesn't blow up a page render), false in prod (so failures are loud).

Response handling conventions

Buzz 0.x responses are not PSR-7. There is no ->json(), no ->throw(). Build tiny helpers and use them everywhere:

private function decode(Buzz\Message\Response $r): array
{
    $type = $r->getHeader('Content-Type') ?? '';
    if (!str_contains($type, 'json')) {
        throw new UnexpectedValueException("Expected JSON, got {$type}");
    }
    return json_decode($r->getContent(), true, flags: JSON_THROW_ON_ERROR);
}

For writes, Buzz has no body abstraction, so set the header yourself:

$this->buzz->post($url, ['Content-Type: application/json'], json_encode($payload));

Laravel translation of each pattern

Testing

In Symfony, the clean move is to redefine buzz / buzz.client in config/services_test.yaml with a stub implementing Buzz\Client\ClientInterface, so tests never hit the network. In Laravel this is a one-liner (Http::fake()), which is one of the strongest reasons not to port the bundle's approach.

Http::fake(['api.example.com/*' => Http::response(['price' => 9.99], 200)]);

Concurrency

Buzz 0.x has no pool/async story — parallel calls mean curl multi-handle code you write yourself. Laravel: Http::pool(fn ($pool) => [...]). If a workload is I/O-bound across many endpoints, this alone justifies the migration.

Gotchas and Tips

Installation will fight you. The bundle's composer.json constrains Symfony 2/3 and Buzz 0.x. Laravel 9+ ships Symfony 6/7 contracts; the solver will refuse, and --ignore-platform-reqs / -W will produce a dependency soup. Don't spend an afternoon on it — the cost/benefit is negative for 7 stars, 0 dependents, and an archived repo.

Buzz\Client\ClientInterface collides with Guzzle's. Both Guzzle and Buzz define ClientInterface; if you bridge the two, alias your imports (use Buzz\Client\ClientInterface as BuzzClient;) or you'll get confusing type errors in DI autowiring.

No PSR-18, no middleware ecosystem. Retries, circuit breakers, logging, caching, and auth-refresh all have to be hand-rolled as decorators around the client. Guzzle/Laravel give you these for free. If you're inheriting a Buzz codebase, budget for that work rather than assuming it exists.

ignore_errors is inverted from what you'd expect. With it false, 4xx/5xx throw; with true, they return a Response you must inspect. Half the bugs in a Buzz codebase are a missing status check because someone assumed errors surfaced automatically.

Per-request tuning headers are a spoofing vector. Buzz 0.x lets callers override behavior (redirect limit, error handling) via special headers. If you forward user-supplied headers into Buzz, sanitize them — otherwise a client can disable your redirect cap and get your server to follow arbitrary hops (SSRF-adjacent).

Timeout semantics differ by client. Buzz\Client\Curl's timeout is the total transfer timeout; connect timeout is separate and often not exposed by the bundle config, so a dead host can hang far longer than timeout suggests. Set it explicitly via setOption(CURLOPT_CONNECTTIMEOUT, ...) on the client service, or you'll see p99 latency spikes that don't match your config.

TLS/proxy failures are the #1 breakage. cURL error 60 in CI or on a corporate network means CA bundle or proxy misconfiguration, not a code bug. Verify with curl -v on the same host first; only disable verify_peer in dev, and never commit that config.

Debugging: log at the transport boundary. Wrap the client (decorate buzz.client in Symfony) and log method + full URL + status + elapsed ms. Response bodies are the second thing to add and only behind a flag — they're often huge and sometimes contain PII.

Extension points are thin. The bundle wires a client and a browser into the container; that's essentially it. There is no event dispatcher or listener tag to hook (Buzz 0.x has no events, and the bundle doesn't add a meaningful layer). Your extension points are: (a) the config file, (b) decorating the client service, (c) subclassing the browser. Verify against Resources/config/ before designing around any hook — don't trust blog posts from 2014.

Migration recommendation for Laravel. Treat this package as documentation, not a dependency. Port call sites to Http:: incrementally: introduce a Http::macro per upstream service, replace one caller at a time, and add Http::fake() tests as you go. Legacy Symfony code that genuinely needs Buzz can run behind a queue or sidecar rather than dragging the bundle into a Laravel composer.json.