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

v3 roadmap plan #705

Closed
bensheldon opened this issue Aug 19, 2022 · 1 comment
Closed

v3 roadmap plan #705

bensheldon opened this issue Aug 19, 2022 · 1 comment

Comments

@bensheldon
Copy link
Owner

bensheldon commented Aug 19, 2022

I wanted to write this out, mainly for my own thinking. And would love any feedback input on it.

The general plan that I have imagined in v3 is:

  1. Extracting and centralizing the Scheduler/Notifier/Poller/CronManager instances inside of a global (e.g. GoodJob.manager). Currently they either are loose inside of the CLI, or within individual adapters. Queue and thread configuration is global, so there should only be one set of these in the process.
  2. Extracting the majority of the logic from Adapter#enqueue, and moving that up to the global GoodJob.enqueue level (or maybe GoodJob::Job.enqueue or GoodJob::Execution.enqueue?). That reduces the size of the adapter, and unlocks...
  3. Creating something like GoodJob.bulk_enqueue for enqueuing multiple jobs at once. This isn't possible while all of the enqueue logic lives within the Adapter (because an application/jobs can have multiple GoodJob adapters). That unlocks...
  4. The cleaner interface for Batches with block enqueue (e.g. batch.jobs { SomeJob.perform_later; OtherJob.perform_later }
@bensheldon
Copy link
Owner Author

bensheldon commented Nov 27, 2023

I think all of these have been accomplished:

I didn't extract a central #enqueue method, but was able to accomplish the other issues without needing it.

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

No branches or pull requests

1 participant