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.
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:
Run firebase login
Authenticate yourself
Go to your project directory
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.
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.
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.
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:
Setting Up & Firebase (You are here!)
The Back End (Coming soon!)
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:
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.
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
HTML
We have a button to subscribe which gets enabled if 'serviceWorker' in navigator. Below that, a simple form and a list of posts:
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 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.
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.
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.
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.
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.
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.
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 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.
