Rate limiting? Caching?

[ymyke]

Does your module support rate limiting? If so, how to activate it? What about caching? Are there any 3rd party modules that you can recommend integrating for that purpose?

[mental32]

Does your module support rate limiting? If so, how to activate it? What about caching? Are there any 3rd party modules that you can recommend integrating for that purpose?

I'm afraid you will have to be more specific with your question.

The HTTPClient will respect 429s sent by Spotify but it's current implementation assumes that rate limits are applied on a per request scenario, based what I've read from Spotify's documentation. This has been the approach since the first release of spotify.py and no issues have been reported.

The library as a whole prefers to avoid caching. This is the case because it's simply the simplest and best solution.

Best case scenario is that the library does include a caching mechanism, but in order to invalidate that cache once a resource has been modified Spotify must be able to communicate that a change has occured and this will require a real time communication channel established between the client and Spotify but Spotify does not provide this.

A less than optimal solution is that the library implements a polling mechanism to automatically update the internal state of Spotify objects. This will require, at least, an overhead of one api call per spotify object alive. This overhead cost will add up very quickly and cause rate limits to be triggered much earlier. Not to mention the added complexity to the library by adding a client cache api with polling mechanisms.

Worst case scenario is that we throw our hands up in the air and let the user handle any and all caching with the lib low level api. This is extra work for the user and most times not that critical a feature to have. Not to mention it's more error prone than a groomed and maintained solution present in the library already.

The current solution is better than any one that requires any sort of direct rest api polling feature and still just shy of the best case solution only limited by Spotify. We simply dont perform any caching across the client session, this reduces complexity and keeps the library to a close 1:1 with the rest api itself.

[ymyke]

Thanks for elaborating. This makes sense.

Will spotify.py wait and retry in case of 429s?

[mental32]

Yes see: https://github.com/mental32/spotify.py/blob/master/spotify/http.py#L185

[ymyke]

Great, thanks. Resolved.