Unique jobs queue option

[requaos]

Hey I was just tracing around and found this hard fork. Originally I hacked in these two features on top of your work in the soft fork of the go-workers lib, since I like handling errors rather than recovering from panics (which seems to be a common ruby/rails idiom).

I am planning on putting appropriate testing around these two features, but was wondering about getting some informal review of my implementation details.

If you are open to this, and honestly I am not really sure if it's okay because the original developer charges money for these features in his ruby gem, am I infringing on some kinda fuzzy line here?

Moving on, are you willing to give it a look over, and if so should I just open a tentative MR into your soft fork, or should I rebase my changelog on this repo and open an MR here for review?

[stefannegrea]

Hello Neil! We always welcome PRs against this repository and love community contributions. Please note this repository is licensed under MIT and your contributions will have to be licensed under the same terms. All contributions regardless of origin go through the same review process and we will gladly review your PRs too.

Without seeing the code, looks like you have two different and distinct features. Both would be very good additions to this framework. I recommend opening two PRs so we can review the changes independently.

[requaos]

Let us start with the unique jobs feature then: #27

[requaos]

The middlewares have been completely redesigned, where before the middleware just needed to satisfy an interface. I am refactoring the code I wrote for a throttled queue, because now the middlewares are pure functions. This feature relies on a ticker running in a separate goroutine. I am reconsidering the storage of this ticker, as it may end up in the worker and no longer be implemented as a middleware

[requaos]

For the throttled worker, I want to implement it as the number of executions per interval of time with consideration of concurrency selection. I am also considering a distribution option, which would be burst or smooth, where the worker exhausts its execution limit on a tick event or where the tick interval is divided across the number of executions so that the executions occur evenly throughout the period. Any thoughts?