Consider making the full download a little less aggressive

[davep]

Right now the full download of all Raindrop data goes pretty hard. So far raindrop.io isn't complaining, and also it shouldn't happen too often if you're mostly using the Braindrop itself¹.

Look at ensuring that the download code observes any throttling, and perhaps also provide a method of interrupting a download.

Footnotes

1. Little less the case if you're a Pro user as Raindrop will do broken link scanning, etc, which will cause changes on the server that will trigger a fresh download the next time you run up the application. ↩

[davep]

Note the rate limits for the Raindrop API: https://developer.raindrop.io/#rate-limiting

It does say:

For requests using OAuth, you can make up to 120 requests per minute per authenticated user.

which would suggest that Raindrop wouldn't be subject to this because it's not using OAuth; but I suspect this is awkward wording and the same limits apply to calls using the test token too.

It's also worth noting that 120 requests per minute, given the scenario written about in #72, would mean it would take at least 30 seconds to download those 3,000 raindrops. It might be worth looking at estimating the number of pages that need downloading, calculating any pause that needs to be used based on that, and also letting the user know how long they can expect to wait (ish -- there's also the issue of download speed and stuff, of course).

It might make more sense to work around these headers:

X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset

[davep]

Despite what the documentation says, it looks like there isn't a X-RateLimit-Reset header (or any of the other headers) when there's a 429. Instead you get a Retry-After.