Skip to content

Conversation

@jondeweydev
Copy link
Collaborator

@jondeweydev jondeweydev commented Jul 8, 2022

Summary

Just like the title says, this is just a spec layout of the functionality to come.

Type of Change

  • New feature (non-breaking change which adds functionality)

Issues

closes #68

timestamp: number;
}

export interface RedisWindow {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You created interface RedisWindow which looks the same as the interface RedisBucket. Any reason you can't use RedisBucket?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or rename RedisBucket to a name that works for both buckets and windows?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

going to add more values in the future to track the rolling and fixed window timestamps

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case the new type should extend RedisBucket to keep things DRY.

At a higher level, what data does Redis need to track? My understanding is the complexity of all requests in the previous window along with the complexity of all requests in the current window. In each case the timestamp could just represent the beginning of the window. I don't think we need to track the timestamp of each request in Redis.

If we don't need anything else then for each user we just need to store two RedisBuckets either under to separate keys or both as an array. In the latter case then we would just need to type something as [RedisBucket, RedisBucket]

Thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline

Copy link
Contributor

@evanmcneely evanmcneely left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved pending the resolution of my one comment about the new interface created.

Copy link
Collaborator

@shalarewicz shalarewicz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just want to discuss high-level approach before approving. See comments for more details

timestamp: number;
}

export interface RedisWindow {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case the new type should extend RedisBucket to keep things DRY.

At a higher level, what data does Redis need to track? My understanding is the complexity of all requests in the previous window along with the complexity of all requests in the current window. In each case the timestamp could just represent the beginning of the window. I don't think we need to track the timestamp of each request in Redis.

If we don't need anything else then for each user we just need to store two RedisBuckets either under to separate keys or both as an array. In the latter case then we would just need to type something as [RedisBucket, RedisBucket]

Thoughts?

@jondeweydev
Copy link
Collaborator Author

updated RedisWindow interface to include fixedWindowStart and currentTokens as well as previousTokens

@shalarewicz shalarewicz self-requested a review July 9, 2022 17:31
@jondeweydev jondeweydev merged commit 3dc4c6c into dev Jul 9, 2022
@jondeweydev jondeweydev deleted the jd/slide branch July 9, 2022 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Write Spec for Sliding Window Counter class

4 participants