DEV Community: Evan Hameed

Microservice Architecture: Circuit Breakers

Evan Hameed — Sun, 10 Jul 2022 21:54:29 +0000

I have been working lately to implement some techniques regarding fault tolerance and chaos control in a microservice architecture.

I got inspired to write this article after implementing these techniques and reading more about how Netflix utilizes these patterns as well.

Circuit Breakers

It is a design pattern in the microservices world. It acts as a health check and availability controller.

Assuming a system that has a lot of microservices involved.
Microservice A calls Microservice B and for some reason Service B fails to respond due to network issues, logic faults, or availability.

The client might keep requesting a particular action since it has no idea that Microservice B will not be able to fulfill this action. As a result, this will cause low performance to the whole system, provide a bad user experience, and it might also cascade the issue to other healthy microservices.

The circuit breaker controls the flow of requests to the damaged microservice.

It has 3 states:

Closed (Allowing requests to pass through).
Open (Preventing the flow of requests).
Half-Open (Allowing a limited number of requests to pass through)

The behavior is very similar to how electric current flows in a circuit.

In the closed state, the circuit breaker allows the flow of the requests to the microservices. At this state, the circuit breaker counts the amount of failed requests. When it reaches a specified threshold, the circuit breaker will change the state of the circuit to Open.

In the open state, the circuit breaker prevents the flow of the requests to the microservice, sending back a proper error message to the client. After that state, the circuit breaker will change the state of the circuit to Half-open depending on the Half-open time buffer.

In the Half-open state, the circuit breaker allows a limited number of requests to pass through. At the same time, it keeps track of how many of them are succeeding and failing.

If the number of succeeded requests reaches a specific threshold, the Circuit breaker will close the circuit again to ensure the flow of the requests to the microservices.

There are some open-source frameworks that support the implementation of circuit breakers for nodeJs that I find very helpful.

Conclusion

Using Circuit breakers is something that should be considered to help improve the fault tolerance of a microservice architecture. It also provides reliability and prevents the impacted damage to other microservices.

Microservice Architecture: Eventual Consistency

Evan Hameed — Sat, 09 Jul 2022 19:27:13 +0000

The main questions this article will answer:

How to persist data in microservices architecture?
How to get a complex job done in a microservice architecture?

The main idea behind the term Eventual consistency in the microservices world is understanding the best way to complete a complex task is to break the task into smaller tasks and have people independently work on these sub-tasks.

Scenario

Let us imagine an order management system, a microservice communication is applied between an order-service, payment-service, and stock service to fulfill this job.

When a customer places an order, let us assume that the order first goes to the stock service for stock control and availability check. After that, the order is forwarded to the payment service in order to get the money from the customer's visa card. The final step is to insert this order into the database as a record through the order service.

Assuming that an issue occurred in the order service, and the final step is not being completed at that specific timestamp. A data consistency issue occurred.

Approaches to resolve such issues

The question that should be asked in the above scenario is if such an error occurs in the process, Should the whole process be rollbacked?

There is no right approach to choose, it depends on the use case of the process.

1. The first possible solution might be 2PC (two-phase commit).

two-phase commit: In transaction processing, databases, and computer networking, the two-phase commit protocol (2PC) is a type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction.

This technique ensures strong data consistency, but at the same time, it has some drawbacks such as low latency and throughput, slow since it is blocking, and might achieve transactions deadlock.

2. Eventual consistency

Eventual consistency is a technique that ensures data consistency and availability by asynchronous communication and ensuring that when an error occurs in a specific process, the error will be resolved eventually without having to roll back the whole process.

Eventual consistency can be achieved by asynchronous and event-driven communication between microservices via messages and events brokers.

Going back to the example we explained earlier. Every action in the process is basically an event that will be pushed to a certain queue. Each microservice will subscribe and listen to its respective queue. When an error occurs just like the one above, the event will be stored in the queue. And this particular microservice will keep retrying to consume the event until it consumes it successfully and reach the completion state.

