bkeepers / qu

a Ruby library for queuing and processing background jobs.
MIT License
505 stars 50 forks source link

NSQ HTTP backend #97

Closed grantr closed 3 years ago

grantr commented 9 years ago

This backend supports the NSQ HTTP api with no extra dependencies. It can only push, get queue size, and clear queues.

I split the backend shared specs internally into pushing specs (push, size, clear) and other. Future shared push specs should go in the a pushing backend group.

/cc @jnunemaker @bkeepers

jnunemaker commented 9 years ago

The extra dependency would only be required for dev and for the nsq gemspec. I'd rather use a supported client library and have an extra dep than support a custom one long term. Thoughts?

grantr commented 9 years ago

@jnunemaker sorry for the confusion! This isn't the full NSQ backend. This is only an alternative for those scared of celluloid. It turned out to be easier to write than the real one.

A true NSQ backend (with krakow as the client library) is in progress at https://github.com/grantr/qu/tree/nsq. It works, but there are timing issues with the specs that I haven't resolved yet. I'll create a PR for that when it's ready.

jnunemaker commented 9 years ago

@bkeepers can you add @grantr to qu or add me in some way that I can access settings? Seems easier to have him just work on qu in branches, rather than a fork.

bkeepers commented 9 years ago

Do you see NSQ being commonly used? I'm just wondering if it should just be in a separate repo. I don't feel strongly either way, but I know in the past we've tried to limit the officially supported backends.

@bkeepers can you add @grantr to qu or add me in some way that I can access settings?

Added him. I guess you can't give admin access to contributors on personal repos?

jnunemaker commented 9 years ago

Yeah, I'd be cool with separate gem for nsq as well.

grantr commented 9 years ago

I actually think everything but qu-redis should be a separate repo. Can we create a qu org?

jnunemaker commented 3 years ago

Stale.