Serverless change notifier using Mongodb realm (stitch) triggers and AWS eventbridge.

In the world of microservices, events happen all the time and services react as per those events. This becomes an overhead when event is triggered even if there was no meaningful change. In this scenario only raising events if something has actually changed would be very beneficial.

In this article we will learn about, how we can leverage mongodb realm (stitch) triggers along with AWS event bridge to create a serverless change notifier.

Prerequisites

You need basic knowledge of mongodb change streams. What they are and how they work? You can read more on this article Power of MongoDb change streams. You can also read about mongodb realm triggers from official mongodb documentation.

Mongodb Realm (Stitch)

Mongodb realm is a serverless platform that enables developers to quickly build applications without having to set up server infrastructure. Realm is built on top of Mongodb Atlas. There are many use cases of realm and some of them are

• Respond to changes and events (triggers)
• Backend logic with serverless functions (javascript functions)
• Store and query data in mongodb (javascript functions)
• Webhooks
• Push notifications
• …and many more.

We will be focusing on data trigger part as rest of features are out of scope for this article.

Database triggers

Database Triggers allow you to execute server-side logic whenever a document is added, updated, or removed in a linked MongoDB Atlas cluster. You can use database Triggers to implement complex data interactions, including updating information in one document when a related document changes or interacting with a service upon the insertion of a new document.

AWS Eventbridge

Amazon EventBridge is a serverless event bus that makes it easy to connect applications together using data from your own applications, integrated Software-as-a-Service (SaaS) applications, and AWS services. We will be using SaaS part for out use case. There are many SaaS providers supported and mongodb is one of them. Let’s go through some of the terminology used in context of eventbridge.

• An Event bus is a mechanism that allows different components to interact with each other without knowing each other.
• A target processes events. It can include SNS, SQS, Lambda etc..
• A rule matches incoming events and routes them to targets for processing. A single rule can route to multiple targets, all of which are processed in parallel.
• A Partner event source is used by an AWS partner to send events to an AWS customer account. To receive these events, the customer must associate an event bus with the partner event source.

How to connect realm trigger and AWS Eventbridge?

To make a connection we need to do steps on both mongodb atlas and AWS Eventbridge level.

Mongodb Realm Triggers

1. Go to Mongodb atlas console and select triggers from the left hand side menu.

2. Click on Add Trigger. This will open a page which will show options to create a trigger. Select database trigger as trigger type and fill up other details. As soon as you select your cluster in link data source section, it creates a realm app behind the scene. After that you can select database and collection on which you want to be notified and what type of operation.

3. Most important part is function section. We need to select Eventbridge here. It will ask for your aws account id and the region in which your account is. Make sure you add this information correctly.

4. Next optional part is match expression and projection. You can use this if you want to be notified only for specific scenario and specific fields. For example: I want to be only notified if users age is greater than 30.

5. Click on save. As soon as you click on save, it will do following things

• Creates the trigger.
• On AWS, the event bus will be created with the same name as of partner event source “aws.partner/mongodb.com/stitch.trigger/{triggerId}” where triggerId is returned from realm.

After this we would need to perform some steps on AWS Eventbridge side.

AWS Eventbridge

1. Go to AWS Eventbridge and click on Partner event source in left hand side pane. You should see an entry for new event source. It should be like aws.partner/mongodb.com/stitch.trigger/{triggerId} where trigger id is the id of trigger created in mongodb atlas.

2. Select the record and click on Associate with event bus.

3. Once you click on associate, it will create a new custom bus for you. Click on Event bus in left hand section to verify it under custom event bus section.

4. Next click on Rules and select the event bus created above from the drop down and click Create Rule.

5. In the rule details all the fields are self explanatory. You can keep the event pattern as default and select event bus as the one created in above steps.

6. Last step is to set up the target. You can setup multiple targets. For example, send notification to SNS and lambda at the same time. For complete list of targets supported, see here.

You are all set after this. To test this, insert a document in the collection on which trigger was created and you should be notified as per the target set. For example, if SNS was selected and topic was subscribed to an email address, you should receive an email.

How to do all this programmatically?

Mongodb Realm Triggers

There are many ways realm triggers can be created.

• Using official SDKs
• Using official Realm Admin API
• Using nodejs client which uses realm admin api.

Here is an example using nodejs.

AWS Eventbridge

You can use aws sdk as per your preference of language.

Here is an example using nodejs sdk

Please note that this is just an example. In real scenario, you might want to make all these methods upsert. This means get them first and if they exists, call update method else call insert method.

Pricing

• Realm Triggers: It comes with monthly free tier requests. For more details see here.
• AWS Eventbridge: Depending upon region it may vary but it would be around $1.00/million event published. More details see here.

Conclusion

Microservices style architecture may give you problems if you don’t think about the number of events that may happen between different services. This is a problem specially when the number of services grow in your system. In these scenarios having something which can tell if an event should be raised or not depending upon if there was actual change in the data or not will be very beneficial.

This style can also be used to send real time notifications to your underlying AWS services from mongodb side without managing any servers.

I hope you found this post helpful. Feel free to comment in case you have any questions, or you think it can be improved.

Happy coding!