This approach can not be achieved with synchronous communication via REST, because REST can not persist events or requests.

References:

Microservices anti-patterns

Evan Hameed — Sat, 04 Jun 2022 15:16:20 +0000

This blog mainly talks about the anti-patterns of building microservice architecture systems.

A microservice architecture helps a lot in many aspects. Readability, Maintainability, scalability, separation of concerns, and many more.

On the other hand, these pros might turn into cons if some anti-patterns are applied in a microservice architecture and it would be very difficult to maintain.

What does anti-pattern mean?

In software engineering and computer science, an anti-pattern is a term that describes how not to solve repetitive recurring issues in your codebase. Therefore they are always considered to be bad practices in the design of systems.

Different Microservices architecture anti-patterns.

1. Distributed Monolithic systems.

This is an anti-pattern that I have experience working with.

A monolithic app means a system that encapsulates the whole logic of the app in one unit or codebase.

One of the mistakes some people do is distributing the logic of that big monolithic app into several small monolithic apps and calling it a microservice architecture.

The fact is these small monolithic apps will eventually chat with others to achieve how the big monolithic app was working.

Any small change in one of these monolithic apps will cause the saga to break. And a change in other systems will be required, and that defeats the purpose of microservice architecture.

2. Cohesion chaos and coupling.

Cohesion in microservice architecture means the amount of how components of a single entity are tied together.

With that being said, a microservice should not care about the components of other entities.

This anti-pattern arises when unrelated components or functionalities are constantly being added to a specific microservice.

3. Dependency distortion.

This anti-pattern also arises when all of the microservices should be deployed in a specific order, otherwise, the saga and the chattiness between the microservices will break.

This is caused by the separation of concerns as well.

4. Shared schemas and datastores.

This is an anti-pattern that occurs when multiple microservices are connected to the same db.

For example, if one microservice needs to change a specific schema due to its internal logic, the microservice that is also connected to that database should adapt to the corresponding change.

4. Actions redundancy.

Action redundancy occurs when there are some functionalities that are occurring in each microservice.

Suppose that, in order for an action to start a saga in the microservices, the user who is doing the action should be authenticated. For that matter, the user should be authenticated once.

Having an API gateway becomes very handy in such situations to centralize shared logic between microservices and also to orchestrate the events between them.

Conclusion

Understanding microservice architecture and its anti-patterns are very important. A lot of complexity might be added trying to apply them without thinking of the overall design of how they should be built.

React Error Boundaries

Evan Hameed — Sat, 21 May 2022 18:39:56 +0000

This article explains how to use React error boundaries to catch errors and shows an abstract error page to inform users that something is not working properly on the website.

How does React handle errors in nature?

When javascript errors occur during rendering, React can not really know how to resolve and recover from them. There is no generic blueprint for React to understand the errors that happen in rendering. It also can not revert back to a stable version before the error occurs. As a result, React unmount all the components as a last resort. That is the reason why when such errors occur, the page goes completely blank as demonstrated below:

Considering this error in this component:

import React from 'react'

const Home: React.FC = () => {
  throw new Error('Error happend!');
  return (
    <div>Home</div>
  )
}

export default Home

The result of that error would look something like this:

The whole components tree got unmounted, this might look very controversial to end-users. They might think that they should wait or that there is something wrong on their end.

Not all users can inspect web pages and find out what is wrong with web applications. Therefore React provides Error Boundaries.

React Error Boundaries

Error boundaries are React components that handle javascript errors anywhere in the components tree by logging them and providing a custom fallback UI to inform users that there is something wrong in the application.

Error Boundaries help in catching errors and prevent unmounting not related components.

Using error boundaries in React application

Create a component, and add the following inside it.

import React from "react";
import ErrorPage from "../components/Error";


interface IErrorBoundryState {
    hasError: boolean;
}
interface IErrorBoundryProps {
    children: React.ReactNode;
}


class ErrorBoundary extends React.Component<IErrorBoundryProps, IErrorBoundryState> {
    constructor(props: IErrorBoundryProps) {
        super(props);
        this.state = { hasError: false };
    }

