- Is eightpoints/guzzle-bundle compatible with Laravel?
- No. Despite being installed via Composer, this is a Symfony bundle that depends on the Symfony kernel, DI container, and configuration component, so it cannot be used inside a Laravel application. Laravel already ships its own HTTP client through Illuminate\Http\Client and the Http facade, which covers the same use cases with retries, logging, and fakes built in. Treat this package as Symfony-ecosystem-only when evaluating it.
- How do I install EightPoints GuzzleBundle in a Symfony application?
- Run composer require eightpoints/guzzle-bundle. If your project uses Symfony Flex, the recipe registers the bundle in config/bundles.php and creates config/packages/eight_points_guzzle.yaml for you. Without Flex you must add EightPoints\Bundle\GuzzleBundle\EightPointsGuzzleBundle::class => ['all' => true] to config/bundles.php manually. After that, most of the remaining work is YAML configuration rather than PHP code.
- How do I configure multiple named Guzzle clients in YAML?
- You declare each client under the eight_points_guzzle.clients key in config/packages/eight_points_guzzle.yaml, giving it a name and its Guzzle options such as base_uri, timeout, headers, and auth. Each entry becomes a container service with the id eight_points_guzzle.client.<name>, and services are registered lazily so unused clients are not instantiated. This is the main value of the bundle: centralising several third-party API clients instead of building GuzzleHttp\Client objects ad hoc in services.
- How do I inject or autowire an EightPoints Guzzle client into a service?
- The simplest approach is to inject by service id, for example eight_points_guzzle.client.crm, or to alias that service to a neutral name such as crm.client in services.yaml. Autowiring named clients requires following the bundle's dedicated documentation, since the underlying services share the GuzzleHttp\Client type. Manual wiring always works but is more verbose, and aliasing to plain GuzzleHttp\ClientInterface keeps your code decoupled from the bundle.
- Which PHP and Symfony versions does EightPoints GuzzleBundle support?
- The bundle requires PHP 7.2 or higher and supports Symfony 5.x, 6.x, 7.x, and 8.x, with version 8.6.0 adding Symfony 8 support. It integrates Guzzle 6.x and 7.x only, and no Guzzle 8 support path is currently stated. Check that your PHP version sits inside the actually tested matrix rather than merely satisfying the constraint.
- How do I add retry, logging, or caching plugins to a Guzzle client?
- Plugins are registered per client in the YAML configuration or through the bundle's plugin registry, and common ones include retry, logging, caching, WSSE, OAuth2, and header forwarding. Many of these plugins live in separate third-party repositories by different authors with their own release cycles, so your real dependency surface is larger than the single composer line. Verify each plugin is released for your Symfony version before relying on it.
- Does the GuzzleBundle dispatch events around HTTP requests?
- Yes. The bundle fires pre-transaction and post-transaction Symfony events that let you inspect or mutate requests and responses, which is useful for adding correlation IDs, custom headers, or metrics. Because listeners can change requests at runtime, behaviour can shift without any code review touching the calling service. Keep listener logic small, explicit, and covered by tests.
- How do I mock or test services that consume bundle-defined clients?
- The bundle produces ordinary GuzzleHttp\Client instances, so you can inject a client built with Guzzle's MockHandler and a handler stack in your tests. Typing your consumers against GuzzleHttp\ClientInterface rather than a concrete bundle service makes swapping in mocks or stubs straightforward. For integration tests, point the configured base_uri at a local stub server instead of the real API.
- What production risks should I watch for with this bundle?
- Most incidents come from configuration rather than code: retry counts, timeouts, and event listeners that mutate requests can cause retry storms or silent failures that code review will not catch. The profiler and logging integration should be disabled or reduced per environment to avoid overhead on hot paths. Also confirm whether your usage involves Guzzle pools or promises, since the event system is primarily built around sequential calls.
- Is EightPoints GuzzleBundle actively maintained, and what is the fallback if it stalls?
- The project is MIT licensed with a small contributor base and stewardship effectively led by one or two recurring committers, so bus factor is the main concern. Support is community-driven via Slack with no commercial backing, though Symfony 5 through 8 support indicates active upkeep. The escape hatch is clean: keep consumers typed against GuzzleHttp\ClientInterface, alias services to neutral names, and you can drop to raw Guzzle or your own PSR-18 client factory at any time.