0

I am hoping this is not too off topic for a post here.

I have an asp.net webAPI service, which provides a number of routes to get near realtime data (ie within say 10 seconds), which required the client application to poll for changes.

I am investigating on which technology would be best to add an "opt in" push notification service, which just pushes "thin" payloads to tell the client application it is now time to call the existing REST route for an update. This way, the push payload is small, and does not contain any security sensitive data (it still gets this using the existing REST security infrastructure)

Cloud based messaging

Previously, I have been told that, for a Mobile application, I should use something like Firebase cloud messaging, or some other messaging service, however this does not seem like the right solution for "subscription based notifications" I am talking about here. I can certainly see this would be useful, if the client is on either iOS or Android device, and wanted messages/notifications/alarms (etc), which could also work when the application is not running, but this does not seem like the right thing to use of these notifications of changed data (which may be happening all the time, sometimes every 5 seconds). Also, I do not want to only target these mobile devices, but also, for example either a web or desktop application, which may also use the same REST service

Other technologies

I have seen mention of Web sockets, or, in the case of asp.net, the option to use SignalR (which will wrap the web sockets, with fallback). SignalR looks good, but my worry is the availability of client libraries for non web / Windows applications (eg iOS, Android). I am also looking at Rest Hooks. These look interesting, but I can't quite see what the actual "push mechanism" is; it almost looks like they need to POST to the subscriber using HTTP, which means the subscriber has to also act as a "server endpoint".

Just after any thoughts / best practices on this, or what others have used?

In particular, (the verification or otherwise), that for this use case, using cloud based messaging is not the right thing to use due to the frequency of these push notifications (ie something where my server gets to the application via another 3rd party service which pushes to the device/application)

Thanks in advance for any suggestions!

peterc
  • 6,921
  • 9
  • 65
  • 131
  • Actually for web based projects I would go with service-worker. If you want to target every platform, then Azure Notification Hub is an opportunity. If you don't need to receive notifications in background, then a message queue like RabbitMQ could do it – momo Jun 07 '18 at 07:41

1 Answers1

0

Signalr is an option

There are some libraries which you can use in iOS and android. I suggest you to read once https://visualstudiomagazine.com/articles/2013/11/01/how-to-use-signalr-in-ios-and-android-apps.aspx (its a bit older, but on the point)

Some alternatives :

Pusher (https://pusher.com/)

Socket.IO (https://socket.io/)

To discuss:

  • Why you will only send a thin payload whith signalr? I see no benefit for that.
  • Why "using cloud based messaging is not the right thing"? I do not understand your arguments but I do not know how your application looks like.
Stephu
  • 3,236
  • 4
  • 21
  • 33
  • Thanks for the info. Point 1The thin payload is just meant to be a more of a subscription/notification to indicate a routes data has changed. The data could be large. At the backend the changes may, sometimes, come very frequently, and other time not so much. The frequently, I means many per second, and here I would just send a single notification at the end (or after some time period) just to tell the client the data has changed. It then uses existing REST call to get the data, whenever it is ready to. Point2 - the cloud solns would be maybe be too slow?? – peterc Jun 08 '18 at 01:11