Check out a free preview of the full Progressive Web Applications and Offline course:
The "Structure of PushSubscription" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

Mikes shows showing PushSubscription code and underscores the importance of using a library for sending notifications. Mike takes questions from students.

Get Unlimited Access Now

Transcript from the "Structure of PushSubscription" Lesson

[00:00:00]
>> Mike North: Here's what a PushSubscription looks like. It's got an endpoint and some keys. The end point as you might suspect tells us that this is probably from Chrome or from an Android device maybe, right? Because that's telling us where to send this thing, it's sort of part of the routing.

[00:00:18] The key section here helps to push server understand that we do have permission to send this user a notification. So you're gonna need to send both of those along for the ride. Now, this is all done for you behind the scenes. The server side is not something we're going to tackle today.

[00:00:38] But we're gonna deal with kind of the typical front end responsibility, which is asking for permission, getting that PushSubscription, sending it to an API so it's stored, and then the API is gonna send notifications for you. It's actually attempting to send notifications all along, we're just not setup to receive them yet.

[00:00:59]
>> Mike North: So, keep in mind that users may have more than one push subscription per browser. You might see that you have duplicate messages coming in, and we'll talk about different ways of combating that. That's like for now just know that you could always blow away your development database and start over and like you will be clean again.

[00:01:21] And that development database is in db/development.sqlite. When you start your server again a new one will be created for you presided with all of the data.
>> Mike North: So you do not want to do the server-side work yourself. The reason is that if you've ever built something like this where you're either doing native push notifications or sometimes if you've ever tried to integrate with something like Intercom, while Intercom is an excellent product.

[00:01:55] It's inherently hard when you're passing stuff off to another service, something may go wrong inside that service and you're not watching their logs, you can't see what's going on. You kind of throw stuff off into a black hole and hope that something happens on the other end as a result of that.

[00:02:15] This is why you want to use a library for this, they can validate stuff before it's sent out. You don't wanna be just manually crafting HTTP requests to talk to the push server directly.
>> Speaker 2: So,
>> Speaker 2: Could you talk about the flow a little bit? Are we talking about this back-end API actually talking to the, let's assume that there's a Mozilla or the Google's PushService.

[00:02:46] And then that service is actually pushing that subscription over to the browser, and the service worker is listening to it?
>> Mike North: Exactly.
>> Speaker 2: Is that what you meant?
>> Mike North: So here's the flow again, and it's good to make sure we make this point clearly. The first part of the flow is we request permission, we basically ask for a subscription, for this push subscription object.

[00:03:14] On the critical path to that promise resolving is the user must click, yes, I wish to allow like the site to send me stuff, right? It reject if they say no. So once we have those subscription objects, just those JSON objects with the keys in the endpoint. We use those as a mechanism to send data to this PushService.

[00:03:36] And the PushService sends it to the appropriate browser to the appropriate service worker and an event will be fired on that service worker. Similar to the fetch event that we've been working with, but it's just a push event. So you get it there, you get a push event, does that make sense?

[00:03:56] All right, let me go forward.
>> Mike North: Great, so use a library, here's how we receive the message. Looks a lot like fetch AddEventListener, push and there's the event. And this push event has a property on it called data and that's where you'll find your push message data. You'll note that I can call data.text on it, it looks a lot like the way we process response objects, right?

[00:04:29] .text, .json, the difference is this is not promise based, it's synchronous and there is no restriction on using it more than once. These aren't like, you don't have to do all of this chaining together. But a similar set of methods are available, so you can decode it into JSON if you wish.