#Making storage provider for nestjs/throttler for MySQL Database using Sequelize Module

9 messages · Page 1 of 1 (latest)

noble flame
#

I am working to make a storage provider to nestjs/throttler for MySQL Database with Sequelize Module. I wanted to see if this is a good apparoch. I have made one that behave similarly with the original rate limiter logic. The only problem is the sequelize model needs to be added manually on AppModule when declaring Sequelize Module. However, I'm just curious if this is a good idea to start with. I've only code on the side or as hobby and have limited knowledge with NestJS. I'm writing my first NestJS backend server atm for my website. I'd like to see if anyone have any concerns with this apparoch.

// app.module.ts
@Module({
    imports: [
        ThrottlerModule.forRoot({
            throttlers: [
                {
                    ttl: seconds(10),
                    limit: 2,
                },
            ],
            storage: new ThrottlerStorageMysqlService(Record),
        }),
        SequelizeModule.forRoot({
            dialect: 'mysql',
            host: 'localhost',
            port: 3306,
            username: 'root',
            password: '',
            database: 'development',
            autoLoadModels: true,
            synchronize: true,
            models: [Record],
        }),
    ],
    controllers: [AppController],
    providers: [AppService],
})
simple helm
#

I have never checked why you would want to store this

But fear sql would be hela slow if this needs needs to be used for anything other then logs

There is a reason redis is so common for this it's faster then any other sql like DB

noble flame
#

I see. To be honest, using sequelize module as storage for throttle is to avoid managing two database. As i already use MySQL to store my data, I just wanted to continue using it to handle throttler storage.

While it is currently working as intended, your concerns with performance is a solid argument. I might as well go with the built-in memory storage at this point.

simple helm
#

after looking into this a bit more, it seems this feature isn't needed in most cases
unless we start having per users/api keys/accounts with different rate limits
i see the use case but not like i'm going to need this

#

grokAI might use this for example
to give the twitter (X) bot account a higher rate then somebody who might use their api key for a small website chat asistant

noble flame
#

I'll look into redis and consider using it for rate limiting data storage. I believe there are storage provider for redis and mongodb already available as community package. I've just started working on one using sequelize as that's what I'm using in the backend. Now it look like a bad idea.

simple helm
noble flame
#

Frankly I believe I did not consider the read/write for rate limiting data and started making mine to save me time managing another db. Thank you for your comments.