Alternative async backend about feedhq HOT 2 CLOSED

FeedHQ uses RQ which is redis-only. Redis is also used as a cache backend for sessions and static files. PostgreSQL has listen/notify capabilities but technically FeedHQ is SQL-agnostic so relying on Postgres means ditching SQLite / MySQL / Oracle support provided by the Django ORM.

There is the trick of setting RQ to eager mode by adding ?eager=True to the REDIS_URL environment variable but that would work only if you're able to process tasks very quickly (or if you have few feeds to process). The eager mode makes the async backend synchronous, meaning every time something is enqueue()'d it gets processed immediately.

This would be fine for small loads, when a single worker would be enough. Probably fine for a single user on shared hosting.

There are a couple of places where stuff is made async in the views:

• OPML import
• Sending to Readitlater / readability / instapaper
• Saving a feed object

Eager mode would make these views slow. The worst case being OPML import :)

from feedhq.

Bad news: the scheduling code now uses Redis instead of the database. It's also much more efficient :). I have very little interest in making the redis dependency optional now, so I'll just close the bug. Postgres and Redis are both hard dependencies.

from feedhq.