Buzz Bundle Laravel Package

Getting Started

Before writing a single line of application code, confirm you actually want to install this: the bundle has zero dependents, and its release history is essentially frozen — the newest tag, 3.1.1, is a one-line "fix function parameter issue" patch, not a revival. It wraps kriswallsmith/buzz, a client library that itself was superseded by Symfony's own HttpClient component and by Guzzle. Treat this section as "how to survive an inherited project," not "how to start a new one."

Minimal install steps, assuming you're stuck maintaining a legacy Symfony app:

composer require simonberger/buzz-bundle:^3.1

Pin to ^3.1 rather than floating — you want the parameter fix, and you do not want an unreviewed minor landing in a legacy app. Then register the bundle using the Symfony version your project targets:

// Symfony 4+/5+ config/bundles.php
return [
    // ...
    SimonBerger\BuzzBundle\SimonBergerBuzzBundle::class => ['all' => true],
];

// Symfony 2/3 AppKernel.php
$bundles = [
    // ...
    new SimonBerger\BuzzBundle\SimonBergerBuzzBundle(),
];

Where to look first: the bundle is tiny — read DependencyInjection/Configuration.php and DependencyInjection/SimonBergerBuzzBundleExtension.php in vendor/. Those two files tell you the entire configuration surface and the service IDs you can inject. The Buzz README (kriswallsmith/buzz) is the real documentation for the API you'll be calling; the bundle is mostly a DI wrapper. If 3.1.1 changed a constructor signature you rely on, the diff between the 3.1.0 and 3.1.1 tags is short enough to read in a minute — do it before you upgrade, since there's no changelog detail beyond the commit subject.

First use case: the canonical one is injecting a configured Buzz\Browser into a service that talks to a downstream HTTP API:

use Buzz\Browser;

class WeatherService
{
    public function __construct(private Browser $browser) {}

    public function current(string $city): string
    {
        return $this->browser->get("https://api.example.com/?q={$city}")->getContent();
    }
}

The service ID to inject depends on the bundle's config schema — check the extension class, since it registers clients under configurable names (commonly buzz.client or buzz.browser).

Implementation Patterns

Configure clients centrally, not in services. The bundle's reason for existing is to let you declare timeouts, base URLs, and listeners once and inject them repeatedly. Keep all wiring in config/packages/simon_berger_buzz.yaml (or config.yml on older Symfony) rather than instantiating Browser ad hoc:

simon_berger_buzz:
    clients:
        weather:
            timeout: 5
            # verify exact keys against Configuration.php — the schema is small
        payments:
            timeout: 10
    default_client: weather

Multiple named clients is the pattern that pays off; a single default client is just a leaky abstraction over new Browser().

Wrap the client behind your own interface. Buzz's API ($browser->get(), ->post(), ->send()) is not what HttpClientInterface looks like, so wrapping it now makes the eventual migration mechanical:

interface DownstreamClient { public function fetch(string $path): string; }

class BuzzDownstreamClient implements DownstreamClient
{
    public function __construct(private Browser $browser, private string $baseUrl) {}

    public function fetch(string $path): string
    {
        return $this->browser->get($this->baseUrl . $path)->getContent();
    }
}

Now swapping in symfony/http-client later is a one-class change — and it also insulates you from any further 3.1.x parameter tweaks.

Use Buzz listeners for cross-cutting concerns. Buzz supports middleware via Buzz\Listener\ListenerInterface (attach with $browser->addListener(...)). Logging, retry, and auth headers belong here rather than in each call site. Register listeners as DI services and attach them to the browser from a compiler pass or an explicit factory — the bundle may or may not do this for you.

Test against the interface, not the browser. Because the injected object is a concrete Browser, mocking in unit tests is painful. Inject an interface, or use Buzz\Browser::setClient() with a fake ClientInterface in tests:

$browser = new Browser(new StubClient($cannedResponse));
$service = new WeatherService($browser);

Compose with Symfony's HTTP abstractions where possible. You can still use PSR-7 requests/responses with Buzz via Buzz\Message\Factory\Factory if your code already speaks PSR-7 — worth doing so the seam with HttpClient stays thin.

Gotchas and Tips

3.1.1 is a bugfix, not a signal to adopt. The release notes are literally "Fix function parameter issue" — a signature correction, most likely a type or default that was wrong in 3.1.0. That is good news for anyone already on 3.1.x (upgrade, run your test suite, done), and it is not evidence of active maintenance, a support policy, or PHP 8.3+/Symfony 7 compatibility work. Don't let a fresh tag on Packagist talk you into a greenfield dependency.

Pin and diff. Because the release has no meaningful changelog, treat the tag-to-tag diff as the changelog. If you call any bundle/buzz methods with positional arguments, check whether the fixed parameter is one you pass — a changed default can silently alter behaviour even though the version bump is patch-level.

Buzz itself is legacy. The kriswallsmith/buzz library was rewritten twice after the API this bundle targets. Browser::get(), Response::getContent(), and the listener system belong to the pre-1.0 era. Code samples you find online may target a different major version than what the bundle pins in its composer.json — check the lock file before copying Stack Overflow answers.

Configuration schema is undocumented. The README and Configuration.php are the only spec. Read Configuration.php — it's a handful of NodeBuilder calls and will tell you exactly which keys are valid (timeout, proxies, clients, etc.). Guessing at YAML keys is the most common first failure; Symfony will silently ignore unknown keys unless ->cannotBeEmpty() or explicit validation is set.

Service IDs can shift between versions. The bundle was authored in the Symfony 2/3 era but released into a Symfony 4/5 world, so alias registration (buzz.client vs. SimonBerger\BuzzBundle\Client\Client) is inconsistent across tags — and a patch release can move a definition without anyone documenting it. Grep Resources/config/services.xml (or services.php) in vendor/ after every bump; don't trust autowiring, because the bundle predates the autowiring-by-type convention.

Debugging HTTP calls is on you. Buzz has no profiler integration. If you're used to Symfony's web profiler showing outgoing requests, you lose that here. Add a listener that logs to the http_client channel, or wrap calls in your own timing decorator, otherwise you'll be var_dump-ing in the terminal.

Error handling is exception-by-convention, not by type. Buzz throws Buzz\Exception\ClientException/ServerException only if you use getClient()->send(); Browser::get() returns a Response for any 4xx/5xx and you have to check getStatusCode() yourself. Enforce a single check path in your wrapper so half your services don't silently swallow 500s.

Extension point: replace the client, not the bundle. If you must keep the dependency for one more release cycle, the cleanest escape hatch is to register your own Buzz\Browser service with the same ID and configure your own listeners. That keeps calling code untouched while you gradually introduce HttpClient behind it, then delete the bundle entry from bundles.php once nothing injects the old ID.

Don't add it to a new project, full stop. For any greenfield code, use Symfony\Component\HttpClient\HttpClient::create() — it ships with the framework, is testable via MockHttpClient, supports retries and concurrency, and will outlive whichever HTTP client library is fashionable this year. A 3.1.1 patch does not change that calculus.