> What if we don’t have control over the frequency of requests (e.g. using a service like Feedly)? Do those happen often enough that we’d need to host the app ourselves?

I know the wording is a bit vague, and I know that most services don't let you customize this. I added it after I suddenly started receiving tons of traffic caused by, I suspect, a single user. This person was purposefully fetching feeds multiple times a minute.

Anyhow, if you aren't actively trying to abuse the service, you should be good. Some RSS readers have "boost" features to fetch feeds more frequently (often a paid feature).

Once I am able to add some good caching, then I may be able to remove that notice. But right now, the service is kinda overloaded and that is why some of the services (Twitter and Instagram in particular) may give you errors at the moment.

Feed aggregation services tend to minimize the frequency of requests especially for unpopular feeds since more requests = higher load for them as well. The incentives on the publishing and consuming sides align. Many services only offer to increase crawling frequencies for premium users, and even then only for a limited number of feeds. Not to mention they only need to crawl once for however many subscribers.

It’s really people who don’t use aggregation services and set their clients to update very frequently (say every minute) that pose a problem.

An aggregator most likely would prioritize feeds by popularity and then run most of their crawlers 24/7. Telling some users that a popular feed has new entries and not telling the free tier sounds complicated. Unless the free tier is getting a read replica of the database, in which case it’s throttled only by how far behind the read replicas get.

Prioritizing lower subscribership feeds if a smaller number of premium customers add them makes some sense though.

Of course popular feeds are crawled constantly, and no, there’s no “telling some users that a popular feed has new entries and not telling the free tier”. But you bet services don’t want to crawl those one-subscriber feeds (e.g. some websites have personal feeds for paid subscribers) constantly for free. And RSS Box feeds apparently tend to fall in the latter category.

> What if we don’t have control over the frequency of requests (e.g. using a service like Feedly)?

I believe most RSS reader-clients and aggregator backends are programmed to respect HTTP cache-control headers; so as long as the developer of this service sets those headers appropriately for their endpoints, there shouldn't be a problem.

The warning is likely more for people's custom scripting using curl(1) et al, where there isn't an HTTP cache in the code path.

Yes, this is far better than most.

But as a matter of fact, almost all of that functionality could be done without JavaScript! You can make the dropdown work by changing it to use a <details> element (the best approach for both practical and accessibility reasons), or :focus-within, or any number of hacks (I’m partial to the checkbox hack which has served me well for many years, except for minor accessibility concerns), and then replace the <a> elements with appropriate submit buttons that will set the necessary query string parameters.

For example, the button for “exclude retweets” would be:

  <button type=submit name=include_rts value=0>Exclude retweets</button>

The only bit that I can’t think of a good way to handle is when you’re setting more than one query string parameter, like the Twitter “Exclude retweets and replies” button which wants to add `include_rts=0&exclude_replies=1` to the query string. I can think of ways to make it work with two clicks (harming accessibility in the process), but none with only one click. My best hope was putting formaction="?include_rts=0&exclude_replies=1" on the submit button, but a GET form will scrub any query string from its action, so that doesn’t work.

And download links like the Ustream one would use formaction="/ustream/download" on their submit button.

I will look into this. Thanks!

> What if we don’t have control over the frequency of requests (e.g. using a service like Feedly)? Do those happen often enough that we’d need to host the app ourselves?

I run a similar service where I rate limit. I've whitelisted the IPs of the centralised feed readers like Feedly (at least the ones I've been able to identify), but the reate limit for non-whitelisted IPs is generous enough that it's really there to only catch the really problematic scripts which crop up from time to time.

> Though it should be “then you will be able”.

Fixed. Thanks! :)