Limiting the amount of REST calls in Mendix (most of the time)
Have you ever built an integration and got an HTTP code 429 response in return? Or is the vendor complaining that you do too many calls to their system?
Appronto co-authors: Martijn Booij and Remco van der Gaag
The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time (“rate limiting”).
In that case, you are sending too many calls to the server within a specific timeframe and the server will prevent you from accessing it at that moment in time. This is mainly done to prevent the endpoint servers from overload.
Incremental retrying with a queue mechanism is one of the solutions to this problem, however, you will still not be able to tackle the problem: You still don’t know how many calls you are sending to the endpoint per timeframe.
The Solution
Sometimes the vendor will have the rate limits documented for the specific endpoints. In that case, you do not want to surpass that limit at any time (or you will get a 429 error again).
At Appronto, we’ve built a rate-limiting module that will let you execute microflows with a rate limit that you can control! The specified microflow will be executed by a Java action with an internal rate-limiting queue.
The module not only provides a solution for a single rate-limited integration, but also for multiple integrations with different rate limits.
Download here: https://marketplace.mendix.com/link/component/120637.
Simplified example
You have an app that has two rate limited integrations:
- Integration to ERP allows for 30 calls per minute = 0,5 per second
- Integration to CRM allows for 1 call per second = 1
Beyond these numbers, the integrations will start giving you 429 responses.
In this case, you will have to execute all the microflows that are running a call to the ERP integration, and those calling to the CRM integration, from the Java action in the module, in which you want to execute the microflow.
All microflows that call the ERP integration will have the following settings:
- Rate limit: 0,5
- RatelimitQueue: “integrationERP” (This defines in which queue and thus rate-limiting) the microflow will be executed.
All microflows that call the CRM integration will have the following settings:
- Rate limit 1
- RatelimitQueue: “integrationCRM”
Rate limiting
The Java action accepts the following parameters:
- Microflow to execute
The microflow that will be executed once processed by the Java queue, based on the specified limit.
- Microflow parameter
A parameter that you can pass to the microflow. If you need to pass multiple parameters to your microflows, you can rework this to use a temporary object that holds the different object ID’s and necessary parameters to your microflow.
- Limit size
The limit per second in which the microflows in the queue will be executed. Setting this to one will execute one microflow per second. When not specifying a limit, the action will revert to the default limit, specified in the constant ‘RateLimit’. Using constants is advised as you would use one limit per integration.
- Ratelimit queue
The name of the ratelimit queue to which the calls will be added.
The Java action will execute microflows within the specified rate limit. It uses an internal queuing mechanism in which the first item in the queue will be executed, then waiting for the specified time (based on the limit), and executing the second item in the queue. The Java queue is agnostic to which microflows should be executed, hence all microflows for one integration, should use the same queue.
Dynamic ratelimit
The module does not automatically manage the rate limit for you. If the integration you call has dynamic rate limits (like Spotify) determine a low rate limit to prevent HTTP errors like 429 (too many requests).
An integration will often reply with an HTTP status code 429 and a Retry-After header in this response indicating how long to wait before making a new request. Adjust your rate limit according to these messages.
Example
In our example, we are integrating with two external music platforms with each different rate limitations. The Spotify API service has a dynamic rate limit based on the number of calls within a rolling 30 second timeframe. Based on testing, we found that Spotify allows for approximately 180 requests per minute without returning the error 429. The Discogs API service allows for 60 requests per minute.
Spotify
Our database of artists is updated daily with new information. In the example we simply retrieve the basic information for the artists:
Discogs
After we have updated our artist objects, we want to query the Discogs database based on the found name.
Thank you for reading!
We hope you enjoyed reading this, if you have any thoughts or questions, please leave a comment here.
Read more
From the Publisher -
If you enjoyed this article you can find more like it on our Medium page. For great videos and live sessions, you can go to MxLive or our community Youtube page.
For the makers looking to get started, you can sign up for a free account, and get instant access to learning with our Academy.
Interested in getting more involved with our community? Join us in our Slack community channel.
