- 1.3k times
I have briefly looked at this before, but haven't actually implemented it myself either. I am thinking about making it available for the next version of Ozzu. You could use a service to do it like you mentioned, but it is also possible to handle it all yourself. This resource goes into great depth:
There are three main steps to get this to work:
- The API call from your server back-end that triggers the push message to the subscriber.
If I were to guess, the second step is probably the one where you would get hung up on. The key piece of information here is that each browser can use any push service they want, it's something developers have no control over. You just need to keep track of the endpoint to use for that user for when you do your API call.
The good news is that it seems like any push service will utilize the Web Push Protocol which is an IETF standard that defines how you make an API call to a push service.
So for each user who subscribes to your push events, you would need to keep track of each user and what push endpoint URL the web browser is using. Then when you push an event you would utilize the API endpoint for that user. The push service will then either deliver the notification immediately if the user is online, or will store the message until they come online to deliver the message.
That should be it in a nutshell. There are quite a few steps involved though, and I left things out such as when you call subscribe how you pass in your public application server key that is used later to verify that it is you who is sending the push message to prevent anyone else from sending messages to an application's users.
This doesn't look like anything you can set up quickly, you are going to have to learn the entire process if you want to implement it yourself.