- How do I install and set up laravel-guzzle-throttle in a Laravel app?
- Install it with composer require hamburgscleanest/laravel-guzzle-throttle; the service provider is auto-discovered. Publish the config file with php artisan vendor:publish and declare your per-host or per-route rate rules there. Then attach the Guzzle middleware from the upstream hamburgscleanest/guzzle-advanced-throttle package to your client's handler stack. Because the package's composer constraints may predate your Laravel version, run composer require --dry-run first to confirm it resolves.
- Which Laravel, PHP, and Guzzle versions does this package support?
- You should treat the supported matrix as unverified until you check composer.json yourself, since the constraints likely predate current Laravel 10-12 and Guzzle 7 releases. The Guzzle 6 to 7 transition changed the handler stack API, and Laravel 9 through 12 changed container and cache contracts, so allowed versions are not the same as tested versions. Run a dry-run install against your actual Laravel and PHP versions before assuming viability.
- Does this package work with Laravel's Http facade?
- Not automatically. Older Laravel versions do not expose the underlying Guzzle handler stack through the Http facade, so you need a custom client binding or a direct Guzzle client. On Laravel 10 and newer you can pass a handler via Http::globalOptions, but otherwise you may have to bypass the facade entirely. Plan for that wiring work before you commit to the package.
- Which cache driver should I use for the throttle counters?
- Use a shared, atomic store such as Redis or Memcached. The array and file drivers give you per-process limits, which are wrong under any concurrency or multi-node deployment because each worker keeps its own counter. Also confirm that the package's counter increment is genuinely atomic; a read-then-write race will silently over-permit requests.
- What happens when the rate limit is reached?
- The middleware typically blocks or sleeps until a slot becomes available, which means it holds a PHP-FPM or queue worker for the duration of the wait. Under bursty load that turns a rate-limit problem into a worker-starvation problem, so check whether blocking, throwing, or dropping is configurable. If blocking is the only option, keep limits generous enough that waits stay short.
- Will third-party SDKs that create their own Guzzle client be throttled?
- No, not unless the SDK accepts an injected handler or client. Any payment, CRM, or LLM SDK that constructs its own Guzzle client bypasses the middleware entirely. This is the biggest scope gap to validate: inventory which outbound integrations you can actually wire the handler into before adopting the package.
- Where should the throttle middleware sit relative to retry middleware?
- The throttle must sit below the retry middleware and above the handler in the stack. If you get the order backwards, retries either double-count tokens against the limit or bypass the throttle completely. Test the ordering explicitly against a mock upstream that returns 429 responses, including any concurrent or async request pools.
- Is laravel-guzzle-throttle production-ready and actively maintained?
- Adoption signal is effectively nil, so treat it as unvetted code with no community review or downstream battle-testing. It has a single-maintainer bus factor and a real chance of being dormant. Check the last commit date, open-issue ratio, license, and whether the upstream throttle library itself is still maintained before putting it in a critical path.
- Does the package expose metrics or events for observability?
- Observability is not a documented strength here, so assume you will need to add your own logging around 429 responses and wait times. Ask the maintainer whether any events or metrics hooks exist for per-host saturation. If not, wrap the middleware or the client so you can record throttle hits and latency in your existing monitoring.
- What are the alternatives if I do not want to depend on this wrapper?
- You can use the upstream hamburgscleanest/guzzle-advanced-throttle package directly, write a small custom Guzzle middleware backed by Laravel's RateLimiter facade and a Redis store, or centralize limits in your own outbound HTTP client binding. Given the low adoption, a bounded spike behind an internal outbound rate limiter interface is safer than an org-wide rollout. If the package is dormant, forking the upstream throttle library is a reasonable path, but confirm the license and maintenance posture first.