|
|
|
|
|
|
by CharlesW
1294 days ago
|
|
|
> In my experience, you generally do that through an aggregator… My understanding is that a cloud-based aggregator (like Feedly) delivers feed and state information to clients, but not the content itself. To test this with blogs, I did a new install of Reeder, synced with Feedly, then turned off Wi-Fi. In my subscriptions, I got everything that would be in the feeds themselves (notably item titles and descriptions as created by publishers) but nothing beyond that. The offline experience was mostly useless, suggesting that the client does most of the heavy-lifting even when leveraging cloud-based aggregators. So is making a few REST API calls a significant savings over checking a couple hundred (or whatever) RSS feeds? With "If-Modified-Since" checks being so cheap, I'm not sure that inserting Mastodon instances as middleboxen makes sense. If all Mastodon did was store subscriptions and state info, it seems like we'd have a far more resilient microblogging ecosystem. |
|
|
Depends entirely on the feed. Just checked my most recent 100 entries from Feedbin - that comes back with 23k of `summary` and 508k of `content`. That was one call to return 661k of JSON covering 28 feeds.
> So is making a few REST API calls a significant savings over checking a couple hundred (or whatever) RSS feeds?
I've made one call to get (assuming >2k in `content` is a full article) 74 full articles from 28 feeds. Add another 26 and I'm looking at 27 total.
Even just retrieving the RSS feeds is 28 and 26 more for the non-included articles to make a total of 54 - double what I had to do via Feedbin. That's before we start considering response times and latency for each of those sites which would drag things down even further.
There's a reason why people use RSS aggregators!