    static getDerivedStateFromError(error: Error) {
        return { hasError: true };
    }

    componentDidCatch(error: Error, info: any) {
        console.log('Error in component did Catch', error);
        console.log('any info', info);
    }
    render() {
        if (this.state.hasError) {
            return <ErrorPage />; // Fallback Customizable component 
        }
        return this.props.children;
    }
}


export default ErrorBoundary;

All what is left now is to wrap the components we want to catch errors from with the above component. We can wrap specific components, or we can be more generic and wrap the main entry.

import ErrorBoundary from './helpers/ErrorBoundry';

root.render(
  <React.StrictMode>
    <ErrorBoundary>
      <App />
    </ErrorBoundary>
  </React.StrictMode>
);

Now the previous error that we had earlier will be catched with the help of this error boundary as demonstrated in the following:

Conclusion

Error boundaries are very important concepts to handle errors and prevent crashing and unmounting the whole components when any error occurs in web applications. They are also a good way to tell end-users about errors instead of showing blank pages.

Read more about error boundaries in the official docs of React.

Scheduling and delaying queue messages

Evan Hameed — Fri, 20 May 2022 10:07:21 +0000

This article mostly talks about different approaches to scheduling and delaying queue messages and their pros and cons with examples and code.

Recently I have been using Amazon SQS as a queue to produce and consume messages as follows:

Now everything seems to be perfect until when we need to delay messages dynamically on a specific queue.

Now certainly when you end up delaying most of the messages inside all queues, apparently using a queue in the first place is not the ideal technique in this situation.

But sometimes in some odd circumstances, we need to delay some specific messages and hide them from the consumer.

Scenario

Suppose you have an ordering and logistics system.
You order a burger from your favorite restaurant. The restaurant accepts the order. After accepting the order, a driver should get assigned to deliver the order to the customer.

Now let's imagine this process happening over microservices that are listening to respective queues.

What happens is that the restaurant acts as a producer of the message when accepting an order. A logistics microservice that is responsible for assigning orders will consume the produced message immediately.

What's wrong with that?

What if the restaurant takes 30 minutes to prepare the burger. In such a case, assigning a driver to this order will be a bad decision because the driver will be wrongly utilized by going to the restaurant immediately and waiting for the burger to be prepared.

Therefore in this case we want to delay a message for x mins until it reaches y time and then execute the operation.

Different Approaches to apply this delay

Unfortunately, AWS SQS allows to delay messages up to 15 mins. But what if we need to delay it a bit more by x mins dynamically.

1. Simplest solution that might come to our minds, is just to set an in-memory timeout function. If using javascript, then setTimeout. In the producer, we calculate how much we need to delay a specific message and we put it as the interval of the setTimeout function.

Cons:

The function inside the timeout might be blocked by other operations that need to be executed.
If the server restarts for any reason, the delay and timeout will be flushed. For example, pushing a piece of code might cause the server to restart and boot again.

2. Another solution might be sending a timestamp in the producer in which when the message should get consumed.
In the consumer, we check if the timestamp reached what we need. If yes, consume the message. If not push the message back to the queue and don't consume it.

Again this is a bad practice because there will be a loop in the consumer, and some messages will be pushed back to the queue multiple times.

Step functions and state machines.

Now, what if we forward the messages to a state machine instead of the queue immediately. state machines have waiting states and we can specify either the timestamp or duration of how much a message should wait in a state machine.

A simple state machine can achieve the following:

Get a message from the producer.
Wait for x duration.
forward messages to specified queues.

Amazon has a tool called step functions where we can create state machines.

1. Create a State machine in amazon step functions.

2. Add a wait state and specify the waiting time by adding a fixed interval or dynamic one.

3. Step functions allow to trigger other AWS services. In this case SQS, so we add another state that defines how to trigger the SQS by providing the queue URL.

After this step, we will have a working State machine that gets messages, keeping them in a waiting state then forwards them to SQS.

