 How do you send a message from your web server to one user or lots of users? How can you do that in a way that's fast, reliable, and secure, and what if the user's browser is closed? Well, on the web, there's now a way to do that using standard APIs and services integrated with mobile and desktop platforms. So let's see how to send push messages from your server and handle incoming messages on your client web app. Now, each browser manages push notifications through its own system called a push service. When a user grants permission for push on your site, you subscribe them to the browser's push service. This creates a subscription object that includes a public key to enable messages to be encrypted and an endpoint URL for the browser's push service, which is unique for each user. From your server, you send push messages to this URL encrypted with the public key, and the push service forwards the message to the right client, device, and browser. The service worker will be woken up to handle incoming push messages when a push event is fired, and this allows your app to react to push messages, for example, by displaying a push notification using serviceworkerregistration.shownotification. Now, the great thing is your app doesn't need to listen to or poll for messages, and the browser doesn't even need to be open. All the work is done under the hood as efficiently as possible by the browser and the operating system. This is great for saving battery and CPU usage. So let's go through that step by step. In the app's main JavaScript, call pushmanager.subscribe on the serviceworkerregistration object. Get the subscription object and convert it to JSON. Get the endpoint URL and public key and save this to your server, for example, by using a fetch request. Send the message payload from your server to the endpoint URL encrypted with the public key. When the operating system of the user's device receives a push message, it passes that onto the browser, which fires a push event in the serviceworker, which you can handle in a handler function. In a push event handler, you can get the data from the message to display a notification. The push API allows a user to subscribe to messages sent from your app server via the push service used by the browser. Subscribing is done in the JavaScript for the page. Responding to push events, for example, by displaying a notification, is done in the serviceworker. Just to repeat, subscribing to the push service and getting the subscription object happen in the JavaScript for the page. First, we check if the user is already subscribed and update the page UI accordingly. If the user isn't already subscribed, prompt them to subscribe. Now, if they are already subscribed, you should still update the server with the latest subscription, since that may have been changed by the push service. When the user grants permission for push on your site, you subscribe them to the browser's push service. As I said before, this creates a subscription object that contains the endpoint URL of the push service, which is different for each browser, along with a public key for encryption. You send the subscription object for the user to the server and save it. And before you subscribe a user, check if you already have a subscription object for them. If you don't have the object, update the UI to prompt the user to enable push notifications. If you do have the subscription object, update your server database with the latest subscription data. The ready property of the service worker defines whether a service worker is ready to control a page or not. It returns a promise, which resolves to a service worker registration object when the service worker becomes active. The get subscription function returns the subscription object or undefined if it doesn't exist. You need to perform this check every time the user accesses your app, because it is possible for subscription objects to change during their lifetime. This is the process of subscribing to the push service. Register the service worker from the page, main.js. This request goes to the user agent, the browser. And the browser returns the service worker registration object. Use the service worker registration object to access the push manager API. And from that request to subscribe to the push service. This request is passed on to the push service. And the push service returns the subscription object, which includes an endpoint URL and a public key. Save the subscription object data to your server and then send push messages from your server to the endpoint URL encrypted with the public key. Now, as I've said, before you send notifications, the user must subscribe to a push service. You call pushmanager.subscribe on the service worker registration object to subscribe. The resulting push subscription object includes all the information that the application needs to send a push message, an endpoint and the encryption key needed for sending data. Each subscription is unique to a service worker. The endpoint for the subscription is a unique URL. That endpoint is all that is necessary to send a message to a client using your application. The endpoint URL therefore needs to be kept secret or other applications might be able to send push messages to your application. Here's an example of the subscription object. This is the object returned from the push service when you call reg.pushmanager.subscribe. The subscription object has two parts. The first part is an endpoint URL, the address on the push service to send messages. This includes an ID that enables the push service to send a message to the correct client and service worker. The second part of the subscription object is the keys property. Now for the geeks out there, the P256DH key is an elliptic curve Diffie Hellman, ECDH, public key for message encryption. If you haven't heard of this before, do check it out. This is a really, really clever piece of engineering. Anyway, the auth key is an authentication secret that an application server uses to authenticate messages. These keys are used by your application server to encrypt and authenticate messages for the push subscription. So users and websites can trust each other's identity. Let's see how the process of sending a message is done. The server generates a message, encrypts it with the public key and sends it to the endpoint URL from the subscription object. The URL contains the address of the push service along with a subscription ID which allows the push service to identify the client to receive the message. The message is received by the push service, which routes it to the right client. So let's go through this one more time. A backend service on your server sends a message to a push service using the endpoint URL from the subscription object you got using JavaScript on the client. The message is encrypted with the public key from the subscription. The push service then uses subscription IDs encoded in the endpoint URL to send the message to the right client. The push event is picked up by the service worker and the service worker gets the data from the message and displays a notification. In this example, we're using Google's web push library to send a push message from a Node.js server. Chrome requires that we set the API key from our project on Firebase. Now, not seen in this code, we get the subscription object from the database and set it to equal a variable called push subscription. The TTL value in the options object is actually pretty clever. This specifies the time in seconds that the push service should keep trying to deliver the message. Now, this is really important to set correctly. Some messages have a short life. Some may be valid for several hours or more. We pass in the subscription object payload and options object to send notification. So that's the whole process. Send messages from your server to your users using web standard APIs. Thanks for listening. In the next episode, you'll find out how to make sure this whole process is secure.