Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As described in this issue, developers should not request large sets of data from the Mollie API in most scenarios. This PR aims to discourage doing so, by introducing throttling.
If a developer (and thereby a merchant) requests a large set of data, the throttling will spread out the pressure on the Mollie API over a larger period of time. But additionally, it might send a signal to the developer, asking "hey, this thing you're doing, it's costly, is there no better way?"
(Closes #271)
Interface
In this implementation, the developer is in control of the throttling:
Developers are using this client voluntarily. They can opt-out of using it at any time, and just use curl to communicate with the Mollie API instead. This is why I feel "forcing" a certain amount of throttling is not productive. If a developer chooses to set the
valuesPerMinute
toNumber.POSITIVE_INFINITY
, that's a conscious decision on their part.(
valuesPerMinute
is optional, making this change backward compatible.)Better
A safer form of throttling ‒ in the sense that it's more difficult for developers to circumvent ‒ would be one that is applied on the Mollie API itself rather than in the client(s). When such throttling is introduced, it can be removed from the client.
Best
Neither spreading the requests over a longer period of time, nor asking the developer to find a way to make fewer request is an ideal solution. The real solution is making more efficient requests, by supporting filtering and searching in the Mollie API itself.
Once the Mollie API supports filtering payments by currency, for instance, we can expand the iteration API:
This would guarantee one single call to the Mollie API (
v2/payments?currency=EUR&limit=10
).