A JSON definition of this state machine would look something like the following:



{
  "Comment": "A description of my state machine",
  "StartAt": "Wait",
  "States": {
    "Wait": {
      "Type": "Wait",
      "Next": "SQS SendMessage",
      "Seconds": 0
    },
    "SQS SendMessage": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sqs:sendMessage",
      "Parameters": {
        "MessageBody.$": "$"
      },
      "End": true
    }
  }
}

The interval can be put dynamic by changing the Seconds param in the waiting state to SecondsPath. Now we can pass it a dynamic variable from the message we send.



"Wait": {
      "Type": "Wait",
      "SecondsPath": "$.expiryInterval", // dynamic variable we pass in the message
      "Next": "SQS SendMessage"
    },

Triggering Step functions from node.js application.




const express = require('express');
const AWS = require('aws-sdk');


const app = express();

app.listen(3000, () => {
    console.log('first server is running on port 3000');
})

AWS.config.update({
    region: 'eu-central-1',
    accessKeyId: process.env.ACCESS_KEY_ID,
    secretAccessKey: process.env.SECRET_ACCESS_KEY,
});

const params = {
    stateMachineArn: process.env.STATE_MACHINE_ARN,
    input: JSON.stringify({ input: 'evan testing', expiryInterval: 10 })
};

const stepfunctions = new AWS.StepFunctions()


stepfunctions.startExecution(params, (err, data) => {
    if (err) {
        console.log(err, err.stack);
    } else {
        console.log(data);
    }
}
);

Conclusion

Queues are not meant to schedule events and actions in the first place. But sometimes such behavior is needed. The easiest and most efficient way that I found is using amazon state machines.

Redis and cache

Evan Hameed — Tue, 17 May 2022 21:33:50 +0000

What is cache?

The cache is an in-memory data store that allows us to store repetitive data for the client.

The cache acts as a near key-value data store to the client applications.

Why is it needed? What about DBMS?

In-memory cache systems like Redis allow us to store data in the physical RAM. Unlike external databases, the data is stored on hard disks or SSDs. With that being said, accessing and retrieving data from cache will be much faster than retrieving it from external data stores.

Hitting the main datastore every time a client makes a request to the API might cause a lot of latency. Specially queries that make a lot of aggregations, lookups, and response time.

In addition to that, it will increase the load and connections on the main database, which will be a reason to increase the resources and allocations of the server running that database.

How does Redis cache work?

Redis becomes very handy because it provides different data types to store such as strings, lists, and hashes.

The whole idea behind how it works is to store the data we get from the main database inside Redis as key-value pair.

The next time we try to get this data, we will check if the data is available in the Redis cache. If yes, the data will be retrieved from Redis without doing further calculations and external Database connections. If the data is not inside the cache, the data will be retrieved from the main DB and later cached inside Redis.

This layer of check can be obtained in multiple ways. One of them is making a global middleware that checks for cache availability as shown below using Express.js:

When an entry in Redis gets expired, the key and value will no longer exist. We can check for the availability of the cache based on the key we store.

const cacheAvailability = (req, res, next) => {
  const { id } = req.params; // or from body or any input we can modify the middleware based on 
  redis.get(id, (error, result) => {
    if (error) throw error;
    if (result !== null) {
      return res.json(JSON.parse(result)); // Parsed because there is a stringified object as a value 
    } else {
      return next();
    }
  });
};

When it should be considered?

There are two terms that should be considered when it comes to caching:
Hit rate: the number of times we actually get the data from the cache and not the external data source.

Miss Rate: The number of times we access the expired cache and get data from the main database.

Caching is meant to store frequently repetitive requested data. Data that is repetitive and not frequently changing. With that being said, the more the hit rate is, the more performance and efficiency we will get in our applications.

Constantly checking for cache, finding it empty, and then getting the data from the main Db and then store in cache is useless.

There should be a persistent relationship between the date we need to cache, how long it will be stored in the cache, and how expensive the operation is if we directly get it from the main database.

