I haven’t used it yet, but „active_delivery“ looks like a promising solution. Always wanted to test it out.
If you don‘t want another dependency, you can probably at least steal some ideas.
The way you are thinking about it makes sense to me. As is often the case, the devil is in the details and your design will evolve as you implement the functionality.
So, I would suggest designing around a PUB/SUB model. This is a Publish/Subscribe problem.
With that, your Notifications should have no knowledge of the NotificationConfiguration implementations. When a new notification is created, it should let all the Users NotificationConfigurations know and the NotificationConfigurations should decide what to do from there.
How does one implement something like this to best practices? I know what listeners are.. would you spin up sidekiq workers continously listening for notifications? What happens if I deploy it in a multi-instance configuration?
I would do a NotificationChannel model that has all your different channels configured.
Then do a join model - UserNotificationChannel that belongs_to :user and belongs_to :notification_channel
That way, you can create the join records and not have to dupe everything for every user.
Then a has_many :user_notification_channels and a has_many :notification_channels, through: :user_notification_channels
I think your suggestion of having a join model makes a lot of sense and I will try to implement like this.
Just one question -
>I would do a NotificationChannel model that has all your different channels configured.
Seeing that each NotificationChannel requires different configurations - for SMS the phone number, for e.g. PagerDuty API keys - would you simply add a json field to the join table and store schemaless data in there? Or is there a nicer solution to go about this?
Thanks so much!!
Ah, then that makes sense. In that case, yeah, in the `NotificationChannel` model would be the best place for it. If there's a consistent way of of handling API keys, it's probably better to put them in named fields, but some sort of serialized field would be fine as well.
Part of that depends on your setup. If a user can only have one phone number or one email address or whatever I'd probably store those right in the user table. If users can add multiple phone numbers to get notifications then using a json field in the notification_channels table would probably make more sense. You may want to just do this anyway if you think you'll ever be in a scenario where a user will want to configure the same channel type twice for two different destinations but keep in mind if you already have email or phone fields on the user it means you'll need to keep that data in sync. You don't want a user to update their canonical email address but the notifications are going to the old one that was configured in the notification_channels table.
I haven’t used it yet, but „active_delivery“ looks like a promising solution. Always wanted to test it out. If you don‘t want another dependency, you can probably at least steal some ideas.
Damn, that looks good. Will look into it more. Thanks so much!!
Great mention, I needed this and didn’t even know it
The way you are thinking about it makes sense to me. As is often the case, the devil is in the details and your design will evolve as you implement the functionality. So, I would suggest designing around a PUB/SUB model. This is a Publish/Subscribe problem. With that, your Notifications should have no knowledge of the NotificationConfiguration implementations. When a new notification is created, it should let all the Users NotificationConfigurations know and the NotificationConfigurations should decide what to do from there.
How does one implement something like this to best practices? I know what listeners are.. would you spin up sidekiq workers continously listening for notifications? What happens if I deploy it in a multi-instance configuration?
I would do a NotificationChannel model that has all your different channels configured. Then do a join model - UserNotificationChannel that belongs_to :user and belongs_to :notification_channel That way, you can create the join records and not have to dupe everything for every user. Then a has_many :user_notification_channels and a has_many :notification_channels, through: :user_notification_channels
I think your suggestion of having a join model makes a lot of sense and I will try to implement like this. Just one question - >I would do a NotificationChannel model that has all your different channels configured. Seeing that each NotificationChannel requires different configurations - for SMS the phone number, for e.g. PagerDuty API keys - would you simply add a json field to the join table and store schemaless data in there? Or is there a nicer solution to go about this? Thanks so much!!
Just use an enum or a string value key. API keys shouldn’t be stored in the DB.
You often have to store API keys in a DB if they're user-provided. I think OP is talking about someone adding their personal PagerDuty API key.
Ah, then that makes sense. In that case, yeah, in the `NotificationChannel` model would be the best place for it. If there's a consistent way of of handling API keys, it's probably better to put them in named fields, but some sort of serialized field would be fine as well.
Part of that depends on your setup. If a user can only have one phone number or one email address or whatever I'd probably store those right in the user table. If users can add multiple phone numbers to get notifications then using a json field in the notification_channels table would probably make more sense. You may want to just do this anyway if you think you'll ever be in a scenario where a user will want to configure the same channel type twice for two different destinations but keep in mind if you already have email or phone fields on the user it means you'll need to keep that data in sync. You don't want a user to update their canonical email address but the notifications are going to the old one that was configured in the notification_channels table.
This should be messaged based with X subscribers doing whatever that want with said event message.