Download the PHP package imliam/laravel-throttle-simultaneous-requests without Composer
On this page you can find all versions of the php package imliam/laravel-throttle-simultaneous-requests. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download imliam/laravel-throttle-simultaneous-requests
More information about imliam/laravel-throttle-simultaneous-requests
Files in imliam/laravel-throttle-simultaneous-requests
Package laravel-throttle-simultaneous-requests
Short Description Throttle the current user's requests based on how many requests are currently being executed.
License MIT
Homepage https://github.com/imliam/laravel-throttle-simultaneous-requests
Informations about the package laravel-throttle-simultaneous-requests
Laravel Throttle Simultaneous Requests Middleware
Throttle the current user's requests based on how many requests are currently being executed, in case any are time consuming before giving a response.
This helps when some endpoints are more resource-intensive than others, and stops users from retrying requests that may not have even completed yet.
This forces users of your API to interact in a different way by queuing their requests appropriately instead of spamming until they reach the request limit.
When performing an action only the current user can perform, this also helps to ensure that the endpoint has a form of idempotency and any side effects can only occur once until a subsequent request is made.
- Laravel Throttle Simultaneous Requests Middleware
- Installation
- Usage
- Why not use queues?
- Why is no
Retry-After
header sent?
- Testing
- Changelog
- Contributing
- Security
- Credits
- License
Installation
You can install the package with Composer using the following command:
Once installed to your project, add the middleware to your App\Http\Kernel::$routeMiddleware
array.
Usage
You can use the middleware like any other. For example, to limit a particular endpoint to only 3 concurrent requests by the same user:
Why not use queues?
Queues have their place to defer time consuming tasks to a later date, however they are not always the most appropriate solution for a task. A given task could require use of limited hardware resources, or require some other kind of processing that does not make sense to run concurrently.
See how Stripe use concurrent request limiters...
Why is no Retry-After
header sent?
Most typical rate limiting solutions limit a user to a number of requests within a set time period, such as 100 requests per minute, so include a Retry-After
header to let the requestor know when they are available to try again.
This middleware does not add such a header to the response, due to the nature of the request taking a longer amount of time to complete there is no guaranteed time where the requestor can retry the request. Instead, it is up to the requestor to determine when to retry.
Testing
Changelog
Please see CHANGELOG for more information on what has changed recently.
Contributing
Please see CONTRIBUTING for details.
Security
If you discover any security related issues, please email [email protected] instead of using the issue tracker.
Credits
- Liam Hammett
- All Contributors
License
The MIT License (MIT). Please see License File for more information.