Using Webpack with Typescript

Evan Hameed — Fri, 13 May 2022 18:56:47 +0000

What is Webpack all about?

Webpack is a Bundling and building orchestration tool.
It is a tool that helps to serve optimized projects by bundling, cleaning, and minifying code to reduce the downloadable files and provide one bundled file that has all our code inside it.

When to use it?

When working on large projects, We will probably end up with a lot of files in our directory. In addition to that, we will need to export and import these files to connect them together.

If we take a look at a simple web application that has some files and components. these files and components will be served to the browser separately as shown below.

Now as these files get bigger in size, they will cause some latency and make the application slower because these components and files make HTTP requests separately.

Here comes the power of Webpack. It will look into all of the files of the application. It will compress and minify everything, then serve it as shown below.

Simple usage of Webpack with Typescript

To start off with using Webpack with typescript. Some dependencies should be installed.

npm i -D webpack webpack-cli ts-loader typescript webpack-dev-server

These dependencies work hand to hand to compile typescript code to javascript with the help of ts-loader and typescript, then bundle the js code using webpack.

Configuring webpack

webpack.config.js should be created in the root directory.

The first thing we can do in this config file is specifying the entry file of the application which is usually app.ts or index.ts

module.exports = {
  entry: './src/app.ts'
}

Now we have the entry file setup, we can configure information about how and where this bundle file will be.
Usually, when compiling typescript code, the compilation will be stored in a folder called dist (can be renamed) as we specify that in the tsconfig.json.
Same for Webpack config, it needs to know where to exactly bundle. Therefore we set the absolute path of the bundle destination.

const path = require('path');

module.exports = {
  entry: './src/app.ts',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist') 
}
}

After setting all that, Webpack needs to know how to compile these typescript files. we can set a simple regular expression for Webpack to find all typescript files. After setting that we specify that ts-loader that we installed earlier will handle the compilation to Javascript during the bundling process as the following:

const path = require('path');

module.exports = {
  entry: './src/app.ts',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist') 
},
  module: {
    rules : [
     {
       test: /\/.ts$/, 
       use: 'ts-loader',
       exclude: /node_modules/

     }
  ]
}
}

We can add different presets for different file extensions when bundling such as CSS files or images by adding rules to the module.

More to learn about Webpack: https://webpack.js.org/concepts/

Docker and Dockerfile

Evan Hameed — Wed, 04 May 2022 22:06:06 +0000

Overview
Docker is a platform that allows containerizing software projects. What I mean by containerizing, having the source code, packages, and dependencies with their respective versions in one container and running it as a process.

The difference between Docker and VMs is Docker runs containers using the host kernel OS with no guest operating systems. On the other hand, under VMs, the Server hardware is virtualized. Each VM has it is own guest OS. This makes Docker lightweight, consumes fewer resources, and spins apps quicker.

How to Dockerize an application?

Applications get dockerized by first having a blueprint or a snapshot of what to have in the container. This blueprint is called docker image. The image gets specified in a Dockerfile and then we will run this image to create a container of this specific snapshot.

Making the Dockerfile

This file is usually put in the root directory of the application. Each line in this file represents an instruction and a layer of how to build the image.

Let's have a simple express API that runs on node as an example.

1_ Specifying the parent image in the Dockerfile

FROM node:17-alpine

This is the first layer of the Dockerfile. It pulls this image of node and installs it in the container. The tag after the colon is called a tag, it specifies the version of node that needs to be pulled.

2_ Specifying the directory we want to work at on the container.

FROM node:17-alpine
WORKDIR /app

3_ Coping package.json and installing all the dependencies in the container.

FROM node:17-alpine
WORKDIR /app
COPY package.json .  
RUN npm install

4_ Copying the whole source code and pasting it in the container.

FROM node:17-alpine
WORKDIR /app
COPY package.json .  
RUN npm install   
COPY . .

