Sidekiq VS Pundit

That depends on how the `maxmemory-policy` is configured, and queue systems based on Redis will tell you not to allow eviction. https://github.com/sidekiq/sidekiq/wiki/Using-Redis#memory (it even logs a warnings if it detects your Redis is misconfigured IIRC).

Sidekiq https://sidekiq.org/: This one started as an open source project, once it got enough traction, the developer made a premium version of it, and makes money by selling licenses to businesses.

Sidekiq will drop in-progress jobs when a worker crashes. Sidekiq Pro can recover those jobs but with a large delay. Sidekiq is excellent overall but it’s not suitable for processing critical jobs with a low latency guarantee.

https://github.com/sidekiq/sidekiq/wiki/Reliability

> I'm not sure feature withholding has traditionally worked out well in the developer space.

I think it's worked out well for Sidekiq (https://sidekiq.org). I really like their model of layering valuable features between the OSS / Pro / Enterprise licenses.

I was studying Sidekiq's page on rate limiters. The first type of rate limiting mentioned is the concurrent limiter: only n tasks are allowed to run at any point in time. Note that this is independent of time units (e.g. per second), or how long they take to run. The only limitation is the number of concurrent tasks/requests.

Uses Sidekiq's "fake" testing mode which will allow you to run the jobs explicitly

The code above isn't idempotent. If you run it twice, it will create two copies, which is probably not what you intended. Why is this important? Because most backend job processors like Sidekiq don't make any guarantees that your jobs will run exactly once.

There are several workarounds for this, like the magnificent Acidic Job gem or Sidekiq Pro/Enterprise features around enhanced reliability and unique jobs. Still, if they occur, bugs related to missing jobs and/or job idempotency are hard to track down and even harder to fix.

https://github.com/varvet/pundit Popular open-source Ruby library focused around the notion of policies, giving you the freedom to implement your own approach based on that.

Can you expand a little? Here's some technical background on what we're doing:

We have our own database of every version of every rubygems package alongside its runtime dependencies (like you see at https://rubygems.org/gems/pundit).

Then we parse your Gemfile and Gemfile.lock. We use the Gemfile to figure out gem group and pinned requirements (we run turn your Gemfile into a ruby AST since Gemfiles can be arbitrary ruby code; we use bundler's APIs to parse your Gemfile.lock). This gives us all of the dependencies your rely on.

Then we let you choose one or more package that you want to upgrade and the version you want to target (let's say Rails 7.0.4.3).

Now we have [your dependencies and their current versions], [target rails version], [all of the runtime dependency constraints of these gems]. We run this through a dependency resolution algorithm (pubgrub). If it resolves then you're good to upgrade to that version of Rails without changing anything.

If this fails to resolve, it's because one or more of your current dependencies has a runtime restriction on rails (or another indirect gem being pulled in by the new rails version). This is where the optimization part comes in. The problem becomes "what is the optimal set of versions of all your dependencies that would resolve with the next version of Rails". Currently we solve for this set trying to optimize for the fewest upgrades. As our dataset of breaking changes gets better we'll change that to optimizing for the "lowest effort".

Happy to elaborate.

For authorization, I'm going back and forth with Pundit and CanCanCan

Expressing authorization rules can be a bit challenging with the use of other authorization gems, such as pundit or cancancan. The resource_policy gem provides a more concise and expressive policy definition that uses a simple block-based syntax that makes it easy to understand and write authorization rules for each attribute.

https://github.com/varvet/pundit Popular open-source Ruby library focused around the notion of policies, giving you the freedom to implement your own approach based on that.

PS If you do mobile / web work (or something else with "detached" UI), I find that declarative access control rules are far superior to imperative ones, because they can be serialized and shipped over the wire. For example, backend running cancancan can be easily send the same rules to casl on the frontend, while if you used something like pundit to secure your backend, you either end up re-implementing it in the frontend, or sending ton of "canEdit" flags with every record.

You can use a combination of an authorization gem (https://github.com/varvet/pundit) and decorators (https://www.rubyguides.com/2018/04/decorator-pattern-in-ruby/) if you want to extend functionality based on their roles.

Use Action Policy or Pundit, and write tests for your policies. Authz is worth testing with near complete coverage.

Pundit: Pundit is a gem that uses simple Ruby objects, and it is probably the simplest policy gem we will cover. Is simple to use, has minimal authorization, and is similar to using pure Ruby. With 7.3k stars on GitHub, it is currently the most popular policy gem.