Support node-redis, possibly along with ioredis?

[yshrsmz]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Add support for redis package.

Motivation

According to the issue in ioredis(redis/ioredis#1870 (comment)), the future mainstream package is going to be redis, not ioredis.

So I think it's a good idea to support redis package.

Example

No response

[mcollina]

Indeed. However Redis is not OSS anymore :'(. I'm generically planning to migrate everything to iovalkey that I plan to maintain.

[yshrsmz]

That sounds good!

I'd like to propose another idea. Is it possible to make it more pluggable? I mean, it would be great if we could use any caching mechanism with this plugin.

For example, split the lib into 2(or more) packages. One is @fastify/rate-limit-core, and another is @fastify/rate-limit-ioredis.

@fastify/rate-limit-core provides core fastify plugin implementation and an interface for the caching mechanism, along with its local in-memory implementation. And @fastify/rate-limit-ioredis provides ioredis implementation for the interface.

This way, if we want to use node-redis or any other caching solution, we can develop a custom implementation while using this plugin.

[gurgunday]

@yshrsmz I completely agree!

Let's create a standard interface (or base class) for fastify-rate-limiter that supports different storage providers (Redis, Valkey, MongoDB, etc).

NestJS does this beautifully with throttler: https://docs.nestjs.com/security/rate-limiting#storages

This approach would:

• Provide simple in-memory storage by default
• Include popular options like Redis out-of-the-box
• Let users easily implement custom storage solutions

Implementation-wise, we'd replace the redis parameter with a storage parameter. Our code wouldn't need to know the storage details - it would just call methods like increment() and compare results with the limit.

This is very achievable, and we can use this breaking change to modernize from callback-based Stores to Promise-based ones.

[avifenesh]

@gurgunday Please involve me for adding valkey-glide as one of the options.

[gurgunday]

Of course :)

I think a lot of people would want Valkey support including me

I'll try to work on this soon and once it's done I'll ping you for help with the GLIDE store

[Eomm]

@fastify/rate-limit-core provides core fastify plugin implementation and an interface for the caching mechanism, along with its local in-memory implementation. And @fastify/rate-limit-ioredis provides ioredis implementation for the interface.

I would invert the logic because a user wants to install a single package.
To ease the things, @fastify/rate-limit-core should be able to register itself without the need to:

1. register @fastify/rate-limit-core
2. provide @fastify/rate-limit-ioredis to the prev plugin

unnecessary overloading that leads to release issue (what if we bump rate-limit-core, but not the rate-limit-ioredis one.

[mcollina]

I think we should keep having a pure-js option and migrate the ioredis one to iovalkey.

[avifenesh]

@mcollina while the movement to iovalkey is amazing! I think the community will be extremely happy about it.
Would adding glide as well, will be a feature the plugin would like to have as well?
We can abstract it behind the same API for the plugin devs, and of course, users?
Currently, I'm adding support for another largely used rate-limiting library, and would like to support glide users, or those who want to use Glide, the option to do so for all the big tools they might use.
Fastify, and specifically this plugin is one of them.

It can be done separately by creating a plugin uniquely to glide for those specific users, which is also fine by me.
But of course, I'd prefer to be sided by pros with major experience in the ecosystem and in general, and part of a mature plugin.
The question is whether there is interest for it to be central, and to have it as an additional feature the library offers.

[mcollina]

Generically we tend to avoid adding binary dependencies if possible, as they cause issues for end users.

As you can see, there is no actual dependency on ioredis:

fastify-rate-limit/package.json

Lines 74 to 78 in 98bc10b

	"dependencies": {
	"@lukeed/ms": "^2.0.2",
	"fastify-plugin": "^5.0.0",
	"toad-cache": "^3.7.0"
	},

.

The logic described in #368 (comment) would be fine.

[avifenesh]

@mcollina for sure not as a hard dependency. The user will need to supply it himself.

Just to make sure i understood, the solution we want is to create a new plugin, which use the core by itself and override the ioredis implementation to valkey glide implementation?
Instead of having it optional part pf the core limiter, but on top of it separately?

[mcollina]

https://github.com/fastify/fastify-rate-limit/blob/main/store/RedisStore.js as you see, it's just a few lines of code.

[gurgunday]

Having a base class that's extendable to implement any storage is what I will go for in my PR

We will surely support the official clients for Redis and Valkey, the implementation is very similar for both of them anyway

Like @avifenesh said, we just did something similar with rate-limiter-flexible, there won't be any dependencies, the client will be passed to the corresponding storage implementation