Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document ActiveJob compatibility/configuration #127

Closed
bensheldon opened this issue Oct 22, 2015 · 10 comments
Closed

Document ActiveJob compatibility/configuration #127

bensheldon opened this issue Oct 22, 2015 · 10 comments

Comments

@bensheldon
Copy link

I eagerly recommend Que to everyone, but the first question they ask is "Is it ActiveJob compatible?". The answer is Yes, but ActiveJob is not mentioned in the Readme nor is there an example in the docs directory. I'd be happy to submit a PR to improve the documentation for using Que with ActiveJob if this is an unintentional omission.

@chanks
Copy link
Collaborator

chanks commented Oct 22, 2015

In the 1.0 branch I've actually removed everything that's Rails-specific (the Railtie, the migration generator, etc). Those parts have always been the most poorly tested and the most time consuming to maintain, especially since I don't personally use Que with Rails (My day job uses Rails + Sidekiq, and I have personal projects that use Que with Roda and Sinatra). I've also gotten frustrated with ActiveJob in the past, and I've grown kind of skeptical that a job queue is the right place for this kind of plug-and-play abstraction.

I've actually been considering whether it would be good to have a disclaimer on the Readme, saying that if the reader wants a quick and easy integration with Rails that they don't have to think too much about, they should probably be looking elsewhere. I'm happy if other people get use out of Que, and when I first launched it I was certainly hoping for a significant level of adoption, which is why I included the Rails integration in the first place. But these days I don't really feel like a large userbase for it is a goal I need to strive toward.

I think it'd be nice if somebody with more of an interest in the Rails stack maintained a gem that promised an easy integration with Que, and I'd certainly try to keep Que flexible enough to make their job easy. But I'm not really plugged into the Rails Way anymore, and I can't really justify the time expenditure to support everyone that is.

@chanks
Copy link
Collaborator

chanks commented Oct 22, 2015

BTW, sorry if that reads as brusque. I don't mean to brush aside your concerns, I'm just laying out how I feel. Does my wanting to drop closer Rails support seem unreasonable to you, or anyone else reading?

@bensheldon
Copy link
Author

@chanks that reads completely polite 😄

I might disagree that "a large userbase" and a small, focused, opinionated tool like Que are mutually exclusive. But I can agree and sympathize about externalizing the Rails integration into a separate gem if that's not where you want to spend time in development or support. As a middleground, you might consider still maintaining control (e.g. owning the repo and Rubygem) of a potential que-rails gem but offload the support to co-maintainers. Just my preference, but I'd rather have an officially blessed gem than multiple projects in various states of abandonment on Github.

Do you have a public timeline/milestone for the 1.0 release? I hope there can be more community discussion and input; not to change your mind, but at least to pick up the work to be done.

@chanks
Copy link
Collaborator

chanks commented Oct 23, 2015

Thanks. 😄 And yeah, I started a que-rails repository a while ago but stumbled around on how to test it. Having an official version that is mostly maintained by those more plugged into Rails sounds good to me.

I don't really have a timeline in mind for 1.0. I mean, the branch is public, but I don't know how much more I want to do with it. It's enough of a rewrite that I considered releasing it as a completely separate gem, but decided against it. At the very least I think there'll be a few betas (maybe even alphas?), so it won't be a sudden thing.

@krisalyssa
Copy link

I just started switching from Sidekiq to Que for an application I'm working with, and the spotty integration with ActiveJob has been my only source of frustration. That being said, I can fully appreciate your not wanting to expend energy on a technology you don't use anymore. That being said, I'd still like to see Que work with ActiveJob, and am willing to help out with maintenance as needed.

@timdiggins
Copy link

Know this issue is quite old, but wondering what the current state of play/plan is -- I notice that there's an ActiveJob adapter for que in rails itself. (although there are arguments against using ActiveJob elsewhere: e.g. #156)

@timdiggins
Copy link

Starting to answer my own question: it looks like the 1.0 branch (in beta) seems to have rails and ActiveJob support fully baked-in (https://github.com/chanks/que/blob/v1.0.0.beta/CHANGELOG.md).

@chanks
Copy link
Collaborator

chanks commented Feb 6, 2018

Yes, that's correct. You're welcome to use 1.0.0.beta, I'm using it in production at my day job. Bug reports welcome!

@timdiggins
Copy link

Great. Will try it out after some other changes in the codebase calm down.

@chanks
Copy link
Collaborator

chanks commented Apr 15, 2018

Closing this out since 1.0 just had its second beta release. The ActiveJob integration is much better (and much better tested) in 1.0. Rails integration specifically is harder, since it's difficult to test against an entire Rails app and things seem to break every time a new major version comes out, but what can you do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants