Persisting the limiter state

[discoverlance-com]

Is there a way we can persist the state of the limiters?

For instance, whilst refreshing the page, if I could persist my rate limit, that will be great else the user just needs to refresh and the previous limiter applied will be lost.

So if I could persist it's state perhaps through some sort of storage drivers like localstorage, cookie or something else of choice. Where the storage driver can just be logic that needs to be implemented or an api interface which can give the user options to persist it to other states even external if they need to do so.

[KevinVandy]

This is a good idea. We should probably have some dependency injection strategy to support persisting and resuming state. That would also make Pacer much more viable on the server.

[KevinVandy]

For server stuff, I meant that we would support using pacer in backend code and persisting to Reddis or something like that. Then pacer could be added in APIs to check rate limits in the backend. No client stuff involved in that scenario.

I think we're making this flexible enough to be used in both the client and server separately.

[kculmback-eig]

An API similar to what @tanstack/query supports for persisting would be great. We are looking at using pacer for our React Native app to queue long running tasks, but need to be able to persist the queue in case a user closes the app. Either using something like @react-native-async-storage/async-storage or react-native-MMKV.

[KevinVandy]

@kculmback-eig You can follow along with my PR here: #32

It's pretty simple and strait forward so far, and just for local/session storage. But, since I separated the persisters into their own packages, maybe you could help with making a @tanstack/react-native-persister package or something like that. My goal is to make it generic enough to work with any TanStack library (or really any other library).

[kculmback-eig]

Looking through your PR I don't think we'd need a separate package for react native specifically. Being able to pass a custom storage provider should be good enough!

Here's some pseudocode for using MMKV:

import { MMKV } from 'react-native-mmkv'

const mmkvStorage = new MMKV()

// Create a rate limiter that persists its state
const rateLimiter = useRateLimiter(setLimitedCount, {
  // Configure the persister to save state to MMKV
  persister: useStoragePersister({
    key: 'my-rate-limiter',
    storage: {
      setItem: (key, value) => {
        mmkvStorage.set(key, value)
      },
      getItem: (key) => {
        const value = mmkvStorage.getString(key)
        return value === undefined ? null : value
      },
      removeItem: (key) => {
        mmkvStorage.delete(key)
      },
    },
  }),
})

And some for using async storage:

import AsyncStorage from '@react-native-async-storage/async-storage'

// Create a rate limiter that persists its state
const rateLimiter = useRateLimiter(setLimitedCount, {
  // Configure the persister to save state to AsyncStorage
  persister: useAsyncStoragePersister({
    key: 'my-rate-limiter',
    storage: AsyncStorage,
  }),
})

This is very similar to what we currently do with @tanstack/react-query:

import { createSyncStoragePersister } from '@tanstack/query-sync-storage-persister'
import { MMKV } from 'react-native-mmkv'

const storage = new MMKV()

const persister = createSyncStoragePersister({
  // https://github.com/mrousavy/react-native-mmkv/blob/main/docs/WRAPPER_REACT_QUERY.md
  storage: {
    setItem: (key, value) => {
      storage.set(key, value)
    },
    getItem: (key) => {
      const value = storage.getString(key)
      return value === undefined ? null : value
    },
    removeItem: (key) => {
      storage.delete(key)
    },
  },
})

[KevinVandy]

I've been working on this for a couple of weeks now and I've changed my mind on the exact API several times. It will remain about this easy, but there is just going to be a huge state refactor in general with TanStack Store that is going to streamline several things in TanStack Pacer. Will probably share more tomorrow.