-
Notifications
You must be signed in to change notification settings - Fork 188
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
Comments
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. |
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? |
@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 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. |
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. |
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. |
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) |
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). |
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! |
Great. Will try it out after some other changes in the codebase calm down. |
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. |
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.
The text was updated successfully, but these errors were encountered: