This is really helpful. I might even use this in my next product.
One question though, I don't see a 'type' field in Notification class. Won't it be helpful if notification type can be saved to identify if the notification was an email notification or push notification and so on?
Thanks! In this last version, we decided to move all notions of channels (sms, push, etc.) to the classes. So each notification has a `trigger_name` linking it to the class form the @message decorator. So you can identify notifications that way, but you can't infer the channels they'll use.
The @message decorator allows transmissions scheduling logic not to have to be extended by your own code to focus on the actual Channel and Message logic. This way, the code is also magically indexing all the transmissions notification classes for when they need to be loaded asynchronously in the worker.
And if you meant that transmissions could have forced a couple of channel tasks, we would have missed the content of notification, the logic to check for validity, etc.
One question though, I don't see a 'type' field in Notification class. Won't it be helpful if notification type can be saved to identify if the notification was an email notification or push notification and so on?