Implementing Push Notifications: The Back End

Filed in Web Design | Web Development Leave a comment

In the first part of this series we set up the front end with a Service Worker, a `manifest.json` file, and initialized Firebase. Now we need to create our database and watcher functions.

Article Series:

  1. Setting Up & Firebase
  2. The Back End (You are here)

Creating a Database

Log into Firebase and click on Database in the navigation. Under Data you can manually add database references and see changes happen in real-time.

Make sure to adjust the rule set under Rules so you don’t have to fiddle with authentication during testing.

{ "rules": { ".read": true, ".write": true }

Watching Database Changes with Cloud Functions

Remember the purpose of all this is to send a push notification whenever you publish a new blog post. So we need a way to watch for database changes in those data branches where the posts are being saved to.

With Firebase Cloud Functions we can automatically run backend code in response to events triggered by Firebase features.

Set up and initialize Firebase SDK for Cloud Functions

To start creating these functions we need to install the Firebase CLI. It requires Node v6.11.1 or later.

npm i firebase-tools -g

To initialize a project:

  1. Run firebase login
  2. Authenticate yourself
  3. Go to your project directory
  4. Run firebase init functions

A new folder called `functions` has been created. In there we have an `index.js` file in which we define our new functions.

Import the required Modules

We need to import the Cloud Functions and Admin SDK modules in `index.js` and initialize them.

const admin = require('firebase-admin'), functions = require('firebase-function') admin.initializeApp(functions.config().firebase)

The Firebase CLI will automatically install these dependencies. If you wish to add your own, modify the `package.json`, run npm install, and require them as you normally would.

Set up the Watcher

We target the database and create a reference we want to watch. In our case, we save to a posts branch which holds post IDs. Whenever a new post ID is added or deleted, we can react to that.

exports.sendPostNotification = functions.database.ref('/posts/{postID}').onWrite(event => { // react to changes }

The name of the export, sendPostNotification, is for distinguishing all your functions in the Firebase backend.

All other code examples will happen inside the onWrite function.

Check for Post Deletion

If a post is deleted, we probably shouldn’t send a push notification. So we log a message and exit the function. The logs can be found in the Firebase Console under Functions ? Logs.

First, we get the post ID and check if a title is present. If it is not, the post has been deleted.

const postID = event.params.postID, postTitle = if (!postTitle) return console.log(`Post ${postID} deleted.`)

Get Devices to show Notifications to

In the last article we saved a device token in the updateSubscriptionOnServer function to the database in a branch called device_ids. Now we need to retrieve these tokens to be able to send messages to them. We receive so called snapshots which are basically data references containing the token.

If no snapshot and therefore no device token could be retrieved, log a message and exit the function since we don’t have anybody to send a push notification to.

const getDeviceTokensPromise = admin.database() .ref('device_ids') .once('value') .then(snapshots => { if (!snapshots) return console.log('No devices to send to.') // work with snapshots }

Create the Notification Message

If snapshots are available, we need to loop over them and run a function for each of them which finally sends the notification. But first, we need to populate it with a title, body, and an icon.

const payload = { notification: { title: `New Article: ${postTitle}`, body: 'Click to read article.', icon: '' }
} snapshots.forEach(childSnapshot => { const token = childSnapshot.val() admin.messaging().sendToDevice(token, payload).then(response => { // handle response }

Handle Send Response

In case we fail to send or a token got invalid, we can remove it and log out a message.

response.results.forEach(result => { const error = result.error if (error) { console.error('Failed delivery to', token, error) if (error.code === 'messaging/invalid-registration-token' || error.code === 'messaging/registration-token-not-registered') { childSnapshot.ref.remove()'Was removed:', token) } else {'Notification sent to', token) } }

Deploy Firebase Functions

To upload your `index.js` to the cloud, we run the following command.

firebase deploy --only functions


Now when you add a new post, the subscribed users will receive a push notification to lead them back to your blog.

GitHub Repo Demo Site

Article Series:

  1. Setting Up & Firebase
  2. The Back End (You are here)

Implementing Push Notifications: The Back End is a post from CSS-Tricks

, , ,

Implementing Push Notifications: Setting Up & Firebase

Filed in Web Design | Web Development Leave a comment

You know those the little notification windows that pop up in the top right (Mac) or bottom right (Windows) corner when, for example, a new article on our favorite blog or a new video on YouTube was uploaded? Those are push notifications.

Part of the magic of these notifications is that they can appear even when we’re not currently on that website to give us that information (after you’ve approved it). On mobile devices, where supported, you can even close the browser and still get them.

Article Series:

  1. Setting Up & Firebase (You are here!)
  2. The Back End (Coming soon!)
Notification on Mac via Chrome
Push notification on a Mac in Chrome

A notification consists of the browser logo so the user knows from which software it comes from, a title, the website URL it was sent from, a short description, and a custom icon.

We are going to explore how to implement push notifications. Since it relies on Service Workers, check out these starting points if you are not familiar with it or the general functionality of the Push API:

What we are going to create

Preview of the our push notification demo website

To test out our notifications system, we are going to create a page with:

  • a subscribe button
  • a form to add posts
  • a list of all the previously published posts

A repo on Github with the complete code can be found here and a preview of the project:

View Demo Site

And a video of it working:

Gathering all the tools

You are free to choose the back-end system which suits you best. I went with Firebase since it offers a special API which makes implementing a push notification service relatively easy.

We need:

In this part, we’ll only focus on the front end, including the Service Worker and manifest, but to use Firebase, you will also need to register and create a new project.

Implementing Subscription Logic


We have a button to subscribe which gets enabled if 'serviceWorker' in navigator. Below that, a simple form and a list of posts:

<button id="push-button" disabled>Subscribe</button> <form action="#"> <input id="input-title"> <label for="input-title">Post Title</label> <button type="submit" id="add-post">Add Post</button>
</form> <ul id="list"></ul>

Implementing Firebase

To make use of Firebase, we need to implement some scripts.

<script src=""></script>
<script src=""></script>
<script src=""></script>

Now we can initialize Firebase using the credentials given under Project Settings ? General. The sender ID can be found under Project Settings ? Cloud Messaging. The settings are hidden behind the cog icon in the top left corner.

firebase.initializeApp({ apiKey: '<API KEY>', authDomain: '<PROJECT ID>', databaseURL: 'https://<PROJECT ID>', projectId: '<PROJECT ID>', storageBucket: '<PROJECT ID>', messagingSenderId: '<SENDER ID>'

Service Worker Registration

Firebase offers its own service worker setup by creating a file called `firebase-messaging-sw.js` which holds all the functionality to handle push notifications. But usually, you need your Service Worker to do more than just that. So with the useServiceWorker method we can tell Firebase to use our own `service-worker.js` file as well.

Now we can create a userToken and a isSubscribed variable which will be used later on.

const messaging = firebase.messaging(), database = firebase.database(), pushBtn = document.getElementById('push-button') let userToken = null, isSubscribed = false window.addEventListener('load', () => { if ('serviceWorker' in navigator) { navigator.serviceWorker.register('') .then(registration => { messaging.useServiceWorker(registration) initializePush() }) .catch(err => console.log('Service Worker Error', err)) } else { pushBtn.textContent = 'Push not supported.' } })

Initialize Push Setup

Notice the function initializePush() after the Service Worker registration. It checks if the current user is already subscribed by looking up a token in localStorage. If there is a token, it changes the button text and saves the token in a variable.

function initializePush() { userToken = localStorage.getItem('pushToken') isSubscribed = userToken !== null updateBtn() pushBtn.addEventListener('click', () => { pushBtn.disabled = true if (isSubscribed) return unsubscribeUser() return subscribeUser() })

Here we also handle the click event on the subscription button. We disable the button on click to avoid multiple triggers of it.

Update the Subscription Button

To reflect the current subscription state, we need to adjust the button’s text and style. We can also check if the user did not allow push notifications when prompted.

function updateBtn() { if (Notification.permission === 'denied') { pushBtn.textContent = 'Subscription blocked' return } pushBtn.textContent = isSubscribed ? 'Unsubscribe' : 'Subscribe' pushBtn.disabled = false

Subscribe User

Let’s say the user visits us for the first time in a modern browser, so he is not yet subscribed. Plus, Service Workers and Push API are supported. When he clicks the button, the subscribeUser() function is fired.

function subscribeUser() { messaging.requestPermission() .then(() => messaging.getToken()) .then(token => { updateSubscriptionOnServer(token) isSubscribed = true userToken = token localStorage.setItem('pushToken', token) updateBtn() }) .catch(err => console.log('Denied', err)) }

Here we ask permission to send push notifications to the user by writing messaging.requestPermission().

The browser asking permission to send push notifications.

If the user blocks this request, the button is adjusted the way we implemented it in the updateBtn() function. If the user allows this request, a new token is generated, saved in a variable as well as in localStorage. The token is being saved in our database by updateSubscriptionOnServer().

Save Subscription in our Database

If the user was already subscribed, we target the right database reference where we saved the tokens (in this case device_ids), look for the token the user already has provided before, and remove it.

Otherwise, we want to save the token. With .once('value'), we receive the key values and can check if the token is already there. This serves as second protection to the lookup in localStorage in initializePush() since the token might get deleted from there due to various reasons. We don’t want the user to receive multiple notifications with the same content.

function updateSubscriptionOnServer(token) { if (isSubscribed) { return database.ref('device_ids') .equalTo(token) .on('child_added', snapshot => snapshot.ref.remove()) } database.ref('device_ids').once('value') .then(snapshots => { let deviceExists = false snapshots.forEach(childSnapshot => { if (childSnapshot.val() === token) { deviceExists = true return console.log('Device already registered.'); } }) if (!deviceExists) { console.log('Device subscribed'); return database.ref('device_ids').push(token) } })

Unsubscribe User

If the user clicks the button after subscribing again, their token gets deleted. We reset our userToken and isSubscribed variables as well as remove the token from localStorage and update our button again.

function unsubscribeUser() { messaging.deleteToken(userToken) .then(() => { updateSubscriptionOnServer(userToken) isSubscribed = false userToken = null localStorage.removeItem('pushToken') updateBtn() }) .catch(err => console.log('Error unsubscribing', err))

To let the Service Worker know we use Firebase, we import the scripts into `service-worker.js` before anything else.


We need to initialize Firebase again since the Service Worker cannot access the data inside our `main.js` file.

firebase.initializeApp({ apiKey: "<API KEY>", authDomain: "<PROJECT ID>", databaseURL: "https://<PROJECT ID>", projectId: "<PROJECT ID>", storageBucket: "<PROJECT ID>", messagingSenderId: "<SENDER ID>"

Below that we add all events around handling the notification window. In this example, we close the notification and open a website after clicking on it.

self.addEventListener('notificationclick', event => { event.notification.close() event.waitUntil( self.clients.openWindow('') )

Another example would be synchronizing data in the background. Read Google’s article about that.

Show Messages when on Site

When we are subscribed to notifications of new posts but are already visiting the blog at the same moment a new post is published, we don’t receive a notification.

A way to solve this is by showing a different kind of message on the site itself like a little snackbar at the bottom.

To intercept the payload of the message, we call the onMessage method on Firebase Messaging.

The styling in this example uses Material Design Lite.

<div id="snackbar" class="mdl-js-snackbar mdl-snackbar"> <div class="mdl-snackbar__text"></div> <button class="mdl-snackbar__action" type="button"></button>
import 'material-design-lite' messaging.onMessage(payload => { const snackbarContainer = document.querySelector('#snackbar') let data = { message: payload.notification.title, timeout: 5000, actionHandler() { location.reload() }, actionText: 'Reload' } snackbarContainer.MaterialSnackbar.showSnackbar(data)

Adding a Manifest

The last step for this part of the series is adding the Google Cloud Messaging Sender ID to the `manifest.json` file. This ID makes sure Firebase is allowed to send messages to our app. If you don’t already have a manifest, create one and add the following. Do not change the value.

{ "gcm_sender_id": "103953800507"

Now we are all set up on the front end. What’s left is creating our actual database and the functions to watch database changes in the next article.

Article Series:

  1. Setting Up & Firebase (You are here!)
  2. The Back End (Coming soon!)

Implementing Push Notifications: Setting Up & Firebase is a post from CSS-Tricks

, ,

Visit Us On TwitterVisit Us On FacebookVisit Us On Google PlusVisit Us On Linkedin