- What is Stiphle used for?
- Stiphle is a small, framework-agnostic PHP library for throttling and rate limiting. You define limits using interchangeable storage adapters, then check, lock, or queue work so actions stay within your thresholds. It is a low-level utility rather than a full framework feature, so you typically wire it into your own service layer or middleware.
- How do I install Stiphle with Composer?
- Install it as a pinned Composer dependency with composer require davedevelopment/stiphle. Because it is not a Laravel package, expect no auto-discovered service provider or published config file. You will need to instantiate throttles and adapters yourself, ideally inside a service provider or a small adapter class.
- Does Stiphle have a Laravel service provider or middleware?
- No. Stiphle is framework-agnostic and ships without Laravel-specific service providers, configuration, or middleware. The recommended approach is to bind an application-owned interface such as App\Contracts\RateLimiter in a service provider, wrap the Stiphle throttles behind it, and expose Laravel middleware or service methods that call your adapter. This keeps Stiphle classes out of controllers, jobs, and domain code.
- Which storage backends does Stiphle support?
- Stiphle offers interchangeable storage adapters including Redis, Memcache, and an in-memory array store. The in-memory adapter is per-process and does not scale across multiple nodes, so it is best suited to tests or single-process use. For multi-instance deployments you should use a shared Redis or Memcached store and verify TTL and atomicity semantics against your production topology.
- Can Stiphle handle rate limiting across multiple servers or containers?
- It can, but only if you back it with a shared store such as Redis or Memcached rather than the array adapter. Correctness then depends on atomic storage operations, consistent key design, and predictable TTL behavior. Run a spike under concurrency to confirm the adapter does not allow race conditions or false positives before relying on it horizontally.
- What is the difference between check, lock, and queue in Stiphle?
- Stiphle exposes three broad ways to stay within a threshold: check whether an action is still allowed, lock to reserve capacity, and queue work so it runs when capacity becomes available. Check is the lightest option for guarding endpoints, while lock and queue patterns suit jobs or background tasks that must not exceed a limit. Choose based on whether you want to reject, reserve, or defer the work.
- Should I use Stiphle or Laravel's built-in RateLimiter?
- Laravel already ships a native RateLimiter backed by its cache stores, and for most applications that is the lower-risk choice. Stiphle is only justified when it provides a specific algorithm, storage behavior, or legacy compatibility that Laravel's limiter does not cover. Compare your requirements first, and if you adopt Stiphle, keep a rollback path to the built-in limiter.
- Is Stiphle still maintained and which PHP versions does it support?
- The last release was in November 2022, so treat maintenance risk as moderate despite the small code surface. Verify Composer constraints for PHP and any required extensions such as redis or memcached against your target stack. Review dependency health quarterly and be prepared to fork or vendor the library if it is abandoned.
- What happens when the Redis or Memcache store is unavailable?
- Failure behavior depends on the adapter and how you wrap it, so test this explicitly rather than assuming. A cache outage can cause a silent bypass of your limits or, depending on your code, hard failures on throttled endpoints. Decide upfront whether your application should fail open or fail closed, and add logging and alerts around store errors.
- How do I test Stiphle rate limiting in a Laravel app?
- Use the in-memory array adapter in unit tests so limits are deterministic and fast, then add integration tests against a real Redis or Memcached instance for TTL and concurrency behavior. Wrap Stiphle behind your own interface so tests can swap in fakes without touching middleware. Also cover the store-unavailable path, since that is where rate limiting most often fails silently.