noticed VS Pundit

These kinds of generators exist in the Noticed gemand within Rails itself via the various rails scaffold commands and even the rails new command, which is a Rails generator itself.

The Noticed gem makes developing notifications fantastically easy by providing a database-backed model and pluggable delivery methods for your Ruby on Rails application. It comes with built-in support for mailers, websockets, and a couple of other delivery methods.

I highly recommend the noticed gem for sending notifications. It supports a bunch of different delivery methods, including email, and it's really well documented.

Currently, CircuitVerse uses activity_notification gem for the Notifications but the gem is not maintained any more and the notification page is very lagging. So we decided to replace the gem and we found noticed gem by chris oliver of Gorails.

Rails developers that need to add a notification system to their application often turn to Noticed. Noticed is a gem that makes it easy to add new, multi-channel notifications to Rails applications.

Have you looked at Caffinate or noticed ?

noticed for notifications

> I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it.

It's way more involved than inserting an auth token header into an HTTP request and calling some API endpoint.

For example, what about verifying webhooks? The official libraries for Stripe (Python, Ruby, Node, PHP, Go, JS, etc.) deal with this for you.

But with Elixir, you're on your own. This is very low level code to have to deal with and it's extremely important you get it right.

You're left having to parse Stripe's specification on this and then implement the code yourself in Elixir. It's so tricky and involved that the Dashbit company (the creator of Elixir and members of the core team work there) wrote a blog post on it at https://dashbit.co/blog/how-we-verify-webhooks.

But before a few months ago that blog post didn't exist. Also this isn't the only thing you'll have to do yourself when it comes to interacting with Stripe.

Then you'll have to do similar things for other payment providers all which are different in a lot of ways, but with Rails you have the combination of having official Ruby clients from those payment providers and even the Pay gem which lets you support payments from multiple providers. That could easily be a few months of dev time just for that abstraction alone if you had to go about that from scratch and your implementation wouldn't have any track record until you start using it and ironing out the bugs from real world experience.

> Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them

Don't take this the wrong way but this seems to be the mindset of almost everyone I chatted with when it comes to Elixir. When someone asks how to do something, the answer is it's trivial or easy to implement but there's never any examples posted on how to do it.

In my mind trivial or easy means I can sit down in maybe a few hours or a day and write a production ready solution, complete with tests and have it work exactly how I want without running into any major roadblocks.

I'd be curious to see how you would implement https://github.com/excid3/noticed or https://github.com/excid3/pay. Based on your responses of saying these things are easy I'm guessing you've written large apps with Phoenix where you've developed features like this in a production app? It would be fantastic if you could post some code examples or a blog post on how you went about this. Not just to answer my specific question but I'm sure the community would appreciate having concrete examples of how it's done. This way more folks would use the framework.

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.

As an example of how to default to deny, consider a Ruby on Rails app (as we tend to do). The primary way a user interacts with the app is through API endpoints powered by controllers. We use Pundit, a popular authorization library for Rails, to manage user permissions.

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.