dynamic config params without restart about spring-cloud-zuul-ratelimit

[zhongyusimon]

Let me ask, did you check the configuration example in the README file? It shows you how to configure access limit per user.

About the restart, it's not really necessary, are you using spring-boot-actuator along with Spring Cloud Config Server? Applying these tools to your project will make it possible to change the configuration on the fly.

answered by @marcosbarbero

[zhongyusimon]

I also have a doubt, that why dont we use code to dynamic change the filter params, so we can store the config in mysql or redis instead. and also can effect the config for a certain time interval. otherwise the refresh config is also a dangerous action, it may damage the online program.

[marcosbarbero]

Hello @zhongyusimon, as this project is meant to use spring-cloud-netflix implementation in which supports spring-cloud-config-server, I don't believe it's good to add this jdbc configuration support as it's already supported by spring-cloud-config-server.

This project will always support the same configurations available for spring-boot.

[zhongyusimon]

Then i have a suggestion about this. cause the project lack of custom logic, we could support config the rule of code style in addition. just like we can use most of models in config way or in code way, so that we can do a lot of things in code with persistence config or complex logic for routing.

[marcosbarbero]

I'm not really sure if I understood your suggestion

[zhongyusimon]

it means we can config the params in yaml or config it in code. just like we can use feign with packed function, or use RestTemplate with custom function.

[marcosbarbero]

Feign and RestTemplate are totally different beasts comparing to this library.
Let's say that feign and restTemplate are libraries meant to be used directly and then you can reconfigure it as necessary because it needs to be explicitly used in the code in order to make the requests.

In the other hand, this rate limiter implementation is not meant to be explicitly used in the code, it needs to be configured and used as such, you won't explicitly call a filter or anything like that, however, if what you need is to be able to create your own filter then it will be necessary to revisit this project architecture, right now it's not that simple to make it.

[lchayoun]

First, the configuration is on the refresh scope, so restart is not needed.

I strongly agree with @marcosbarbero, this project is an implementation specific to zuul in order to add rate limit capabilities with a minimum overhead and as fast as possible.
It is definitely not meant to be explicitly used in the business logic code.

But, if you want to customize the policies dynamically, you can always add a filter that runs before the rate limit filter and modify the policies configuration as you wish.
Of course, there are some limitation to the dynamicity of how this project use the configuration.