Search code examples
springspring-bootwebserverrate-limitingappserver

why rate limiting logic should be placed with application code rather then web server

I am exploring to put rate limiting functionality on rest API which are developed using spring boot.

After going through many articles, I came to know that the best way to put rate limiting functionality is with application code, rather then putting it on web servers.

My question is how do you decide that which functionality should go where. Since, its monitoring your incoming calls and nothing to do with business logic, the ideal place should be a web server.

Solution

  • My question is how do you decide that which functionality should go where. Since, its monitoring your incoming calls and nothing to do with business logic, the ideal place should be a web server.

    Technically the web server could do the job but in the facts, a web server doesn't have necessarily all needed information, it is not specialized for API consuming and it may also make the testability of this feature much harder.

    Some practical reasons why the webserver side could be a bad choice :

    • the developers don't have necessarily the configuration of the HTTP web server in local.
    • you want to write unit and integration test to check that the rate limitations are applied as specified. Creating a configuration for automated testing is much simpler in the scope of your Java application than with a configuration file defined on a web server.
    • web servers reasons in terms of HTTP request-response, not in terms of service. Rate limitations may be applied according to the IP but not only, the username, the user roles, the type of service may influence the limitations. Not sure that you could get all of these easily from an HTTP server.
      For example roles are stored on the server side or in a database.

    A better option is setting these mechanisms by adding specific and specialized classes or configuration files, which simplifies their reading, their maintenance and their testability.
    As you mention Spring Boot in your tags, that and that should interest you.