Build a Serverless event-driven application with SNS and Node.js

Photo by Vincent Lin on Unsplash

At Ovrsea, we run on a microservice architecture that is fully Serverless. Microservices trigger many events in destinations to others. Most of these events are handled asynchronously, reducing the coupling and improving system availability.

Here are the benefits of having an event-driven architecture:

• Low coupling between microservices.
• Easier collaboration between teams since each one can work on their microservice.
• Improvement in the request-response time because microservices can handle some actions asynchronously.
• Your system can handle scalability better because you can batch events to be consumed by a service.
• Your system is more fault-tolerant since the messages are stored in a queue; you can replay failed events.

On AWS, there are many services to build event-driven applications like SNS, SQS, Kinesis, Event Bridge, etc.

This post will focus on using SNS to communicate between two microservices.

Example of microservices subscribing to an SNS Topic

What will build

To demonstrate the use of SNS, we will have two microservices:

• User management: expose an endpoint through the API gateway for registering a new user. Once the user is saved, and the event is published to notify other services
• Emails Sender: This microservice listens to many events and sends an email to the corresponding recipient

Here is what our architecture will look like:

The architecture of the system to build

Prerequisites

You must install these tools on your computer to follow this

• Node.js 14+ - Download link
• AWS CLI - Installation guide
• AWS IAM configured - Configuration guide
• Serverless Framework - Installation link

Create the SNS Topic

We use the SNS topic to connect two or many applications; one can publish an event, and all the applications subscribed to this topic will receive that event and act according to the payload.

We can create a topic from the AWS console or through the AWS CLI; here is the command to run:

The TopicArn will be printed in the console, copy it and keep it somewhere; we will use it later:

Create an SNS Topic with the AWS CLI

Press CTRL + C to exit

Note: You must create one topic per environment to avoid sending events to the wrong services.

Set up the project

I prepared a project with the two microservices already built, but they are not communicating together yet. We will update them to make that possible.

Run the commands below to clone the project and set up the user management microservice:

We get the following output:

Locally invoke the Lambda function for user signup

Run the commands below to set up the emails-sender microservice:

We get the following output:

Locally invoke the Lambda function for emails sending

Publish a message in the SNS Topic

To publish a message on a topic, with need the AWS SDK for JavaScript that provides an API to make this call. Let’s install it:

Publishing a message with the SDK required two elements:

• The topic ARN: we created the topic earlier.
• The message: It’s a JSON string with the information the others will use to identify the action to perform. The maximum content size is 256KB.

Update the file user-management/src/functions/signup/handler.ts with the code below:

Let’s permit the Lambda function to publish in the SNS Topic. Update the property provider of the file user-management/serverless.ts by adding the code below:

Subscribe to a message in the SNS Topic

The user-management service publishes an event on the topic, but no service has subscribed to this topic yet. Let’s configure the emails-sender service to subscribe to it.

We need to indicate the event that triggers this Lamdba function which is a message in an SNS Topic. Update the file emails-sender/src/functions/main/index.ts with the code below:

The only remaining thing is to give the SNS subscription to the Lambda function. Update the property provider of the file emails-sender/serverless.ts by adding the code below:

That is it! The only remaining thing to do is update the Lamdba handler to send the email, but we will not cover it for brevity.

Deploy in production and test

Locally, we can only test the two services independently; but to test the whole system, we need to deploy it on AWS. Thank the Serverless Framework that makes it easier for us.

Run the commands below to deploy the two services:

Wait for the deployment to complete, copy the API Gateway URL printed in the terminal of the user-management service

Deploy the Lambda function on AWS

Use an HTTP client to send a request to this endpoint and see the result.

Test the user registration with Postman

In the AWS console, go to the CloudWatch Logs of the emails-sender function; you will see the event log.

CloudWatch logs of the Lambda function that send the emails

The two services communicate together as expected 🎉

Wrap Up

You must think about event-driven architecture for better low-coupled and fault-tolerant services.

AWS provides many services to build event-driven applications. You should pick the one that suits your needs.

Find the source code of this project on the GitLab repository.