Limiting your amount of calls in Mendix (most of the time REST)

Problem

Have you ever built an integration and got HTTP code 429 response messages in return? Or is the vendor complaining that you do too many calls to their system?

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.

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 2 rate limited integrations:

1. Integration to ERP allows for 30 calls per minute = 0,5 per second
2. 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 executing a call to integration ERP, and those calling to integration CRM, from the Java action in the module, in which you want to execute the microflow.

All Microflows that calls the integration ERP, will have at least the following settings:

• Rate limit: 0,5
• RatelimitQueue: “integrationERP” (This defines in which queue and thus ratelimiting) the microflow will be executed.

All microflows that call to intergration CRM, will have at least the following settings:

• Rate limit 1
• RatelimitQueue: “intergrationCRM”

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 1 will execute 1 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 1 limit per integration.

• Ratelimit queue

The name of the ratelimit queue where the calls will be added to.

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 a 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 seconds timeframe. Based on testing we found that Spotify allows for approx. 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.