I understand that the Server Events feature is used to notify external clients, but is it possible to use within my own service as well or should I use something else for this use case:
In my service I do a lot of standard stuff (adding, deleting, updating information). I want my users to be able to subscribe to sms notifications of these events. So I thought that using ServerEvents to notify from my different service methods and then make a global named event receiver that sent the sms would be a good idea.
But it feels like there is something simpler, that I’m using an external feature to do something internal.
What would be the pros/cons of using this approach? Is it better to create some kind of request filter to acheive my goal?
ServerEvents is an impl of SSE that’s just a wrapper around a long-lived HTTP connection used to send notifications to connected clients, as a result the impl is tightly coupled to managing long-lived HTTP Client connections so it’s not re-usable for anything else.
Sounds like you’re after a custom Pub/Sub solution. I don’t know anything about your architecture, e.g. how clients subscribe, if clients are desktop apps, if the subscriptions can be transient or need to durable, whether you have load-balanced app servers, etc. But I’d first be looking to see if there’s an existing Pub/Sub solution that fits your needs, e.g. integrates with SMS. Otherwise look at the different generic Pub/Sub solutions, for transient connections to Desktop Apps I’d look at Redis Pub/Sub, for durable connections I’d look at Pub/Sub features of Rabbit MQ. If you’re hosting on a cloud, explore whether they already have suitable solutions. Otherwise if you need a bespoke solution, I’d aim for the simplest solution that can work, which might just be a table containing a list of user subs containing events they’re interested in, then on each event send it to the users that have registered for the event - which I’d run in a bg thread or out-of-proc.