Bull: Get a list of all bull queues on redis

Created on 9 Aug 2018 · 7Comments · Source: OptimalBits/bull

Is it possible?

Thanks

question

Source

cesarvarela

👍1

Most helpful comment

Here some inspirational code to get the queues:

var queueNameRegExp = new RegExp("(.*):(.*):id");
const keys = await redisClient.keys("*:*:id");
queues = keys.map(function(key) {
  var match = queueNameRegExp.exec(key);
  if (match) {
    return {
      prefix: match[1],
      name: match[2]
    };
  }
});

manast on 21 Aug 2018

👍3 ❤2 🎉2

All 7 comments

I have the same question. Please help!
Guys, thanks for the package, but your Docs aren't begginer friendly.

ChrisRobston on 20 Aug 2018

@cesarvarela did you managed to solve this?

ChrisRobston on 20 Aug 2018

@canyoudev what things were not beginner friendly? Please open an issue describing the docs you would like to have :)

aleccool213 on 20 Aug 2018

👍2

Here some inspirational code to get the queues:

var queueNameRegExp = new RegExp("(.*):(.*):id");
const keys = await redisClient.keys("*:*:id");
queues = keys.map(function(key) {
  var match = queueNameRegExp.exec(key);
  if (match) {
    return {
      prefix: match[1],
      name: match[2]
    };
  }
});

manast on 21 Aug 2018

👍3 ❤2 🎉2

I ended up not needing it.

btw, thanks for the example, you can close the issue if you want.

cesarvarela on 21 Aug 2018

@manast @aleccool213 thanks for responses.

After reading Docs more carefully and spending more time with this package I ended up with idea that you guys intentionally leave all this space for developer to solve. This is a good idea, since you doesn't pollute source code with API that devs could implement themselves. It's just me get used to all this huge API's.

The only thing is missing for me in Docs, is good practices and code examples, like this. But after all, since there's pretty intensive discussions in issues, I could find plenty of examples there, which is nice. So thanks!

ChrisRobston on 21 Aug 2018

🎉1 😄1

I actually disagree, i think this should be within the library. I think the way redis works to store and manage queues should be completely internal to bull. Having external APIs depending on the internal redis structure is brittle, and also will restrict changes and enhancements in the future with bull.