Push: why not push as a mode and fcm as a vendor?

Hi there,

I've been working on a React Native based mobile app to receive push notifications from iris and allow viewing and acking open incidents. We're looking into making this app available publicly with configurable SAML and iris endpoints (for testing), and considering open sourcing it to enable push if there is demand.

When I started this some time ago (https://github.com/linkedin/iris/issues/355) it seemed to make most sense to add push in the mode table, which allows to make push part of escalation plans, configuring per-user priority modes and storing the device token in the target_contact table and all the other goodness available with other modes. Then creating an iris_firebase vendor (with supports = frozenset([PUSH_SUPPORT]) seems natural and allow future extensibility with other push vendors.

However, coming back to see your progress on push implementation I see that you have taken a very different route in implementing it, instead coupling push to a global twilio and/or slack configuration (AFAICT). Would you mind explaining why this choice was made instead of using iris modes and vendors?

Of course, I imagine you might be already depending on your implementation choices and it could be that it's not possible for you to reconsider this implementation choice, but before taking on the burden of maintaining a fork I thought I would ask if you would be open to an implementation that uses modes and vendors?

Very best,

Jun

Review the existing push implementation and its global Twilio/Slack configuration, then compare it with Iris modes, vendors, target_contact, and escalation plans described here. A useful outcome is a maintainer decision explaining the trade-offs and whether push should be modeled as a mode with an FCM vendor.