The first dot next to the copy means get the whole directory. The second dot is where to paste the directory in the container. The reason why it is a dot and not /app is that after specifying the WORKDIR /app, all the paths in the container will be relative to /app.

5_ Finally run the app.

FROM node:17-alpine
WORKDIR /app
COPY package.json .  
RUN npm install   
COPY . . 
CMD ['node' , 'start']

Building the image:

Docker build -t [IMAGE_NAME] -p [HOST_PORT]:[EXPOSED_PORT] .

Running the image inside a container:

Docker run —name [CONTAINER_NAME] [IMAGE_NAME]

An alternative for the above commands would be creating a unified compose file that would look like this:

Create docker-compose.yaml next to the project directory.

version: '3.8'
services: 
  api: 
    build: ./api
    container_name: api_container
    ports: 
      - '3000:3000'
    volumes: 
      - ./api:/app
      - ./app/node_modules

Run docker-compose up

What are volumes?

Images are read-only, which means on a testing environment it does not make sense to build an image every time we change the source code. Using volumes here becomes very handy. Volumes allow mapping files from local code to the existing one on the container without building new images.

Some useful docker commands

- Docker ps
    - List all running containers.
- Docker ps -a
    - List all containers
- Docker images
    - List all images

- Docker build -t [IMAGE_NAME] -p [HOST_PORT]:[EXPOSED_PORT] .
    - Build the image

- Docker run —name [CONTAINER_NAME] [IMAGE_NAME]
        - Run the image inside a container.

Resources:

Docker docs

Microservice Architecture - Asynchronous Messaging

Evan Hameed — Fri, 29 Apr 2022 17:40:33 +0000

This article explains the core benefits of asynchronous communication, queues, and microservice architecture.
When, how, and why they should be considered in software projects.

Why asynchronous messaging?

Let us consider the following e-commerce goods business. Customers can buy things online and also get their items delivered immediately.

Let's say these actions are involved in the process:

Sending the order of the customer to the main ordering service
Notify customers back via Email or SMS service.
Sending the action to a logistics service to deliver the order.

First Approach: One component that does all the actions:
A customer buys an item, the order goes to a centralized API that does all required calculations to place payments, discounts, offers, Notifying the customer back, and prepare the delivery of the purchased item.

Second Approach: Using Asynchronous Communication between microservices:
The action of buying an item goes to a queue that acts as a middleware between the customer and the microservices.
After placing the action in the queue, Each microservice will consume the message in the queue and do its own required function.

Advantages of Messaging communication and microservices.

Now when working on a small project that does few simple functionalities, it makes sense to pick the first approach.
When it comes to building a scalable and flexible e-commerce website, picking the second approach will make a lot more sense for the following reasons:

1. Reliability: Having a microservice and messaging communication architecture will allow an ideal flow of data and actions. If one of the microservices is facing downtime, this will not affect the process of ordering, as other microservices will work independently.

2. Consistency of actions: As explained above, when one of the microservices is down, this architecture will ensure that the actions that are needed to be done will not get lost. When this microservice gets fixed, it will consume all the actions that are not implemented yet during the downtime.

3. Scalability: As this e-commerce business grows, more orders will be pushed to the queue exponentially every day. Increasing the instances of these microservices that are acting as consumers will ensure the speed and efficiency no matter how much is the throughput and frequency of these actions.

4. Maintenance: This architecture improves maintainability, as the whole business is separated into smaller divided modules.

5. Testing: this isolation of having grouped functionalities in one microservice will improve the testability of the business, as testing will occur in individual parts of the system.

6. Flexibility: Having such architecture will make it easier in the future to hook other microservices to the business as it won't affect the overall behavior of the system.

Conclusion: We saw the difference between the synchronous and asynchronous systems. Synchronous systems are less reliable and sometimes one small damage in the functionalities or services will cause problems in the whole system.

On the other hand, Asynchronous communication and microservice architecture provide more flexibility, reliability, maintainability, and consistency. Microservices are more independent and reliable.

Examples of messaging queues:

Apache Kafka
RabbitMQ
Amazon SQS

