Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by weixiyen | Hacker News Reader

Full thread

weixiyen·

Curious, why the choice of mongo vs something like redis?

View on HN

I thought the same. For redis there's Kue, which looks a lot more feature complete.

https://github.com/learnboost/kue

See above for Mongo vs Redis. As for "feature completeness", this is a pretty feature complete job scheduling library. It leaves the writing of a Web interface to someone else, but for scheduling jobs it gets the job done. (Haha, that pun was irresistible)

The choice of Mongo vs Redis was intentional. Without configuration Redis doesn't guarantee persistence as well as Mongo. Since Redis is often used for non-critical data such as sessions I didn't want to enforce sacrificing performance of sessions for persistence.

Looking at these scheduling modules, I wonder to myself why saving a .json file wouldn't be more simple. Filesystem cache, available to all workers on the system and no dependencies required.

I mean, if you're worried about cluster workers file reading being slower than a db connection, the json store could be write-only most of the time and only read on app startup while schedules are synced over cluster messaging.

In my mind there are a few reasons, but indeed it could definitely be implemented with a flat file. Sometimes you aren't guaranteed write-access to a file on the system, especially if you're using a PAAS like Heroku. That also complicates things if you want to build something to view/edit the data in an isolated instance. These are just the reasons that come to the top of my head, but in reality you're right, this could be finessed to be done with just a flat file.

Good points. Perhaps structuring it in a way to allow for a flat file or redis/nosql/sql might push a particular schedule module into greater favor, at least for those of us who want our apps to consist of minimal different db methods.

Reply on news.ycombinator.com