This sync thing is turning into a major headache.

The Trouble with Feedly

I’m thinking of abandoning Feedly, which is a shame since it seems to have the best mobile ecosystem, but it’s just not developer friendly on the command line. I went over this the last time sync came up, but there are too many hurdles.

• OAuth. I like OAuth, but it’s really not a solution for authenticating from the command line. In particular, the Feedly authentication requires you to be running a webserver (doable since localhost is okay, but totally out of the way for a sync plugin) and interact with a browser. The interaction is the real deal breaker, as I want the daemon to be fully runnable headless, not spawning browsers to click around on. In this case, it’s not really Feedly’s fault because it’s pretty clear they’re targeting other web services and mobile devices where clicking on OAuth sites isn’t an issue. Really, it’s more that it just doesn’t fill Canto’s specific niche.
• Developer Tokens. The workaround for OAuth is using their dev system which basically gives you an authentication token directly, which would be the end result of using OAuth. The unfortunate part there is that it expires without warning and in only 3 months. This is the path I’ve been pursuing albeit with trepidation because that expiration is really a pain in the ass.
• Excessive Rate Limiting. The straw that broke the camel’s back was that the developer tokens only allow you to do 250 requests a day. That might seem like a lot, about 10 an hour, or one every 5-6 minutes, but if the sync plugin is going to immediately inform Feedly of read items that limit is absurdly small. This could be made to work, say by making synchronization explicit but I really don’t want to have to have the user ask to sync manually. And even then, that’s a limit that could be hit and it’s yet another case where the plugin fails out of the blue. Not to mention that developing with that rate limit is really annoying – I’ve hit the limit in under an hour each time I’ve been testing. Of course, that rate limit only applies to the developer token logins, and if I was doing a web service / mobile with the OAuth login then I could register my application and get a decent rate limit. Once again, the daemon gets shafted.
• Documentation. The Feedly API documentation is very sparse and it doesn’t seem to really cover how to use it in a straightforward manner. For example, I had to look at some half-way implemented API bindings just to find that you get content of feeds from the “Stream” API, instead of the “Feed” API. The Stream API talks about streamIds, but never defines them or how to derive them from a feed (I guess it’s *implied* that you use the feedId?). It also has pagination built into it with a “continuation” header, but doesn’t define what circumstances that’s present (i.e. you still get ‘continuation’ even if there are no more items). These aren’t really killer, but it does make figuring out how to use the API a chore.

Alternative: Inoreader

Github user romaintb mentioned an alternative service, inoreader.

Inoreader hits the same notes the Feedly does in terms of platform support. All I really care about is having a free Android app and a web service and those both look good even if there isn’t the same client diversity Feedly offers (yet?).

More importantly, however, the API seems a bit more sane. I was able to register an application and then login with a standard Inoreader account (not using OAuth account, I tried). There’s still a rate limit, but it’s 10,000 requests a day for one part of the API and 50,000 a day for another (so basically 240x the API calls although it’s per application instead of per user). That’s still a limit, but it’s a lot more relaxed and I can request an increase if it becomes necessary (haven’t looked into this yet, but there’s a link for it).

The sane(r) API and the elimination of the developer token 3 month expiration is a pretty compelling reason to switch to researching inoreader.

Alternative: The Old Reader

A commenter on this site put me on to The Old Reader too. I chose to pursue Inoreader based on the web interface, but The Old Reader might also be an option but I haven’t really delved into the API. It seems like everyone is mimicking the old Google Reader API (as unofficial as it was) so it might be trivial to do both.

Let’s not get ahead of ourselves however.