Pavel Duchovny

## Introduction

Containerized applications are becoming an industry standard for virtualization. When we talk about managing those containers, [Kubernetes](https://kubernetes.io/) will probably be brought up extremely quickly.

Kubernetes is a known open-source system for automating the deployment, scaling, and management of containerized applications. Nowadays, all of the major cloud providers (AWS, Google Cloud, and Azure) have a managed Kubernetes offering to easily allow organizations to get started and scale their Kubernetes environments.

Not surprisingly, MongoDB Atlas also runs on all of those offerings to give your modern containerized applications the best database offering. However, ease of development might yield in missing some critical aspects, such as security and connectivity control to our cloud services.

In this article, I will guide you on how to properly secure your Kubernetes cloud services when connecting to MongoDB Atlas using the recommended and robust solutions we have.

## Prerequisites

You will need to have a cloud provider account and the ability to deploy one of the Kubernetes offerings:

* [Amazon EKS](https://aws.amazon.com/eks/)
* [Google Cloud GKE](https://cloud.google.com/kubernetes-engine)
* [Azure AKS](https://azure.microsoft.com/en-us/services/kubernetes-service)

And of course, you'll need a MongoDB Atlas project where you are a project owner.

> If you haven't yet set up your free cluster on [MongoDB Atlas](http://bit.ly/mongodbatlas), now is a great time to do so. You have all the instructions in this [blog post](https://www.mongodb.com/developer/products/atlas/free-atlas-cluster/). Please note that for this tutorial you are required to have a M10+ cluster.

## Step 1: Set Up Networks

Atlas connections, by default, use credentials and end-to-end encryption to secure the connection. However, building a trusted network is a must for closing the security cycle between your application and the database.

No matter what cloud of choice you decide to build your Kubernetes cluster in, the basic foundation of securing that deployment is creating its own network. You can look into the following guides to create your own network and gather the main information (Names, Ids, and subnet [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) \- CIDR\)\.

##### Private Network Creation

| AWS | GCP | Azure |
| --- | --- | ----- |
| [Create an AWS VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html#getting-started-create-vpc) | [Create a GCP VPC](https://cloud.google.com/vpc/docs/using-vpc) | [Create a VNET](https://docs.microsoft.com/en-us/azure/virtual-network/quick-create-portal) |

## Step 2: Create Network Peerings

Now, we'll configure connectivity of the virtual network that the Atlas region resides in to the virtual network we've created in Step 1. This connectivity is required to make sure the communication between networks is possible. We'll configure Atlas to allow connections from the virtual network from Step 1.

This process is called setting a Network Peering Connection. It's significant as it allows internal communication between networks of two different accounts (the Atlas cloud account and your cloud account).
<figure align="center"><img style="border-radius: 10px; width: 800px" src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Atlas_peering_page_3e33f7d799.png" alt="Atlas peering page"></figure>The network peerings are established under our Projects > Network Access > Peering > "ADD PEERING CONNECTION." For more information, please read our [documentation](https://docs.atlas.mongodb.com/security-vpc-peering/).

However, I will highlight the main points in each cloud for a successful peering setup:

##### Private Network Creation
<div style="overflow-x:auto;">
<table style="
        border: 1px solid #B8C4C2;
        border-collapse: collapse;
        margin: 16px 0;
        table-layout: fixed;
"><thead style="border: inherit" valign="bottom"><tr style="border: inherit"><th style="width: 250px; border: inherit; padding: 10px">AWS</th><th style="width: 250px; border: inherit; padding: 10px">GCP</th><th style="width: 250px; border: inherit; padding: 10px">Azure</th></tr></thead><tbody style="border: inherit" valign="top"><tr style="border: inherit"><td style="border: inherit; padding: 10px"><ol><li>Allow outbound traffic to Atlas CIDR on 2015-27017.</li><li>Obtain VPC information (<code>Account ID</code>, <code>VPC Name</code>, <code>VPC Region</code>, VPC CIDR). Enable DNS and Hostname resolution on that VPC.</li><li>Using this information, initiate the VPC Peering.</li><li>Approve the peering on AWS side.</li><li>Add peering route in the relevant subnet/s targeting Atlas CIDR and add those subnets/security groups in the Atlas access list page.</li></ol></td><td style="border: inherit; padding: 10px"><ol><li>Obtain GCP VPC information (<code>Project ID</code>, <code>VPC Name</code>, <code>VPC Region</code>, and CIDR).</li><li>When you initiate a VPC peering on Atlas side, it will generate information you need to input on GCP VPC network peering page (<code>Atlas Project ID</code> and <code>Atlas VPC Name</code>).</li><li>Submit the peering request approval on GCP and add the GCP CIDR in Atlas access lists.</li></ol></td><td style="border: inherit; padding: 10px"><ol><li>Obtain the following azure details from your subscription (<code>Subscription ID</code>, Azure Active Directory <code>Directory ID</code>, VNET <code>Resource Group Name</code>, <code>VNet Name</code>, <code>VNet Region</code>).</li><li>Input the gathered information and get a list of commands to perform on Azure console.</li><li>Open Azure console and run the commands, which will create a custom role and permissions for peering.</li><li>Validate and initiate peering.</li></ol></td></tr></tbody></table>
</div>

## Step 3: Deploy the Kubernetes Cluster in Our Networks

The Kubernetes clusters that we launch must be associated with the
peered network. I will highlight each cloud provider's specifics.

## AWS EKS

When we launch our EKS via the AWS console service, we need to configure
the peered VPC under the "Networking" tab.

Place the correct settings:

* VPC Name
* Relevant Subnets (Recommended to pick at least three availability
zones)
* Choose a security group with open 27015-27017 ports to the Atlas
CIDR.
* Optionally, you can add an IP range for your pods.

![In this case, I placed my peered VPC name, chose three availability zones from my EU West region, and specified a security group allowing 27015 - 27017 access to Atlas CIDR.](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/AWS_Netoworking_Kube_ed6404dca2.png)

## GCP GKE

When we launch our GKE service, we need to configure the peered VPC under the "Networking" section.

Place the correct settings:

* VPC Name
* Subnet Name
* Optionally, you can add an IP range for your pod's internal network that cannot overlap with the peered CIDR.

![In this case, once I got to the network tab, I placed my Network name ](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/GCP_Kube_Clusterr_Network_6037204a1a.png)

## Azure AKS

When we lunch our AKS service, we need to use the same resource group as the peered VNET and configure the peered VNET as the [CNI network](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) in the advanced Networking tab.

Place the correct settings:

* Resource Group
* VNET Name under "Virtual Network"
* Cluster Subnet should be the peered subnet range.
* The other CIDR should be a non-overlapping CIDR from the peered network.

![In this case, I checked the box ](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Networking_AKS_Azure_5c9cc20768.png)

## Step 4: Deploy Containers and Test Connectivity

Once the cluster is up and running in your cloud provider, you can test the connectivity to our peered cluster.

First, we will need to get our connection string and method from the Atlas cluster UI. Please note that GCP and Azure have private connection strings for peering, and those must be used for peered networks.

![Connect to Peering Test: step 1](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Private_Conn_String_d42ecbe933.png)

![Connect to Peering Test: step 2](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Shell_Template_e101dd97bf.png)

Now, let's test our connection from one of the Kubernetes pods:
<figure align="center"><img style="border-radius: 10px; width: 800px" src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Success_Shell_Private_3303fc8d3d.png" alt="Successful Shell Test"></figure>That's it. We are securely connected!

## Wrap-Up

Kubernetes-managed clusters offer a simple and modern way to deploy containerized applications to the vendor of your choice. It's great that we can easily secure their connections to work with the best cloud database offering there is, MongoDB Atlas, unlocking other possibilities such as building cross-platform application with [MongoDB Realm and Realm Sync](https://www.mongodb.com/cloud/atlas/lp/realm) or using [MongoDB Data Lake](https://www.mongodb.com/cloud/atlas/lp/data-lake) and [Atlas Search](https://www.mongodb.com/atlas/search) to build incredible applications.

> If you have questions, please head to our [developer community website](https://community.mongodb.com/) where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.

A high-level guide on how to securely connect MongoDB Atlas with the Kubernetes offerings from Amazon AWS, Google Cloud (GCP), and Microsoft Azure.

Securely Connect MongoDB to Cloud-Offered Kubernetes Clusters

Maxime Beugnet

**You probably already know that MongoDB Atlas is MongoDB as a service in the public cloud of your choice but did you know we also offer a free forever cluster? In this Quick Start, we'll show you why you should get one and how to create one.**

MongoDB Atlas's Free Tier clusters - which are also known as M0 Sandboxes - are limited to only 512MB of storage but it's more than enough for a pet project or to learn about MongoDB with our [free MongoDB University](http://bit.ly/mongodbuniversity) courses.

The only restriction on them is that they are available in a few regions for each of our three cloud providers: currently there are six on AWS, five on Azure, and four on Google Cloud Platform.

In this tutorial video, I will show you [how to create an account](http://bit.ly/mdb-atlas). Then I'll show you how to create your first 3 node cluster and populate it with sample data.

:youtube[]{vid=rPqRyYJmx2g}

Now that you understand the basics of [MongoDB Atlas](https://docs.atlas.mongodb.com/), you may want to explore some of our advanced features that are not available in the Free Tier clusters:

-   [Peering your MongoDB Clusters](https://docs.atlas.mongodb.com/security-vpc-peering/) with your AWS, GCP or Azure machines is only available for dedicated instances (M10 at least),
-   [LDAP Authentication and Authorization](https://docs.atlas.mongodb.com/security-ldaps/),
-   [AWS PrivateLink](https://docs.atlas.mongodb.com/billing/additional-services/#private-endpoints).

Our new [Lucene-based Full-Text Search engine](https://docs.atlas.mongodb.com/atlas-search/) is now available for free tier clusters directly.


Want to know the quickest way to start with MongoDB? It begins with getting yourself a free MongoDB Atlas Cluster so you can leverage your learning

Getting Your Free MongoDB Atlas Cluster

Henna Singh



<div class="introduction">

Hello, everyone. I am Henna. I started with Mobile Application back in 2017 when I was a lucky recipient of the Udacity Scholarship. I had always used SQLite when it came to using databases in my mobile apps. Using SQLite was definitely a lot of boilerplate code, but using it with Room library did make it easier.

I had heard about Realm before but I got so comfortable using Room with SQLite that I never thought of exploring the option.

At the time, I was not aware that Realm had multiple offerings, from being used as a local database on mobile, to offering Sync features to be able to sync your app data to multiple devices.

I will pen down my experiments with MongoDB Realm as a series of articles. This is the first article in the series and it is divided into two parts.

**Part A** will explain how to create a MongoDB Realm back end for your mobile app.

**Part B** will explain how to implement Google Authentication in the
app.

>Pre-Requisites: You have created at least one app using Android Studio.

![Laptop and Coffee](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/laptopandcoffee_180302bf7d.jpeg)
Photo by [Emily Finch](https://unsplash.com/@emilydafinchy?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=medium&utm_medium=referral)

Let's get some coffee and get the ball rolling. :)

## Part A: 

### Step 1. How to Create an Account on MongoDB Cloud

MongoDB Realm is a back end as a service. When you want to use MongoDB Realm Sync functionality, you need to create a MongoDB Realm account and it is free :D :D

> MongoDB’s Atlas offering of the database as a service is what makes this database so amazing. For mobile applications, we use Realm DB locally on the mobile device, and the local data gets synced to MongoDB Atlas on the cloud.

An account on MongoDB Cloud can be easily created by visiting
<https://account.mongodb.com/account/login>.

Once you sign-in to your account, you will be asked to create an Organization

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/ccount_setup_b18587e46f.png)

Once you click on the Create button, you will be asked to enter organization name and select MongoDB Atlas as a Cloud Service as shown below and click Next.

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/create_Organisation_ca92f8f450.png)

Add members and permissions as desired and click on Create Organization. Since I am working on my own I added only myself as Project Owner.

Next you will be asked to create a project, name it and add members and permissions. Each permission is described on the right side. Be cautious of whom you give read/write access of your database.

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/addmemberspermissions_cabf7b478e.png)

Once you create a project, you will be asked to deploy your database as shown below
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/createdatabase_63fbccabae.png)

Depending on your use-case, you can select from given options. For this article, I will choose shared and Free service :)

Next select advance configuration options and you will be asked to select a Cloud Provider and Region

A cluster is a group of MongoDB Servers that store your data on the cloud. Depending on your app requirement, you choose one. I opted for a free cluster option for this app.
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/createcluster_0fd9d1fb7f.png)

> Be mindful of the Cloud Provider and the Location you choose. Realm App is currently available only with AWS and it is recommended to have Realm App region closer to the cluster region and same Cloud Provider. So I choose the settings as shown.
> 
Give a name to your cluster. Please note this cannot be changed later.

And with this, you are all set with Step 1.

### Step 2. Security Quickstart
Once you have created your cluster, you will be asked to create a user to access data stored in Atlas. This used to be a manual step earlier but now you get the option to add details as and when you create a cluster.

These credentials can be used to connect to your cluster via MongoDB Compass or Mongo Shell but we will come to that later.

You can click on “Add My Current IP Address” to whitelist your IP address and follow as instructed.
![Add Network Security details](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/securityquickstart_257fef4eeb.png)

If you need to change your settings at a later time, use Datasbase Access and Network Access from Security section that will appear on left panel.

With this Step 2 is done.
### Step 3. How to Create a Realm App on the Cloud
We have set up our cluster, so the next step is to create a Realm app and link it to it. Click on the Realm tab as shown.
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/realmtab_f9c6a49588.png)

You will be shown a template window that you can choose from. For this article, I will select “Build your own App”
![Start with a template](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/realmappcreation_5bcb4bb73f.png)


Next you will be asked to fill details as shown. Your Data Source is the Atlas Cluster you created in Step1. If you have multiple clusters, select the one you want to link your app with.

Please note, Realm app names should have fewer than 64 characters.
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/realmapp_c079d404e1.png)

For better performance, It is recommended to have local deployment and region the same or closer to your cluster region.

Check the Global Deployment section in MongoDB's official documentation for more details.

You will be shown a section of guides once you click on “Create a Realm Application”. You can choose to follow the guides if you know what you are doing, but for brevity of this article, I will close guides and this will bring you to your Realm Dashboard as shown

Please keep a note of the “App Id”. This will be needed when you create the Android Studio project.
![Realm Dashboard](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/realmappid_3537ee0eae.png)

There are plethora of cloud services that comes with MongoDB Realm. You can use functions, triggers, graphQL, and other features depending on your app use cases. For this article, you will be using Authentication.

With this, you are finished with Part A. Yayyy!! :D



## Part B: 

### Step 1. Creating an Android Studio Project

I presume you all have experience creating mobile applications using Android Studio. In this step, you would "Start a new Android Project." You can enter any name of your choice and select Kotlin as the language and min API 21.

Once you create the project, you need to add dependencies for the Realm Database and Google Authentication.

**For Realm**, add this line of code in the project-level `build.gradle` file. This is the latest version at the time of writing this article.

**Edit 01:** Plugin is updated to current (may change again in future).

``` java
classpath "io.realm:realm-gradle-plugin:10.9.0"
```

After adding this, the dependencies block would look like this.

``` java
dependencies {
    classpath "com.android.tools.build:gradle:4.0.0"
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    
    classpath "io.realm:realm-gradle-plugin:10.9.0"

    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
}
```

Now we add Realm plugin and Google Authentication in the app-level `build.gradle` file. Add this code at the top of the file but below the `kotlin-kapt` extension. If you are using Java, then this would come after the Android plugin.

``` java
apply plugin: 'kotlin-kapt'
apply plugin: 'realm-android'
```

In the same file, we would also add the below code to enable the Realm sync in the application. You can add it anywhere inside the Android block.

``` java
android {
...
...
realm {
    syncEnabled = true
  }
...
}
```

For Google Auth, add the following dependency in the app-level gradle file. Please note, the versions may change since the time of this article.

**Edit 02:** gms version is updated to current.

``` java
dependencies{
...
...
//Google OAuth
implementation 'com.google.android.gms:play-services-auth:20.0.1'
...
}
```

With this, we are finished with Step 1. Let's move onto the next step to implement Google Authentication in the project.

### Step 2. Adding Google Authentication to the Application

Now, I will not get into too much detail on implementing Google Authentication to the app since that will deviate from our main topic. I have listed below the set of steps I took and links I followed to implement Google Authentication in my app.

1.  [Configure a Google API Console project](https://developers.google.com/identity/sign-in/android/start-integrating#configure_a_project). (Create credentials for Android Application and Web Application). Your credential screen should have 2 oAuth Client IDs.

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/oauthcliendids_2da4d84855.png)

2.  [Configure Google Sign-in and the GoogleSignInClient object](https://developers.google.com/identity/sign-in/android/sign-in#configure_google_sign-in_and_the_googlesigninclient_object) (in the Activity's onCreate method).
3.  [Add the Google Sign-in button to the layout file](https://developers.google.com/identity/sign-in/android/sign-in#add_the_google_sign-in_button_to_your_app).
4.  [Implement Sign-in flow](https://developers.google.com/identity/sign-in/android/sign-in#start_the_sign-in_flow).

This is what the activity will look like at the end of the four steps.

>**Please note**: This is only a guideline. Your variable names and views can be different. The String server_client_id here is the web client-id you created in Google Console when you created Google Auth credentials in the Google Console Project.

``` java
class MainActivity : AppCompatActivity() {

    private lateinit var client: GoogleSignInClient

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val googleSignInOptions = GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
            .requestEmail()
            .requestServerAuthCode(getString(R.string.server_client_id))
            .build()

        client = GoogleSignIn.getClient(this, googleSignInOptions)

        findViewById(R.id.sign_in_button).setOnClickListener{
            signIn()
        }
    }

    override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
        super.onActivityResult(requestCode, resultCode, data)
        if(requestCode == 100){
            val task = GoogleSignIn.getSignedInAccountFromIntent(data)
            val account = task.getResult(ApiException::class.java)
            handleSignInResult(account)
        }
    }

    private fun handleSignInResult(account: GoogleSignInAccount?) {
            try{
                Log.d("MainActivity", "${account?.serverAuthCode}")
                //1
                val idToken = account?.serverAuthCode

                //signed in successfully, forward credentials to MongoDB realm
                //2
                val googleCredentials = Credentials.google(idToken)
                //3
                app.loginAsync(googleCredentials){
                    if(it.isSuccess){
                        Log.d("MainActivity", "Successfully authenticated using Google OAuth")
                        //4
                        startActivity(Intent(this, SampleResult::class.java))
                    } else {
                        Log.d("MainActivity", "Failed to Log in to MongoDB Realm: ${it.error.errorMessage}")
                    }
                }
            } catch(exception: ApiException){
                Log.d("MainActivity",  exception.printStackTrace().toString())
            }
    }

    private fun signIn() {
        val signIntent = client.signInIntent
        startActivityForResult(signIntent, 100)
    }
}
```

When you run your app, your app should ask you to sign in with your Google account, and when successful, it should open SampleResult Activity. I displayed a random text to show that it works. :D

Now, we will move onto the next step and configure the Google Auth provider on the MongoDB Realm cloud account.

### Step 3. Configure Google Auth Provider on MongoRealm UI

Return to the MongoDB Realm account where you created your Realm app. On the left panel, click on the Authentication tab and you will see the list of auth providers that MongoDB Realm supports.

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/authproviders_55d5b34661.png)
Click on the *edit* icon corresponding to Google Authentication provider and you will be led to a page as shown below.

**Edit 03:** Updated Screenshot as there is now a new option OpenID connect.
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Open_ID_Connect_5b3ce6b5a8.png)

Toggle the **Provider Enabled** switch to **On** and enter the **Web-Client ID** and **Web Client Secret** from the Google Console Project you created above.

You can choose the Metadata Fields as per your app use case and click Save.

> Keeping old UI here as OpenID Connect is not used.
> 
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/authproviders2_bdd33e8aa7.png)
With this, we are finished with Step 3. 

### Step 4. Implementing Google Auth Sync Credentials to the Project

This is the last step of Part 2. We will use the Google Auth token received upon signing in with our Google Account in the previous step to authenticate to our MongoDB Realm account.

We already added dependencies for Realm in Step 3 and we created a Realm app on the back end in Step 2. Now, we initialize Realm and use the appId (Remember I asked you to make a note of the app Id? Check Step 2. ;)) to connect back end with our mobile app.

Create a new Kotlin class that extends the application class and write the following code onto it.

``` java
val appId ="realmsignin-abyof" // Enter your own App Id here
lateinit var app: App

class RealmApp: Application() {

    override fun onCreate() {
        super.onCreate()
        Realm.init(this)

        app = App(AppConfiguration.Builder(appId).build())

    }
}
```

An "App" is the main client-side entry point for interacting with the MongoDB Realm app and all its features, so we configure it in the application subclass for getting global access to the variable.

This is the simplest way to configure it. After configuring the "App", you can add authentication, manage users, open synchronized realms, and all other functionalities that MongoDB Realm offers.

To add more details when configuring, check the [MongoDB Realm Java doc](https://docs.mongodb.com/realm-sdks/java/10.0.0-BETA.8/io/realm/mongodb/App.html).

Don't forget to add the RealmApp class or whatever name you chose to the manifest file.

``` java
<application
   ..
    android:theme="@style/AppTheme"
    android:name=".RealmApp">
    ....
    ....
    <activity android:name=".MainActivity">
        ...
        ...
    </activity>
</application>
```

Now come back to the `handleSignInResult()` method call in the MainActivity, and add the following code to that method.

``` java
private fun handleSignInResult(account: GoogleSignInAccount?) {
        try{
            Log.d("MainActivity", "${account?.serverAuthCode}")

            // Here, you get the serverAuthCode after signing in with your Google account.
            val idToken = account?.serverAuthCode

            // signed in successfully, forward credentials to MongoDB realm
            // In this statement, you pass the token received to ``Credentials.google()`` method to pass it to MongoDB Realm.
            val googleCredentials = Credentials.google(idToken)

            // Here, you login asynchronously by passing Google credentials to the method.
            app.loginAsync(googleCredentials){
                if(it.isSuccess){
                    Log.d("MainActivity", "Successfully authenticated using Google OAuth")

            // If successful, you navigate to another activity. This may give a red mark because you have not created SampleResult activity. Create an empty activity and name it SampleResult.
             startActivity(Intent(this, SampleResult::class.java))
                } else {
                    Log.d("MainActivity", "Failed to Log in to MongoDB Realm: ${it.error.errorMessage}")
                }
            }
        } catch(exception: ApiException){
            Log.d("MainActivity",  exception.printStackTrace().toString())
        }
}
```

Add a TextView with a Successful Login message to the SampleResult layout file.

Now, when you run your app, log in with your Google account and your SampleResult Activity with Successful Login message should be shown.

When you check the App Users section in your MongoDB Realm account, you should notice one user created.
![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/appusers_8775b437e2.png)

## Wrapping Up

You can get the code for this tutorial from [this GitHub repo](https://github.com/hennasingh/RealmWithGoogle).

Well done, everyone. We are finished with implementing Google Auth with MongoDB Realm, and I would love to know if you have any feedback for me.❤

You can post questions on [MongoDB Community Forums](https://developer.mongodb.com/community/forums/) or if you are struggling with any topic, please feel free to reach out.

In the next article, I talk about how to implement Realm Sync in your Android Application.


Getting Started with MongoDB Realm and Implementing Google Authentication in Your Android App

Start Implementing Google Auth With MongoDB Realm in Your Android App

Stanimira Vlaeva

Abirami Sukumaran

## Plea and the Pledge: Truly Serverless

As modern application developers, we’re juggling many priorities: performance, flexibility, usability, security, reliability, and maintainability. On top of that, we’re handling dependencies, configuration, and deployment of multiple components in multiple environments and sometimes multiple repositories as well. And then we have to keep things secure and simple. Ah, the nightmare!

This is the reason we love serverless computing. Serverless allows developers to focus on the thing they like to do the most—development—and leave the rest of the attributes, including infrastructure and maintenance, to the platform offerings. 

In this read, we’re going to see how Cloud Run and MongoDB come together to enable a completely serverless MEAN stack application development experience. We'll learn how to build a serverless MEAN application with [Cloud Run](https://cloud.google.com/run/) and [MongoDB Atlas](https://www.mongodb.com/atlas), the multi-cloud application data platform by MongoDB.

### Containerized deployments with Cloud Run

All serverless platform offer exciting capabilities: 

* Event-driven function (not a hard requirement though)
* No-infrastructure maintenance
* Usage-based pricing
* Auto-scaling capabilities

Cloud Run stands out of the league by enabling us to: 

* Package code in multiple stateless containers that are request-aware and invoke it via HTTP requests
* Only be charged for the exact resources you use
* Support any programming language or any operating system library of your choice, or any binary

Check this link for more features in full [context](https://cloud.google.com/run/?utm_source=google&utm_medium=cpc&utm_campaign=japac-IN-all-en-dr-skws-all-pkws-trial-b-dr-1009882&utm_content=text-ad-none-none-DEV_c-CRE_529584319423-ADGP_Hybrid%20%7C%20SKWS%20-%20PHR%20%7C%20Txt%20~%20Compute%20~%20Cloud%20Run_Global%20gap%20analysis-KWID_43700065767178853-aud-970366092687%3Akwd-677335471899&userloc_1007768-network_g&utm_term=KW_cloud%20run&gclid=Cj0KCQjw1tGUBhDXARIsAIJx01lcrrpCE3MLqe4k3MiQdd8ibvGmXduL9kLXELPjodjSu7Gipc5ODYwaAlBkEALw_wcB&gclsrc=aw.ds).

However, many serverless models overlook the fact that traditional databases are not managed. You need to manually provision infrastructure (vertical scaling) or add more servers (horizontal scaling) to scale the database. This introduces a bottleneck in your serverless architecture and can lead to performance issues.

### Deploy a serverless database with MongoDB Atlas

MongoDB launched serverless instances, a new fully managed, serverless database deployment in Atlas to solve this problem. With serverless instances you never have to think about infrastructure — simply deploy your database and it will scale up and down seamlessly based on demand — requiring no hands-on management. And the best part, you will only be charged for the operations you run. To make our architecture truly serverless, we'll combine Cloud Run and MongoDB Atlas capabilities.

## What's the MEAN stack?

The [MEAN stack](https://www.mongodb.com/mean-stack) is a technology stack for building full-stack web applications entirely with JavaScript and JSON. The MEAN stack is composed of four main components—MongoDB, Express, Angular, and Node.js.

* **MongoDB** is responsible for data storage. 
* **Express.js** is a Node.js web application framework for building APIs.
* **Angular** is a client-side JavaScript platform.
* **Node.js** is a server-side JavaScript runtime environment. The server uses the MongoDB Node.js driver to connect to the database and retrieve and store data. 

![MEAN stack](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/mean_stack_e791a7354e.PNG)

## Steps for deploying truly serverless MEAN stack apps with Cloud Run and MongoDB

In the following sections, we’ll provision a new MongoDB serverless instance, connect a MEAN stack web application to it, and finally, deploy the application to Cloud Run.

### 1. Create the database

Before you begin, get started with [MongoDB Atlas on Google Cloud](https://console.cloud.google.com/marketplace/product/mongodb/mdb-atlas-self-service).

![MongoDB Atlas on Google Cloud subscription page](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/mongodb_atlas_on_google_cloud_e3bcc0b537.JPG)

Once you sign up, click the “Build a Database” button to create a new serverless instance. Select the following configuration:

![Create new serverless instance in MongoDB Atlas configuration page
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/create_new_serverless_instance_9134772726.JPG)

Once your serverless instance is provisioned, you should see it up and running.

![Database deployments page in MongoDB Atlas
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/database_deployments_page_5309d13fb4.JPG)

Click on the “Connect” button to add a connection IP address and a database user.

For this blog post, we’ll use the “Allow Access from Anywhere” setting. MongoDB Atlas comes with a set of security and access features. You can learn more about them in the [security features documentation article](https://www.mongodb.com/docs/atlas/setup-cluster-security/).

Use credentials of your choice for the database username and password. Once these steps are complete, you should see the following:

![Screen showing 'You are ready to connect' in MongoDB Atlas
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/ready_to_connect_e06352f53b.JPG)

Proceed by clicking on the “Choose a connection method” button and then selecting “Connect your application”.

![Screen showing the connection string for MongoDB Atlas
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/connection_string_mongodb_atlas_c28ea136ce.JPG)

Copy the connection string you see and replace the password with your own. We’ll use that string to connect to our database in the following sections.

### 2. Set up a Cloud Run project

First, sign in to [Cloud Console](http://console.cloud.google.com/), create a new project, or reuse an existing one.

Remember the Project Id for the project you created. Below is an image from [https://codelabs.developers.google.com/codelabs/cloud-run-hello#1](https://codelabs.developers.google.com/codelabs/cloud-run-hello#1) that shows how to create a new project in Google Cloud.

!['Create a new project' configuration page in Google Cloud. The project id is highlighted.
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/create_new_project_605bbeec53.JPG)

Then, enable Cloud Run API from [Cloud Shell](https://cloud.google.com/shell):

* Activate Cloud Shell from the Cloud Console. Simply click Activate Cloud Shell.

![Google Cloud Shell Editor loading page
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/google_cloud_shell_editor_18236232e8.JPG)

* Use the below command:

*gcloud services enable run.googleapis.com*

We will be using Cloud Shell and [Cloud Shell Editor](https://cloud.google.com/shell/docs/editor-overview#:~:text=Cloud%20Shell%20comes%20with%20a,and%20is%20based%20on%20Theia.) for code references. To access Cloud Shell Editor, click Open Editor from the Cloud Shell Terminal:

![Google Cloud Shell Code Editor
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/google_cloud_shell_code_editor_51ed2f16ca.JPG)

Finally, we need to clone the MEAN stack project we’ll be deploying. 

We’ll deploy an employee management web application. The REST API is built with Express and Node.js; the web interface, with Angular; and the data will be stored in the MongoDB Atlas instance we created earlier.

Clone the project repository by executing the following command in the Cloud Shell Terminal:

`git clone` [https://github.com/mongodb-developer/mean-stack-example.git](https://github.com/mongodb-developer/mean-stack-example.git)

In the following sections, we will deploy a couple of services—one for the Express REST API and one for the Angular web application. 

### 3. Deploy the Express and Node.js REST API

First, we’ll deploy a Cloud Run service for the Express REST API. 

The most important file for our deployment is the Docker configuration file. Let’s take a look at it:

**mean-stack-example/server/Dockerfile**

```
FROM node:17-slim
 
WORKDIR /usr/app
COPY ./ /usr/app
 
# Install dependencies and build the project.
RUN npm install
RUN npm run build
 
# Run the web service on container startup.
CMD ["node", "dist/server.js"]
```

The configuration sets up Node.js, and copies and builds the project. When the container starts, the command “node dist/server.js” starts the service.

To start a new Cloud Run deployment, click on the Cloud Run icon on the left sidebar:

![Select the 'Cloud Run' icon from the left sidebar
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/select_new_cloud_run_e2c48b457a.JPG)

Then, click on the Deploy to Cloud Run icon:

![Select the 'Deploy to Cloud Run' icon from the opened pane
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/select_deploy_to_cloud_run_c90b1dc8f6.JPG)

Fill in the service configuration as follows:

* Service name: node-express-api
* Deployment platform: Cloud Run (fully managed)
* Region: Select a region close to your database region to reduce latency
* Authentication: Allow unauthenticated invocations

Under Revision Settings, click on Show Advanced Settings to expand them:

* Container port: 5200
* Environment variables. Add the following key-value pair and make sure you add the connection string for your own MongoDB Atlas deployment:

`ATLAS_URI:mongodb+srv:/<username>:<password>@sandbox.pv0l7.mongodb.net/meanStackExample?retryWrites=true&w=majority`

For the Build environment, select Cloud Build.

Finally, in the Build Settings section, select:

* Builder: Docker
* Docker: mean-stack-example/server/Dockerfile

Click the Deploy button and then Show Detailed Logs to follow the deployment of your first Cloud Run service!

After the build has completed, you should see the URL of the deployed service:

![Screenshot displaying the message 'Deployment completed successfully!' and the deployment URL.
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/deployment_completed_successfully_31bcb13b6f.JPG)

Open the URL and append ‘/employees’ to the end. You should see an empty array because currently, there are no documents in the database. Let’s deploy the user interface so we can add some!

### 4. Deploy the Angular web application

Our Angular application is in the client directory. To deploy it, we’ll use the Nginx server and Docker.

> Just a thought, there is also an option to use Firebase Hosting for your [Angular application deployment](https://www.youtube.com/watch?v=jVPHsolXgLk) as you can serve your content to a CDN (content delivery network) directly.

Let’s take a look at the configuration files:

**mean-stack-example/client/nginx.conf**

```
events{}
 
http {
 
   include /etc/nginx/mime.types;
 
   server {
       listen 8080;
       server_name 0.0.0.0;
       root /usr/share/nginx/html;
       index index.html;
 
       location / {
           try_files $uri $uri/ /index.html;
       }
   }
}
```

In the Nginx configuration, we specify the default port—8080, and the starting file—`index.html`.

**mean-stack-example/client/Dockerfile**

```
FROM node:17-slim AS build
 
WORKDIR /usr/src/app
COPY package.json package-lock.json ./
 
# Install dependencies and copy them to the container
RUN npm install
COPY . .
 
# Build the Angular application for production
RUN npm run build --prod
 
# Configure the nginx web server
FROM nginx:1.17.1-alpine
COPY nginx.conf /etc/nginx/nginx.conf
COPY --from=build /usr/src/app/dist/client /usr/share/nginx/html
 
# Run the web service on container startup.
CMD ["nginx", "-g", "daemon off;"]
```

In the Docker configuration, we install Node.js dependencies and build the project. Then, we copy the built files to the container, configure, and start the Nginx service.

Finally, we need to configure the URL to the REST API so that our client application can send requests to it. Since we’re only using the URL in a single file in the project, we’ll hardcode the URL. Alternatively, you can attach the environment variable to the window object and access it from there.

**mean-stack-example/client/src/app/employee.service.ts**

```
@Injectable({
 providedIn: 'root'
})
export class EmployeeService {
 // Replace with the URL of your REST API
 private url = 'https://node-express-api-vsktparjta-uc.a.run.app'; 
…
```

We’re ready to deploy to Cloud Run! Start a new deployment with the following configuration settings:

* Service Settings: Create a service
* Service name: angular-web-app
* Deployment platform: Cloud Run (fully managed)
* Authentication: Allow unauthenticated invocations

For the Build environment, select Cloud Build.

Finally, in the Build Settings section, select:

* Builder: Docker
* Docker: mean-stack-example/client/Dockerfile

Click that Deploy button again and watch the logs as your app is shipped to the cloud! When the deployment is complete, you should see the URL for the client app:

![Screenshot displaying the message 'Deployment completed successfully!' and the deployment URL for the Angular service.
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/deployment_completed_successfully_notice_6602368f53.JPG)

Open the URL, and play with your application!

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/employees_demo_1_da0a6342ba.gif)

### Command shell alternative for build and deploy

The steps covered above can alternatively be implemented from Command Shell as below:

Step 1: Create the new project directory named “mean-stack-example” either from the Code Editor or Cloud Shell Command (Terminal):

*mkdir mean-stack-demo
cd mean-stack-demo*

Step 2: Clone project repo and make necessary changes in the configuration and variables, same as mentioned in the previous section.

Step 3: Build your container image using Cloud build by running the command in Cloud Shell:

*gcloud builds submit --tag gcr.io/$GOOGLECLOUDPROJECT/mean-stack-demo*

$GOOGLE_CLOUD_PROJECT is an environment variable containing your Google Cloud project ID when running in Cloud Shell.

Step 4: Test it locally by running: 
docker run -d -p 8080:8080 gcr.io/$GOOGLE_CLOUD_PROJECT/mean-stack-demo 
and by clicking Web Preview, Preview on port 8080.

Step 5: Run the following command to deploy your containerized app to Cloud Run:

*gcloud run deploy mean-stack-demo --image 
gcr.io/$GOOGLECLOUDPROJECT/mean-stack-demo --platform managed --region us-central1 --allow-unauthenticated --update-env-vars DBHOST=$DB_HOST*

a. –allow-unauthenticated will let the service be reached without authentication.

b. –platform-managed means you are requesting the fully managed environment and not the Kubernetes one via Anthos.
 
c. –update-env-vars expects the MongoDB Connection String to be passed on to the environment variable DBHOST.
Hang on until the section on Env variable and Docker for Continuous Deployment for Secrets and Connection URI management.

d. When the deployment is done, you should see the deployed service URL in the command line.

e. When you hit the service URL, you should see your web page on the browser and the logs in the Cloud Logging Logs Explorer page. 

![Service logs displayed in the Cloud Logging Logs Explorer page
](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/services_logs_2085273e8a.JPG)

### 5. Environment variables and Docker for continuous deployment

If you’re looking to automate the process of building and deploying across multiple containers, services, or components, storing these configurations in the repo is not only cumbersome but also a security threat. 

1. For ease of cross-environment continuous deployment and to avoid security vulnerabilities caused by leaking credential information, we can choose to pass variables at build/deploy/up time.
    
    *--update-env-vars* allows you to set the environment variable to a value that is passed only at run time. In our example, the variable DBHOST is assigned the value of $DB_HOST. which is set as *DB_HOST = ‘<<ENCODED CONNECTION URI>>’*.

    Please note that unencoded symbols in Connection URI (username, password) will result in connection issues with MongoDB. For example, if you have a $ in the password or username, replace it with %24 in the encoded Connection URI.

2. Alternatively, you can also pass configuration variables as env variables at build time into docker-compose (*docker-compose.yml*). By passing configuration variables and credentials, we avoid credential leakage and automate deployment securely and continuously across multiple environments, users, and applications.

## Conclusion

MongoDB Atlas with Cloud Run makes for a truly serverless MEAN stack solution, and for those looking to build an application with a serverless option to run in a stateless container, Cloud Run is your best bet. 

## Before you go…

Now that you have learnt how to deploy a simple MEAN stack application on Cloud Run and MongoDB Atlas, why don’t you take it one step further with your favorite client-server use case? Reference the below resources for more inspiration:

* Cloud Run HelloWorld: [https://codelabs.developers.google.com/codelabs/cloud-run-hello#4](https://codelabs.developers.google.com/codelabs/cloud-run-hello#4)
* MongoDB - MEAN Stack: [https://www.mongodb.com/languages/mean-stack-tutorial](https://www.mongodb.com/languages/mean-stack-tutorial)

If you have any comments or questions, feel free to reach out to us online: [Abirami Sukumaran](http://www.linkedin.com/in/abiramisukumaran) and [Stanimira Vlaeva](https://twitter.com/StanimiraVlaeva).

In this blog, we'll see how Cloud Run and MongoDB come together to enable a completely serverless MEAN stack application development experience.

Serverless MEAN Stack Applications with Cloud Run and MongoDB Atlas

Josman Pérez Expóstio

In a serverless application, one of the important features that we must implement for the success of our application is push notifications.

Realm allows us to have a complete push notification system directly in our [Services App](https://www.mongodb.com/atlas/app-services). To do this, we’ll make use of several components that we’ll explain here and develop in this tutorial. But first, let’s describe what our application does.

## Context

The application consists of a public list of books that are stored locally on the device thanks to [Atlas Device Sync](https://www.mongodb.com/atlas/app-services/device-sync), so we can add/delete or update the books directly in our Atlas collection and the changes will be reflected in our application.

We can also add as favorites any book from the list, although to do so, it’ll be necessary to register beforehand using an email and password. We will integrate email/password authentication in our application through the [Atlas App Services authentication providers](https://www.mongodb.com/docs/atlas/app-services/authentication/providers/).

The books, as they belong to a collection synchronized with Atlas Device Sync, will not only be stored persistently on our device but will also be synchronized with our user. This means that we can retrieve the list of favorites on any device where we register with our credentials. Changes made to our favorites using other devices are automatically synchronized.

![Example of the iOS app running on a device](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/books_28f8494f1d.gif)

### Firebase

The management of push notifications will be done through [Firebase Cloud Messaging](https://firebase.google.com/docs/cloud-messaging). In this way, we benefit from a single service to send notifications to iOS, web, and Android.

The configuration is similar to the one we would follow for any other application. The difference is that we will install the [firebase-admin](https://www.npmjs.com/package/firebase-admin) SDK in our Atlas App Services application.

### Triggers

The logic of this application for sending push notifications will be done through triggers. To do this, we will define two use cases:

1. A book has been added or deleted: For this, we will make use of the [topics in Firebase](https://firebase.google.com/docs/cloud-messaging/ios/topic-messaging), so when a user registers to receive this type of notification, they will receive a message every time a book is added/deleted from the general list of books.
2. A book added to my favorites list has been modified: We will make use of the Firebase tokens for each device. We relate the token received to the user so that when a book is modified, only the user/s that have it in their favorites list will receive the notification.

### Functions

The Atlas Triggers will have a function linked that will apply the logic for sending push notifications to the end devices. We will make use of the Firebase Admin SDK that we will install in our App Services App as a [dependency](https://www.mongodb.com/docs/atlas/app-services/functions/dependencies/).

## Overall application logic

This application will show how we can integrate push notifications with an iOS application developed in Swift. We will discuss how we have created each part with code, diagrams, and example usage.

At the end of this tutorial, you’ll find a link to a Github repository where you’ll find both the code of the iOS application as well as the code of the App Services application.

![How to request a FCMToken](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/How_to_request_a_FCM_Token_01c90dfa97.png)

When we start the application for the first time, we log in using [anonymous authentication](https://www.mongodb.com/docs/atlas/app-services/authentication/anonymous/), since to view the list of books, it’s not necessary to register using email/password. However, an anonymous user will still be created and saved in a collection Users in Atlas.

When we first access our application and enable push notifications, in our code, we register with Firebase. This will generate a [registration token](https://firebase.google.com/docs/cloud-messaging/concept-options#credentials), also known as FCMToken, that we will use later to send custom push notifications.

```swift
Messaging.messaging().token { token, error in
   if let error = error {
       print("Error fetching FCM registration token: \(error)")
   } else if let token = token {
       print("FCM registration token: \(token)")
       // Save token in user collection
       user.functions.updateFCMUserToken([AnyBSON(token), AnyBSON("add")], self.onCustomDataUpdated(result:realmError:))
   }
}
```

Once we obtain the FCM token, we will [call a function](https://www.mongodb.com/docs/realm/sdk/swift/examples/call-a-function/) through the Realm SDK to save this token in the user document corresponding to the logged-in user. Within the document, we have defined a token field that will be composed of an array of FCM tokens.

To do this, we will make use of the Firebase SDK and the `Messaging` method, so that we are notified every time the token changes or a new token is generated. In our Swift code, we will use this function to insert a new FCToken for our user.

```swift
Messaging.messaging().token { token, error in
    if let error = error {
        print("Error fetching FCM registration token: \(error)")
    } else if let token = token {
        print("FCM registration token: \(token)")
        // Save token in user collection
        user.functions.updateFCMUserToken([AnyBSON(token), AnyBSON("add")], self.onCustomDataUpdated(result:realmError:))
    }
}
```

In our App Services app, we must implement the logic of the `updateFCMUserToken` function that will store the token in our user document.

#### Function code in Atlas

```javascript
exports = function(FCMToken, operation) {

  const db = context.services.get("mongodb-atlas").db("product");
  const userData = db.collection("customUserData");
  
  if (operation === "add") {
    console.log("add");
    userData.updateOne({"userId": context.user.id},
    { "$addToSet": {
      "FCMToken": FCMToken
    }  
    }).then((doc) => {
      return {success: `User token updated`};
    }).catch(err => {
      return {error: `User ${context.user.id} not found`};
    });
  } else if (operation === "remove") {
    console.log("remove"); 
  } 
};
```

We have decided to save an array of tokens to be able to send a notification to each device that the same user has used to access the application.

The following is an example of a User document in the collection:

```JSON
{
 "_id": {
   "$oid": "626c213ece7819d62ebbfb99"
 },
 "color": "#1AA7ECFF",
 "fullImage": false,
 "userId": "6268246e3e0b17265d085866",
 "bookNotification": true,
 "FCMToken": [
   "as3SiBN0kBol1ITGdBqGS:APA91bERtZt-O-jEg6jMMCjPCfYdo1wmP9RbeATAXIQKQ3rfOqj1HFmETvdqm2MJHOhx2ZXqGJydtMWjHkaAD20A8OtqYWU3oiSg17vX_gh-19b85lP9S8bvd2TRsV3DqHnJP8k-t2WV",
   "e_Os41X5ikUMk9Kdg3-GGc:APA91bFzFnmAgAhbtbqXOwD6NLnDzfyOzYbG2E-d6mYOQKZ8qVOCxd7cmYo8X3JAFTuXZ0QUXKJ1bzSzDo3E0D00z3B4WFKD7Yqq9YaGGzf_XSUcCexDTM46bm4Ave6SWzbh62L4pCbS"
 ]
}
```

## Send notification to a topic

Firebase allows us to subscribe to a topic so that we can send a notification to all devices that have ever subscribed to it without the need to send the notification to specific device tokens.

In our application, once we have registered using an email and password, we can subscribe to receive notifications every time a new book is added or deleted.

![Setting view in the iOS app](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Settings_1136d1eb16.png)

When we activate this option, what happens is that we use the Firebase SDK to register in the topic books.

```swift
static let booksTopic = "books"

@IBAction func setBookPushNotification(_ sender: Any) {
 if booksNotificationBtn.isOn {
     Messaging.messaging().subscribe(toTopic: SettingsViewController.booksTopic)
     print("Subscribed to \(SettingsViewController.booksTopic)")
 } else {
     Messaging.messaging().unsubscribe(fromTopic: SettingsViewController.booksTopic)
     print("Unsubscribed to \(SettingsViewController.booksTopic)")
 }
}
```

### How does it work?

The logic we follow will be as below:

![How push notifications to topic works](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Push_Notifications_diagram_Send_to_topic_b517db3b91.jpg)

In our Atlas App Services App, we will have a [database trigger](https://www.mongodb.com/docs/atlas/app-services/triggers/database-triggers/) that will monitor the Books collection for any new inserts or deletes.

Upon the occurrence of either of these two operations, the linked function shall be executed and send a push notification to the “books” topic.

To configure this trigger, we’ll make use of two very important options:

* **Full Document**: This will allow us to receive the document created or modified in our change event. 
* **Document Pre-Image**: For delete operations, we will receive the document that was modified or deleted before your change event.

With these options, we can determine which changes have occurred and send a message using the title of the book to inform about the change. 

The configuration of the trigger in the App Services UI will be as follows:

![Screenshot of the trigger configuration in the Atlas App Services UI](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Trigger_for_topic_push_notification_bcbc380591.jpg)

The function linked to the trigger will determine whether the operation occurred as an `insert` or `delete` and send the push notification to the topic **books** with the title information.

Function logic:

```javascript
 const admin = require('firebase-admin');
 admin.initializeApp({
   credential: admin.credential.cert({
     projectId: context.values.get('projectId'),
     clientEmail: context.values.get('clientEmail'),
     privateKey: context.values.get('fcm_private_key_value').replace(/\\n/g, '\n'),
   }),
 });
 const topic = 'books';
 const message = {topic};
 if (changeEvent.operationType === 'insert') {
   const name = changeEvent.fullDocument.volumeInfo.title;
   const image = changeEvent.fullDocument.volumeInfo.imageLinks.smallThumbnail;
   message.notification = {
     body: `${name} has been added to the list`,
     title: 'New book added'
   };
   if (image !== undefined) {
     message.apns = {
       payload: {
         aps: {
           'mutable-content': 1
         }
       },
       fcm_options: {
         image
       }
     };
   }
 } else if (changeEvent.operationType === 'delete') {
   console.log(JSON.stringify(changeEvent));
   const name = changeEvent.fullDocumentBeforeChange.volumeInfo.title;
   message.notification = {
     body: `${name} has been deleted from the list`,
     title: 'Book deleted'
   };
 }
 admin.messaging().send(message)
   .then((response) => {
     // Response is a message ID string.
     console.log('Successfully sent message:', response);
     return true;
   })
   .catch((error) => {
     console.log('Error sending message:', error);
     return false;
 });
```

When someone adds a new book, everyone who opted-in for push notifications will receive the following:

![Screenshot of a push notification on a device](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Example_of_push_to_topic_on_device_aa8f65fd48.png)

## Send notification to a specific device

To send a notification to a specific device, the logic will be somewhat different.

For this use case, every time a book is updated, we will search if it belongs to the favourites list of any user. For those users who have such a book, we will send a notification to all registered tokens.

This will ensure that only users who have added the updated book to their favorites will receive a notification alerting them that there has been a change.

### How does it work?

![Diagram of sending push notifications to a specific list of users](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Diagram_of_sending_push_notifications_to_a_specific_list_of_users_51080e63c4.jpg)

For this part, we will need a database trigger that will monitor for updates operations on the books collection.

The configuration of this trigger is much simpler, as we only need to monitor the `updates` that occur in the book collection. 

The configuration of the trigger in our UI will be as follows:

![Screenshot of the trigger configuration in the Atlas App Services UI](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Trigger_for_checking_updates_on_book_collection_dcb9e145d0.jpg)

When such an operation occurs, we’ll check if there is any user who has added that book to their favorites list. If there is, we will create a new document in the ***pushNotifications*** collection.

This auxiliary collection is used to optimize the sending of push notifications and handle exceptions. It will even allow us to set up a monitoring system as well as retries.

Every time we send a notification, we’ll insert a document with the following:

1. The changes that occurred in the original document.
2. The FCM tokens of the recipient devices.
3. The date when the notification was registered.
4. A processed property to know if the notification has been sent.

Here’s an example of a push notification document:

```JSON
{
 "_id": {
   "$oid": "62a0da5d860040b7938eab87"
 },
 "token": [
"e_OpA2X6ikUMk9Kdg3-GGc:APA91bFzFnmAgAhbtbqXOwD6NLnDzfyOzYbG2E-d6mYOQKZ8qVOCxd7cmYo8X3JAFTuXZ0QUXKJ1bzSzDo3E0D00z3B4WFKD7Yqq9YaGGzf_XSUcCexDTM46bm4Ave6SWzbh62L4pCbS",
   "fQvffGBN2kBol1ITGdBqGS:APA91bERtZt-O-jEg6jMMCjPCfYdo1wmP9RbeATAXIQKQ3rfOqj1HFmETvdqm2MJHOhx2ZXqGJydtMWjHkaAD20A8OtqYWU3oiSg17vX_gh-19b85lP9S8bvd2TRsV3DqHnJP8k-t2WV"
 ],
 "date": {
   "$date": {
     "$numberLong": "1654708829678"
   }
 },
 "processed": true,
 "changes": {
   "volumeInfo": {
     "title": "Pacific on Linguistics",
     "publishedDate": "1964",
     "industryIdentifiers": [
       {
         "type": "OTHER",
         "identifier": "UOM:39015069017963"
       }
     ],
     "readingModes": {
       "text": false,
       "image": false
     },
     "categories": [
       "Linguistics"
     ],
     "imageLinks": {
       "smallThumbnail": "http://books.google.com/books/content?id=aCVZAAAAMAAJ&printsec=frontcover&img=1&zoom=5&source=gbs_api",
       "thumbnail": "http://books.google.com/books/content?id=aCVZAAAAMAAJ&printsec=frontcover&img=1&zoom=1&source=gbs_api"
     },
     "language": "en"
   }
 }
}
```

To process the notifications, we’ll have a database trigger that will monitor the ***pushNotifications*** collection, and each new document will send a notification to the tokens of the client devices.

#### Function logic

```javascript
exports = async function(changeEvent) {

 const admin = require('firebase-admin');
 const db = context.services.get('mongodb-atlas').db('product');

 const id = changeEvent.documentKey._id;

 const bookCollection = db.collection('book');
 const pushNotification = db.collection('pushNotification');

 admin.initializeApp({
   credential: admin.credential.cert({
     projectId: context.values.get('projectId'),
     clientEmail: context.values.get('clientEmail'),
     privateKey: context.values.get('fcm_private_key_value').replace(/\\n/g, '\n'),
   }),
 });

 const registrationToken = changeEvent.fullDocument.token;
 console.log(JSON.stringify(registrationToken));
 const title = changeEvent.fullDocument.changes.volumeInfo.title;
 const image = changeEvent.fullDocument.changes.volumeInfo.imageLinks.smallThumbnail;

 const message = {
   notification:{
     body: 'One of your favorites changed',
     title: `${title} changed`
   },
   tokens: registrationToken
 };

 if (image !== undefined) {
   message.apns = {
     payload: {
       aps: {
         'mutable-content': 1
       }
     },
     fcm_options: {
      image
     }
   };
 }

 // Send a message to the device corresponding to the provided
 // registration token.
 admin.messaging().sendMulticast(message)
   .then((response) => {
     // Response is a message ID string.
     console.log('Successfully sent message:', response);
     pushNotification.updateOne({'_id': BSON.ObjectId(`${id}`)},{
       "$set" : {
         processed: true
       }
     });
   })
   .catch((error) => {
     console.log('Error sending message:', error);
 });
};
```

Example of a push notification to a user:

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Screenshot_of_specific_push_notification_received_on_device_c650d5fae0.png)

## Repository

The complete code for both the App Services App as well as for the iOS application can be found in a [dedicated GitHub repository](https://github.com/josmanperez/BookRealmTutorial).

If you have found this tutorial useful, let me know so I can continue to add more information as well as step-by-step videos on how to do this.

And if you’re as excited about Atlas App Services as I am, create your [first free App](https://www.mongodb.com/atlas/app-services) today!

Use our Atlas App Services application to create a complete push notification system that fits our business logic.

GCP

All GCP Content

Push Notifications Using Atlas App Services & iOS Realm SDK

Serverless MEAN Stack Applications with Cloud Run and MongoDB Atlas

Securely Connect MongoDB to Cloud-Offered Kubernetes Clusters

Getting Your Free MongoDB Atlas Cluster

Start Implementing Google Auth With MongoDB Realm in Your Android App

Related Topics