From Discord: Add a RateLimiter module

[effect-bot]

Summary

In the above conversation, the topic of implementing delayed API calls with Effect was discussed. Several approaches were suggested, including using a queue or a rate limiter. A queue-based implementation was provided, which allows for limiting the number of requests made within a certain time frame. A rate limiter implementation was also mentioned, which can be useful for controlling the rate of API calls.

Some key takeaways from the discussion include:

1. Using a queue or a rate limiter can help control the rate of API calls and prevent abuse.
2. The implementation can be done using Effect's queue or by creating a rate limiter service.
3. A factory pattern can be used to create instances of the rate limiter service, allowing for easier replacement of implementations for testing purposes.
4. Depending on the requirements, a distributed or shared state may be needed for more advanced rate limiting scenarios.
5. The possibility of adding a RateLimiting module to the core of Effect was mentioned as a potential future improvement.

Overall, the discussion highlighted different approaches and considerations for implementing delayed API calls and rate limiting with Effect.

Discord thread

https://discord.com/channels/795981131316985866/1138377123799769088

[fubhy]

@mikearnaldi Could this be our blueprint? https://github.com/svroonland/rezilience/blob/master/rezilience/shared/src/main/scala/nl/vroste/rezilience/RateLimiter.scala

[effect-bot]

Partially yes, but I'd like to include some form of persistence to make this tooling potentially work across services

…

On Fri, 5 Jan 2024, 17:39 'Sebastian Lorenz' via Technical Operations, < ***@***.***> wrote: @mikearnaldi <https://github.com/mikearnaldi> Could this be our blueprint? https://github.com/svroonland/rezilience/blob/master/rezilience/shared/src/main/scala/nl/vroste/rezilience/RateLimiter.scala — Reply to this email directly, view it on GitHub <#1685 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6645BKPEC23F5DYODXXCTLYNAUDHAVCNFSM6AAAAAA7WO4STCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZYHE2TMNBYGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[hsubra89]

👋🏽 Relatively new to the effect ecosystem.

I followed the conversation on Discord. Even without persistence, I believe having a service specific RateLimiter is generally more useful than not having any solution at all at the moment. If I were to raise a patch based on the Rezilience implementation and the conversation in that thread, would that be accepted?

[fubhy]

👋🏽 Relatively new to the effect ecosystem.

I followed the conversation on Discord. Even without persistence, I believe having a service specific RateLimiter is generally more useful than not having any solution at all at the moment. If I were to raise a patch based on the Rezilience implementation and the conversation in that thread, would that be accepted?

Sure, go ahead. Persistence should be considered in the sense that it should be possible to retroactively add it to the implementation but doesn't have to be included in the first iteration as far as I'm concerned.