Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manage the amount requests to the Web API to avoid rate limiting #12

Closed
JMPerez opened this issue Jul 1, 2015 · 6 comments
Closed

Manage the amount requests to the Web API to avoid rate limiting #12

JMPerez opened this issue Jul 1, 2015 · 6 comments
Assignees

Comments

@JMPerez
Copy link

JMPerez commented Jul 1, 2015

I think you could use something like https://github.com/JMPerez/promise-throttle to limit how many requests per second are made. You have an example of how this is done on https://github.com/JMPerez/spotify-dedup/blob/master/app/scripts/main.js

If you like the idea I can work on a Pull Request to add this.

@watsonbox
Copy link
Owner

Yes, I like this idea. I guess it would only ensure no throttling errors when using a personal application though, since according to the docs "Rate limiting is applied on an application basis (based on client id), regardless of how many users are using it."

I'm going to add a progress bar for the bulk export soon, too, which would be a pre-requisite for adding this kind of slowed down exporting I think.

@JMPerez
Copy link
Author

JMPerez commented Jul 1, 2015

You can still have rate limiting issues if several users are using the site at the same time, but you would have more control on the amount of requests a given user makes per unit of time.

@pavelkomarov
Copy link
Contributor

My version implements rate limiting, 10 queries per second to the server. This is essential to make exporting really large playlists or all together work. Even for users with insanely large collections, it works in only a few minutes. Progress bar not super necessary.

I've hard-coded my client id, so everyone who uses it racks up traffic under the same limit. So if lots of users at once happen to all try to Export All at the same time, then yes they'll still run in to rate limiting problems. But this is unlikely until there are thousands of users every day, so I've chosen to just ignore it. If we ever get to that point, then I'll have to do something like give everyone their own client id.

exportify.net

@watsonbox
Copy link
Owner

Terribly overdue 🙈 but I'll see what I can do in updating this repo to support this and using as much of the work that's been done as possible. Thank you @pavel-aicradle for advancing it. I think this issue will best serve as the main one for dealing with this, put there's a lot of useful discussion in these:

@pavelkomarov
Copy link
Contributor

#70 gives you my changes, which include the fix to this.

watsonbox added a commit that referenced this issue Nov 12, 2020
- Remove jQuery in exporter objects
- Use Bottleneck library for rate limiting https://github.com/SGrondin/bottleneck
- Simplify code
watsonbox added a commit that referenced this issue Nov 12, 2020
- Remove jQuery in exporter objects
- Use Bottleneck library for rate limiting https://github.com/SGrondin/bottleneck
- Simplify code
watsonbox added a commit that referenced this issue Nov 12, 2020
- Remove jQuery in exporter objects
- Use Bottleneck library for rate limiting https://github.com/SGrondin/bottleneck
- Simplify code
watsonbox added a commit that referenced this issue Nov 16, 2020
* Implement rate limiting using Retry-After header

- Remove jQuery in exporter objects
- Use Bottleneck library for rate limiting https://github.com/SGrondin/bottleneck
- Simplify code

* Add progress bar for Export All progress

* Update tests to ensure access token is correctly passed
@watsonbox
Copy link
Owner

Should now be fixed by #75

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants