Create demo for <amp-web-push> on ampbyexample.com

[demianrenzulli]

amp-web-push doesn't have its own demo at ampbyexample.com, and since its implementation involves several steps, it can be quite useful for developers (specially those working on full AMP Sites).

The demo can follow a similar approach as the Lab at the PWA instructor lead course, by showing how to implement the subscription to the Notification service, the retrieval of the token, the logic on the SW side, and, by showing the user how to send notification with cURL to test the implementation.

[demianrenzulli]

I'm taking this one.

[sebastianbenz]

Thanks for looking into this Demian! Would it be possible to add a button to the page that'll send a notification? For example, the button could simply trigger a backend call which then sends the notification.

[demianrenzulli]

Hi Sebastian, yes! We can add that functionality to the page as well.

Which of these options are you thinking about?

• Somehow sending as a parameter the token (endpoint URL), to that backend call, so the server can take it and send the push event.
• Persisting the token on the backend, so it can be used several times. For this option: should we follow the approach that another demo has used to persist user related information?

Maybe you have a different solution in mind.

[sebastianbenz]

Hm, I'd prefer to avoid storing user data in the backend. Crazy idea: could we trigger the push notification from within a service worker? Button will trigger a request, which gets intercepted by the service worker which then triggers the push.

[demianrenzulli]

So, we can experiment with something like:

1. Storing the token/keys on IndexedDB when subscription takes place.
2. Intercepting the fetch request on the SW for the backend call issued by the "Notify me!" button.
3. As a result, send a post request to the endpoint URL generated with the token:

"https://android.googleapis.com/gcm/send/fYFVeJQJ2CY:APA91bGrFGRmy-sY6NaF8atX11K0bKUUNXLVzkomGJFcP-lvne78UzYeE91IvWMxU2hBAUJkFlBVdYDkcwLG8vO8cYV0X3Wgvv6MbVodUfc0gls7HZcwJL4LFxjg0y0-ksEhKjpeFC5P" --request POST --header "TTL: 60" --header "Content-Length: 0" --header "Authorization: key=AAAANVIuLLA:APA91bFVym0UAy836uQh-_S8sFDX0_MN38aZaxGR2TsdbVgPeFxhZH0vXw-E99y9UIczxPGHE1XC1CHXen5KPJlEASJ5bAnTUNMOzvrxsGuZFAX1_ZB-ejqBwaIo24RUU5QQkLQb9IBUFwLKCvaUH9tzOl9mPhFw"

Would that work?

[sebastianbenz]

That was my thinking - not sure if it works :-)

[demianrenzulli]

Will try and let you know!

[demianrenzulli]

Update:

• I could make this work on top of the PWA Webpush Codelab.
• Then, integrated it with this amp-web-push example.

The problem I found was not with the approach itself, of using the SW to store tokens, retrieve them, and trigger the Webpush, after a the user clicks on a button, but on the fact that to make this work with VAPID, composing the push request inside the SW is not as simple as it was with FCM (I guess for that reason, there are so many Web Push libraries for backend).

I wonder if the right approach, would be to reuse the web-push-lib for Node, inside the SW, maybe re-writing it to be used outside of Node. The only function we would need is sendNotification, but I'm seeing it calls others as well.

If we were not using VAPID, this would work by just composing a POST request, but the old protocol is proprietary, and no longer recommended, and, for some reason, amp-web-push threw an error when I tried to use it (it worked well with the PWA plan sample shared earlier).

[demianrenzulli]

If you think that adding all the VAPID webpush logic to the SW might be too complex, another thing we could do is to use the SW only to persist and retrieve the key, and send a request to an ampbyexample endpoint, (passing those keys) so the web push request can be made from there (here's a library for Go).

That way, we use IndexedDB as our database, avoiding to use one on backend, but still make the server deal with the details of how to compose and send a web push request.