kue Kue without Redis

I'm running an app that (for the foreseeable future) will not be scaled beyond a single running instance. I'd like to keep the job queue in-memory without having to make calls to redis. Am I crazy or is kue unnecessary in this case?

I like the API a whole lot.

Thanks.

Jun 12 '16 18:06 ColemanGariety

I'd like to keep the job queue in-memory without having to make calls to redis

If you don't need distribution and delayed jobs, You'd better use a control flow module like async.

Jun 12 '16 20:06 behrad

If redis isn't required (as it seems to be shown here) then why is it listed in the package.json?

I ask because couldn't you just not use redis and specify redis.createClientFactory. Have itreturn a module that implements the redis API but that just stores the items in memory?

Jul 21 '16 18:07 Saevon

@Saevon that's what I ended up doing :-)

Jul 21 '16 18:07 ColemanGariety

@JacksonGariety: but doesn't this package install redis anyways? that seems a bit wrong if redis isn't at all needed, in fact I would have just made the default be an in memory queue, with a setup for redis.

At the very least the redis should be removed from package.json

Should I perhaps open another ticket for this?

Jul 21 '16 18:07 Saevon

@Saevon in places where scaling is never needed, I use async.queue. When may be needed in the future, I stub the redis client via the factory method.

I think it makes sense to make redis optional here, because it did take a good amount of time to implement async.queue, but I won't be needing it anymore.

Jul 22 '16 01:07 ColemanGariety

@JacksonGariety afaik async.queue doesn't support retries and timeouts between them (always have to code it in yourself). Hence why I prefer this library. Also as you'd mentioned this can scale to use redis when needed with next to no work.

So I believe you should change this issue to request the following (unless thats not how issues work here):