Using Amazon SQS in Nest.

Evan Hameed — Wed, 27 Apr 2022 23:31:48 +0000

I have been working lately with Amazon SQS on a nest project. I thought of sharing the experience with others because it was a headache for me to actually set it up the right way in NestJS.

After trying some different approaches, here is my ultimate SQS setup in nestJS.

Github: https://github.com/evanhameed99/amazon-sqs-nest

First of all: Install below dependencies :

npm i @ssut/nestjs-sqs
npm i aws-sdk

I will mainly tackle two different scenarios:

Producing messages to an existing SQS.
Consuming messages from an existing SQS.

Setting Up the Producer:

Create producer.module.ts

import { Module } from '@nestjs/common';
import { SqsModule } from '@ssut/nestjs-sqs';
import { MessageProducer } from './producer.service';
import * as AWS from 'aws-sdk';
import { config } from '../config';

AWS.config.update({
    region: config.AWS_REGION, // aws region
    accessKeyId: config.ACCESS_KEY_ID, // aws access key id
    secretAccessKey: config.SECRET_ACCESS_KEY, // aws secret access key
});


@Module({
    imports: [
        SqsModule.register({
            consumers: [],
            producers: [
                {
                    name: config.TEST_QUEUE, // name of the queue
                    queueUrl: config.TEST_QUEUE_URL, 
                    region: config.AWS_REGION, // url of the queue
                },
            ],
        }),
    ],
    controllers: [],
    providers: [MessageProducer],
    exports: [MessageProducer]
})
export class ProducerModule { }

Create Producer function in producer.service.ts

import { Injectable } from '@nestjs/common';
import { SqsService } from '@ssut/nestjs-sqs';
import { config } from '../config';
@Injectable()
export class MessageProducer {
    constructor(private readonly sqsService: SqsService) { }
    async sendMessage(body: any) {

        const message: any = JSON.stringify(body);

        try {
            await this.sqsService.send(config.TEST_QUEUE, message);
        } catch (error) {
            console.log('error in producing image!', error);
        }

    }
}

Lastly Import the producer in the root app.module.ts

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ProducerModule } from './producer/producer.module';

@Module({
  imports: [
    ProducerModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Setting up the consumer.

Create consumer.module.ts

import { Module } from '@nestjs/common';
import { SqsModule } from '@ssut/nestjs-sqs';
import { MessageHandler } from './messageHandler';
import * as AWS from 'aws-sdk';
import { config} from '../config';


AWS.config.update({
    region: config.AWS_REGION,
    accessKeyId: config.ACCESS_KEY_ID,
    secretAccessKey: config.SECRET_ACCESS_KEY,
});
@Module({
    imports: [
        SqsModule.register({
            consumers: [
                {
                    name: config.TEST_QUEUE, // name of the queue 
                    queueUrl: config.TEST_QUEUE, // the url of the queue
                    region: config.AWS_REGION,
                },
            ],
            producers: [],
        }),
    ],
    controllers: [],
    providers: [MessageHandler],
})
export class ConsumerModule { }

Set up your message handler to consume the messages messageHandler.ts

import { Injectable } from '@nestjs/common';
import { SqsMessageHandler } from '@ssut/nestjs-sqs';
import * as AWS from 'aws-sdk';
import { config } from '../config';


console.log('config.AWS_REGION', config);
@Injectable()
export class MessageHandler {
    constructor() { }
    @SqsMessageHandler(config.TEST_QUEUE, false)
    async handleMessage(message: AWS.SQS.Message) {
        const obj: any = JSON.parse(message.Body) as {
            message: string;
            date: string;
        };
        const { data } = JSON.parse(obj.Message);

        // use the data and consume it the way you want // 

    }
}

Lastly import the consumer module in app.module.ts

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ConsumerModule } from './consumer/consumer.module';
import { ProducerModule } from './producer/producer.module';

@Module({
  imports: [
    ProducerModule,
    ConsumerModule
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Link to my template repo.