DEV Community: Chafroud Tarek

I Built a Terraform Reference Repository (So You Don't Have to Bang Your Head Against the Wall)

Chafroud Tarek — Sun, 12 Oct 2025 12:51:57 +0000

Hey there 👋
Check it out here: GitHub Repository Link

So I've been working with Terraform for a while now, and honestly? It's been a love-hate relationship. More hate than love on some days, if I'm being real.

You know those moments when you're staring at your terminal at 2 AM because a state lock won't release? Or when you accidentally destroy half your infrastructure because you used count instead of for_each? Yeah, we've all been there. Or at least, I hope I'm not the only one.

Why I Built This

After going through the same painful issues over and over (and probably Googling "terraform circular dependency" more times than I'd like to admit), I decided to collect everything in one place. Not just theory or best practices that look good on paper I mean actual working code that you can copy and paste when things go wrong at 2 AM.

The repository includes:

Ready-to-use modules (VPC, EC2, RDS, S3, Security Groups)
Complete environment setups (dev, staging, production)
Real solutions to problems that actually happen
Scripts that make your life easier
A Makefile because who remembers all those commands anyway?

What's Inside

The Modules You Actually Need Not the fancy stuff, just the basics done right:

VPC Module: Public/private subnets, NAT gateways, the whole setup
EC2 Module: Instances with proper security and monitoring
RDS Module: Database with encryption, backups, and auto-generated passwords
S3 Module: Buckets with versioning, encryption, lifecycle rules
Security Groups: Properly structured, no circular dependencies

Each module is battle-tested. I use these in production, and they work.

2. Environment Structure That Makes Sense

environments/
├── dev/
├── staging/
└── production/

Each environment has its own state file, its own backend, and its own everything. Because mixing dev and prod is how disasters happen.

3. The "Oh Crap" Solutions Section

This is probably my favorite part. Real problems with real solutions:
State Locked Forever? Here's how to unlock it safely.
Circular Dependency Hell? Use security group rules instead of inline blocks.
Everything's Being Destroyed? Add lifecycle rules, use for_each instead of count.
Provider Version Conflicts? Lock your versions properly.
I didn't just write about these issues - I included the exact code that fixes them.

4. Scripts That Save Time

init-backend.sh: Sets up your S3 bucket and DynamoDB table for state management
validate-terraform.sh: Runs all checks before you commit
cleanup-workspaces.sh: Because workspace management is annoying

5. A Makefile For the Lazy (Like Me)

bashmake plan ENV=dev make apply ENV=production make validate make security make clean
Done.
No more typing long commands or forgetting flags.
The Stuff I Wish Someone Told Me Earlier
Use for_each, Not count
Seriously. I learned this the hard way when I removed one availability zone from a list and Terraform decided to recreate ALL my subnets. With for_each, removing one AZ only affects that specific resource.

hcl# DON'T do this
resource "aws_subnet" "private" {
  count = length(var.azs)
  # ...
}

# DO this instead
resource "aws_subnet" "private" {
  for_each = toset(var.azs)
  # ...
}
Never Hardcode Secrets

I know it's tempting when you're testing something quickly. But just don't. Use Secrets Manager or Parameter Store. The repo shows you exactly how.
State Locks Are Your Friend (Until They're Not)
Always use DynamoDB for state locking. But when it gets stuck? Don't panic. Check the docs folder - I wrote a whole troubleshooting guide.

Format Your Code
Run terraform fmt before every commit. Future you will thank present you. Or set up pre-commit hooks and never think about it again.
Real Talk About Modules

I see a lot of people either:
Putting everything in one giant main.tf file (chaos)
Creating overly complex modules that do too much (also chaos)

The modules in this repo are focused. Each one does ONE thing well. Need a VPC? Use the VPC module. Need a database? Use the RDS module. Mix and match as needed.

What This Repo Is NOT
This is not a framework. It's not "the one true way" to do Terraform. It's not going to revolutionize your DevOps workflow.
It's a reference. A starting point. A "here's what worked for me, maybe it'll work for you too" kind of thing.
The Validation Process
Because we all know that one person who applies without planning first...

bashmake validate # Checks everything make format # Formats your code make lint # Runs tflint if you have it make security # Runs tfsec security scan

All of this runs before you push. Saves you from embarrassing PR comments.

Contributing
Look, I don't know everything. I've probably made mistakes in this repo. Some best practices might be outdated by the time you read this.
That's why it's open for contributions. If you find a bug, fix it. If you have a better solution, share it. If you think something is missing, add it.
The goal is to make this actually useful for people, not to have a perfect repo that I gatekeep.
Lessons I Learned Building This
1. Documentation matters more than you think
I added comments and README files everywhere. Because I've opened my own code months later and had no idea what I was doing.
2. Working examples > theory
Every module has a usage example. Every common issue has a solution with code. No "exercise left to the reader" nonsense.
3. Keep it simple
I removed probably 30% of what I initially built because it was overcomplicated. If you can't understand it in 5 minutes, it's too complex.
4. Test everything
I deployed every module to a test environment. Found bugs. Fixed them. Then found more bugs. That's how it works.

Getting Started

bashgit clone <repo-url>
cd terraform-infrastructure

# Set up your backend
./scripts/init-backend.sh your-bucket-name terraform-locks us-east-1

# Copy example variables
cd environments/dev
cp terraform.tfvars.example terraform.tfvars

# Edit with your values
vim terraform.tfvars

Initialize and plan

make init ENV=dev
make plan ENV=dev
That's it. No complicated setup. No dependencies hell. Just Terraform.

Final Thoughts
Building infrastructure shouldn't feel like black magic. It shouldn't require you to memorize 47 different command flags or spend hours debugging cryptic error messages.
This repo is my attempt to make it a bit easier. It's not perfect, but it's better than what I had when I started.
If it helps even one person avoid a 2 AM debugging session, I'll consider it a success.

Check it out here: GitHub Repository Link
And if you use it and find it helpful (or find bugs), let me know. I'd love to hear about it.
Happy terraforming 🚀

P.S. If you've never used Terraform before, this might be a good starting point. If you're a Terraform expert, you'll probably find things to improve. Either way, contributions are welcome.
P.P.S. Yes, I know there are other Terraform best practices repos out there. This one is mine. It has my specific pain points and solutions. Maybe yours are similar. Maybe not. That's okay.

Found this helpful? Give it a ⭐ on GitHub. Have suggestions? Open an issue. Want to argue about best practices? The comments are below.

Guide: Hosting Multiple Applications on a VPS Without Registered Domains

Chafroud Tarek — Sat, 20 Jan 2024 14:04:11 +0000

In this guide, we'll explore a practical solution for hosting multiple applications on a Virtual Private Server (VPS) without the need for registered domain names. We'll focus on setting up two front-end applications, one for clients and another for administrators, along with a back-end application to handle the server-side functionalities.

So, first of all, we need to install the following packages:

sudo apt update
sudo apt install nginx
sudo apt install nodejs npm 
sudo apt install git

Secondly, navigate to the 'www' folder by executing the following command

cd /var/www

Once inside this folder, we will pull our projects from GitHub. In my case, I have three projects: "front-client," "front-admin," and "back-api".

git clone ....

Now, when I run 'ls,' I should see the three folders:

Go to the 'front-client' and build it. In my case, I use Node.js, so I will just run:

cd front-client
npm run build

Repeat the same process for 'front-admin.' After building, I will have two folders: 'dist' and 'build.'

Note: You might get the same names for both folders, so ensure to change their names or place them in different locations, not at the same level.

After building:
move to /var/www and run :

cp -r ./front-client/dist  ./
cp -r ./front-admin/build  ./

This will move our build to the 'www' folder.

Then, move to Nginx to set up our config:

cd /etc/nginx/sites-availables
touch front-client
cd /etc/nginx/sites-enabled
touch fromt-client 
ln -s /etc/nginx/sites-available/front-client /etc/nginx/sites-enabled/front-client

With these commands, we create two files and use ln to create links between them. This means if we change one, the other will be automatically updated. Repeat the same process for 'front-admin' and the API.

*for the admin file enter the following : *

server {
    listen 80;
    server_name 162.19.256.134(your vps ipv4);
    location / {
     root /var/www/build/;
     index inde.htm index.html;
     try_files $uri $uri/ /index.html;
    }
 }

the same for the client file just change the port :

server {
    listen 90;
    server_name 162.19.256.134(your vps ipv4);

    location / {
        root /var/www/dist/;
        index index.html;
        try_files $uri $uri/ /index.html;

        add_header 'Access-Control-Allow-Headers' '*' always;
        add_header 'Access-Control-Allow-Methods' '*' always;
    }
}

and we end up with our api file :

server {
    listen 60;
    server_name 162.19.256.134(your vps ipv4);

    location / {
        proxy_pass http://localhost:4242;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;

         if ($http_origin = "http://162.19.256.134(your vps ipv4):70") {
            add_header 'Access-Control-Allow-Origin' 'http://162.19.253.131:70' always;
        }

        if ($http_origin = "http://162.19.256.134(your vps ipv4):80") {
            add_header 'Access-Control-Allow-Origin' 'http://162.19.253.131:80' always;
        }
        add_header 'Access-Control-Allow-Headers' '*' always;
        add_header 'Access-Control-Allow-Methods' '*' always;
    }
}

The final step involves starting Nginx. Execute the following commands:

sudo systemctl start nginx
nginx -t

This will start Nginx and verify its configuration.

Now, you can visit your sites at (your VPS-IPv4):70 and (your VPS-IPv4):80.

And here we can say that we have reached the end of our blog. I hope you find it useful and informative for more tips you can follow me here linkedin.

Part 2: Setup Dashboard with grafana and nestjs

Chafroud Tarek — Wed, 03 Jan 2024 19:29:08 +0000

With the help of this blog,where we'll walk you through using Grafana to create a dynamic dashboard and NestJS to export data with ease. In just a few easy steps, up your data visualisation game and simplify backend development. Are you ready to turn unstructured data into meaningful dashboards? Let's get started! 🚀🏊

Part One:
In the initial phase, we'll configure Prometheus with our Nest app. This ensures that the app can export data via specific endpoints. Prometheus will then scrape this data and seamlessly export it to Grafana.

1/
we need to install willsoto:
yarn add @willsoto/nestjs-prometheus prom-client
or
npm install @willsoto/nestjs-prometheus prom-client

2/
In the app module imports, be sure to include the following:
PrometheusModule.register({ path: '/app-metrics', }),

this specifies the endpoint where the Prometheus metrics will be exposed.

Similarly, in the AppModule providers, make sure to include:



 makeCounterProvider({
      name: 'count',
      help: 'metric_help',
      labelNames: ['method', 'origin'] as string[],
    }),
 makeGaugeProvider({
      name: 'gauge',
      help: 'metric_help',
    }),

FEEL FREE TO CUSTOMIZE THEM ACCORDING TO YOUR PREFERENCES.
makeCounterProvider is likely a function or method provided by the @willsoto/nestjs-prometheus library to create a Prometheus Counter metric

name: Specifies the name of the metric. In this case, it's set to "count"
help: Provides a description or help text for the metric.
labelNames: Specifies label names for the metric. Labels are key-value pairs that allow you to differentiate between different dimensions of the metric. In this case, labels for 'method' and 'origin' are defined.

3/
In order to capture all requests, we must add intercepts to our root application



export class AppModule {
  configure(consumer: MiddlewareConsumer) {
   //forRoutes('yourRootapi')
    consumer.apply(MetricsMiddleware).forRoutes('/api');
  }
}

We must include something similar to this in our interceptors:
two essential steps are necessary. First, define our metrics, and second, explore them to export significant data



@Injectable()
export class CustomMetricsMiddleware implements NestMiddleware {

  public customDurationGauge: Gauge<string>;
  public customErrorsCounter: Counter<string>;

  constructor(
    // Must be identical to those declared in our AppModule
    @InjectMetric('count') public appCounter: Counter<string>,
    @InjectMetric('gauge') public appGauge: Gauge<string>,
  )
{
 // Customizing the names and help messages for metrics
    this.customDurationGauge = new Gauge<string>({
      name: 'app_duration_metrics',
      help: 'app_concurrent_metrics_help',
      labelNames: ['app_method', 'app_origin', 'le'],
    });
    this.customErrorsCounter = new Counter<string>({
      name: 'app_error_metrics',
      help: 'app_usage_metrics_to_detect_errors',
      labelNames: ['app_method', 'app_origin', 'app_status'],
    });
}

In this example, I utilize counter metrics to count the number of requests based on method and origin, and gauge metrics to calculate the duration of each request.



 use(req: Request, res: Response, next: NextFunction) {
    // Incrementing custom counter and gauge
    this.appCounter.labels(req.method, req.originalUrl).inc();
    this.appGauge.inc();

    // Recording start time for measuring duration
    const startTime = Date.now();

    // Setting up a callback for when the response finishes
    res.on('finish', () => {
      // Calculating the duration and recording it in the custom duration gauge
      const endTime = Date.now();
      const duration = endTime - startTime;
      this.customDurationGauge
        .labels(req.method, req.originalUrl, (duration / 1000).toString())
        .set(duration);

      // Incrementing the custom errors counter based on the response status code
      this.customErrorsCounter.labels(req.method, req.originalUrl, res.statusCode.toString()).inc();
    });

    // Continuing with the middleware chain
    next();
  }

Part Two:
In the next section, we'll shift our focus to Grafana aiming to consume metrics and visually them in a meaningful way:

So the initial step is to log in using admin/admin for the first sign-in and configure the data source like the example below :

Now, we will begin with our dashboard:

visit Grafana dashboards and search for "Node Exporter Full"

and copy the ID:

You need to choose a datasource that matches the name you used before:

and BOOM NOW WE HAVE A DASHBOARD :

YOU CAN CUSTOMIZE YOUR DASHBOARD AS YOU WANT FOR EXAMPLE FOR THE COUNTER THAT WE EXPORT FROM OUR NESTJS APP WE CAN VISUALIZE IT THERE LIKE THIS WAY :

And here we can say that we have reached the end of our blog. I hope you find it useful and informative. for more tips you can follow me here linkedin.

PART 1: How to Set Up Grafana and Prometheus Using Docker

Chafroud Tarek — Sat, 02 Dec 2023 11:23:54 +0000

Ready to supercharge your NestJS applications? In this blog, we'll walk through the easy steps of setting up Grafana and Prometheus with Docker. Say hello to seamless monitoring and visualization, making your development journey smoother and more insightful. Let's dive into the world of containerized deployment together and add a visual edge to your NestJS projects, bringing your data to life in a way that goes beyond performance metrics.

This will be a comprehensive guide :

1. Create a Docker Compose file named 'docker-compose.monitoring.yml' in your main project

2. Create a folder named "config" and inside it config/prometheus.yaml create file named promtheus.yaml

We need four essential components to establish a monitoring setup: Prometheus, Grafana, cAdvisor, and Node Exporter :

Prometheus: An open-source monitoring and alerting toolkit designed for reliability and scalability. Prometheus collects and stores time-series data, allowing for querying and analysis.

Grafana: A popular open-source platform for monitoring and observability. Grafana provides a customizable dashboard for visualizing and analyzing metrics from various data sources, including Prometheus.

cAdvisor: Short for Container Advisor, cAdvisor is an open-source container monitoring tool. It analyzes resource usage and performance characteristics of running containers, providing valuable insights into containerized environments.

Node Exporter: A Prometheus exporter that collects hardware and OS-level metrics from Linux and other Unix-like systems. Node Exporter enables monitoring of host-level resources and performance metrics.

Let's dive into practice again 🔥

in our "docker-compose.monitoring.yml" file we need to add the code below :

--First One :



version: '3.8'
networks:
  monitoring:
    driver: bridge

In this step, we set the Docker Compose version to 3.8 and define a custom network named "monitoring" with the bridge driver.

-- Second One:



volumes:
  prometheus-data:
    driver: local
  grafana-data:
    driver: local

This step creates local volumes named "prometheus-data" and "grafana-data" for persistent storage.

-- Third One: Service 1: prometheus :



prometheus:
  image: prom/prometheus:v2.37.9
  container_name: prometheus
  ports:
    - 9090:9090
  command:
    - '--config.file=/etc/prometheus/prometheus.yaml'
  volumes:
    - ./config/prometheus.yaml:/etc/prometheus/prometheus.yaml:ro
    - ./data:/prometheus
  restart: unless-stopped

Image: Specifies the Docker image for Prometheus and its version.
Container Name: Assigns a specific name to the Prometheus container.
Ports: Maps the host machine's port 9090 to the container's port 9090 for accessing Prometheus.
Command: Sets the configuration file path for Prometheus.
Volumes: Binds local directories for Prometheus configuration and data persistence.
Restart: Ensures that the Prometheus container restarts unless explicitly stopped.

-- Service 2: Grafana :



grafana:
  image: grafana/grafana-oss:latest
  container_name: grafana
  ports:
    - '3000:3000'
  volumes:
    - grafana-data:/var/lib/grafana
  restart: unless-stopped

-- Service 3 : node-exporter:



node_exporter:
  image: quay.io/prometheus/node-exporter:v1.5.0
  container_name: node_exporter
  command: '--path.rootfs=/host'
  pid: host
  restart: unless-stopped
  volumes:
    - /:/host:ro,rslave

-- Service 4 : cAdvisor:



cadvisor:
  image: gcr.io/cadvisor/cadvisor:v0.47.0
  container_name: cadvisor
  command:
    - '-port=8098'
  volumes:
    - /:/rootfs:ro
    - /var/run:/var/run:ro
    - /sys:/sys:ro
    - /var/lib/docker/:/var/lib/docker:ro
    - /dev/disk/:/dev/disk:ro
  devices:
    - /dev/kmsg
  privileged: true
  restart: unless-stopped

So the result will be like this 🚨:



version: '3.8'
networks:
  monitoring:
    driver: bridge
volumes:
  prometheus-data:
    driver: local
  grafana-data:
    driver: local
services:
  prometheus:
    image: prom/prometheus:v2.37.9
    container_name: prometheus
    ports:
      - 9090:9090
    command:
      - '--config.file=/etc/prometheus/prometheus.yaml'
    volumes:
      - ./config/prometheus.yaml:/etc/prometheus/prometheus.yaml:ro
      - ./data:/prometheus
    restart: unless-stopped
  grafana:
    image: grafana/grafana-oss:latest
    container_name: grafana
    ports:
      - '3000:3000'
    volumes:
      - grafana-data:/var/lib/grafana
    restart: unless-stopped
    #password: root123
  node_exporter:
    image: quay.io/prometheus/node-exporter:v1.5.0
    container_name: node_exporter
    command: '--path.rootfs=/host'
    pid: host
    restart: unless-stopped
    volumes:
      - /:/host:ro,rslave
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.47.0
    container_name: cadvisor
    command:
      - '-port=8098'
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    devices:
      - /dev/kmsg
    privileged: true
    restart: unless-stopped

Now, let's dive into the Prometheus configuration file:
in our config/prometheus.yaml file we need to define the scarpe configurations :



global:
  scrape_interval: 15s

Sets a global scrape interval of 15 seconds. This means Prometheus will collect metrics from configured targets at this interval



scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['myapi:6003']
    metrics_path: '/tam-metrics'

Defines a scrape configuration for a job named 'prometheus'.
scrape_interval: 5s: Overrides the global scrape interval for this specific job to 5 seconds.
static_configs: Specifies a list of statically configured targets.
targets: ['myapi:6003']: Indicates that Prometheus should scrape metrics from the target 'myapi' on port 6003.
metrics_path: '/tam-metrics': Specifies the path where Prometheus should scrape metrics for this job.



  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node_exporter:9100']

Adds another job configuration named 'node-exporter'.
targets: ['node_exporter:9100']: Indicates that Prometheus should scrape metrics from the target 'node_exporter' on port 9100.



  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8098']

targets: ['cadvisor:8098']: Specifies that Prometheus should scrape metrics from the target 'cadvisor' on port 8098.

the full result will be like this :



global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['myapi:6003']
    metrics_path: '/tam-metrics'
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node_exporter:9100']

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8098']

to run all this just type in terminal :

docker-compose -f docker-compose.monitoring.yml up -d

and BOOM 🤯:

Prometheus

Grafana

first time login : admin/admin

So, here we are, reaching the conclusion of this section. We've successfully configured our containers, everything is running smoothly, and we've achieved some impressive results. But hold on, this is just the beginning! The real magic happens when we dive into configuring our dashboards and exporting metrics from our Nest app. Get ready for some visual delights! Stay tuned for Part 2, where we'll explore these exciting aspects in detail. See you there for an adventure in data visualization.

👋 You can also Contact me and follow my posts in Linkedin

Dockerizing a NestJS app and persisting data

Chafroud Tarek — Sun, 29 Oct 2023 15:33:02 +0000

It has been a while since our last post, and we have successfully achieved our goal of reaching 20k this year. I am extremely glad, and this achievement motivates me to do a lot more. Hopefully, this year, Inshallah, we will reach 50k. Anyway, let's begin. Our topic revolves around Dockerizing a NestJS app and persisting data.

In this scenario, I'll be utilizing PostgreSQL and Prisma. I'll assume you're already familiar with creating a NestJS application and integrating Prisma. If not, please leave a comment below, and I'll create a dedicated post on the process.

1- Setup your nestjs app

2- Add dockerFile:
Create it as a regular file within your project, not within the 'src' directory but at the same level as 'package.json'. Simply name it Dockerfile
i will explain it line by line :
▶ builder stage:
❶ : FROM node:latest AS builder :
- This line sets the starting point for building our Docker image by using the most recent version of Node.js from Docker Hub.

 ❷ : WORKDIR /app :
        -  Sets the working directory inside the Docker container to /app

❸ : COPY package*.json ./
    COPY prisma ./prisma/ : 
       - COPY package*.json ./ and COPY prisma ./prisma/: Copies the package.json and package-lock.json files as well as the prisma directory from the host machine to the /app directory in the container

❹ : RUN npm install --force :
- Executes the npm install command to install the project dependencies defined in package.json.

❺ : COPY . . :
- Copies all files from the current directory of the host machine to the /app directory in the container

❻ : RUN npm run build :
- Executes the command to build the project

▶ Final stage : This is the final image that will be created. It's based on the Node.js image without any specific name/alias.

copies only the essential artifacts needed to run the application from the "builder" stage (node_modules, package*.json, dist directory). This selective copying helps keep the final image small and efficient.

❶ : FROM node:latest

❷ : WORKDIR /app

❸ :
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/dist ./dist
- Copies specific directories from the 'builder' stage to the respective directories in the new stage

     ❹ : EXPOSE 3000 : 
   -  Informs Docker that the container listens on port 3000 at runtime

    ❺ : CMD [ "npm", "run", "start:prod" ]:
  - Specifies the default command to be executed when the container starts

the final result :



FROM node:latest AS builder

WORKDIR /app

COPY package*.json ./
COPY prisma ./prisma/

RUN npm install --force

COPY . .

RUN npm run build

FROM node:latest

WORKDIR /app

COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/dist ./dist

EXPOSE 3000
CMD [ "npm", "run", "start:prod" ]

The next crucial step is to generate a 'docker-compose.yml' file at the same level as the 'Dockerfile'.

❶ : version: '1.1' # Specifies the version of the Compose file format being used.
❷ : services: will contain our services :

the final result will be like this :



version: '3.8'
services:
  prisma-migrate:
    container_name: prisma-migrate
    build:
      context: prisma
      dockerfile: Dockerfile
    environment:
      DATABASE_URL: ${DATABASE_URL}
    depends_on:
      - postgres

  postgres:
    image: postgres:13
    container_name: postgres
    restart: always
    ports:
      - '5432:5432'
    env_file:
      - .env
    volumes:
      - postgres:/var/lib/postgresql/data

  pgadmin:
    image: dpage/pgadmin4
    restart: always
    container_name: nest-pgadmin4
    environment:
      - PGADMIN_DEFAULT_EMAIL=admin@admin.com
      - PGADMIN_DEFAULT_PASSWORD=pgadmin4
    ports:
      - '5050:80'
    depends_on:
      - postgres

volumes:
  postgres:
    name: nest-db

and now just run : *docker compose up -d *

Hopefully, this brings value and aids you,Feel free to leave a comment if this was helpful or if you have any questions. I'm here and ready to provide further assistance.for more tips you can follow me here linkedin.

Testing in NestJS: A Comprehensive Guide

Chafroud Tarek — Thu, 06 Jul 2023 13:43:44 +0000

In this blog, we'll explore testing authentication in NestJS. We'll cover strategies, tools, and best practices to ensure robust authentication mechanisms. Topics include unit testing and mocking dependencies. By the end, you'll gain a comprehensive understanding of how to effectively test authentication in your NestJS applications.

Below, you will find the default content of the file, which serves as a starting point for testing. If you are already familiar with tests, you'll quickly grasp its structure and purpose. However, if you're new to testing, don't worry—I'll provide detailed explanations with comments for each part to help you understand it better.

Now we will test the resolver/controller (are the same) :

▪️ the first case is the signup

1️⃣ : On the providers, you need to add all the services you use. In my case, it would be like this

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        AuthResolver,
        AuthService,
        PasswordService,
        JwtService,
        PrismaService,
        ConfigService,
      ],
    }).compile();

    resolver = module.get<AuthResolver>(AuthResolver);
    authService = module.get<AuthService>(AuthService);
  });

⚠️: I added the authService because I will use it later to spy actions performed by my resolver.

2️⃣ : add the test case :

3️⃣ : mock the input data and the tokens

   const data: SignupInput = {
      email: 'test@example.com',
      roleId: 'admin',
      password: 'password',
      username: 'testName',
    };
 const tokens = {
    accessToken: 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJmb29',
    refreshToken: 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJmb29',
  };

4️⃣ : we need to spy the createUser method that exist on our authService by using this line :

//spyOn: allows you to create a spy on a particular method of an object or class
const createUserSpy = jest.spyOn(authService, 'createUser');
// mock the resolved value of the createUser method 
 createUserSpy.mockResolvedValue(tokens);

5️⃣ : mock the cookies

 const cookieMock = jest.fn();
 response.cookie = cookieMock;

6️⃣ : and now it's time to calling the signup method of the resolver object, which corresponds to the signup resolver function

 // It will simulate the signup process using our mock data
  const result = await resolver.signup(data, response);

7️⃣ : and the last steo is to set the expectations :

expect(createUserSpy).toHaveBeenCalledWith(data, response);
    expect(cookieMock).toHaveBeenCalledWith(
      'refreshToken',
      tokens.refreshToken
    );
    expect(result).toEqual(tokens);

The final result : 👇

With the same way we can test the others :

▪️ Login:

▪️ RefreshToken:

▪️ decodeUser:

Finally,
I don't test all cases to keep the blog lightweight. Feel free to message me for more details or if you have any questions. I hope you find it enjoyable. See you in another blog 👋.

React Testing with the help of storybook stories

Chafroud Tarek — Mon, 26 Jun 2023 05:59:57 +0000

In our latest blog post on creating components with Storybook, we will leverage the existing stories of our button components to create comprehensive test cases using Testing Library.

You can refer to the official documentation for setting up Testing Library
https://testing-library.com/docs/react-testing-library/setup/

The first step is to create our testing file, in my case "button.test.tsx", and add the necessary imports.

and this is the full example:

// Describe block for the Button Component
describe('Button Component', () => {

  // Test case for rendering primary button
  test('should render primary button', () => {
    render(<Primary {...Primary.args} />);
    expect(screen.getByRole('button')).toHaveTextContent('Button');
  });

  // Test case for rendering secondary button
  test('should render secondary button', () => {
    render(<Secondary {...Secondary.args} />);
    expect(screen.getByRole('button')).toHaveTextContent('Button');
  });

  // Test case for rendering danger button
  test('should render danger button', () => {
    render(<Danger {...Danger.args} />);
    expect(screen.getByRole('button')).toHaveTextContent('Button');
  });

  // Test case for rendering disabled button
  test('should render disabled button', () => {
    render(<Disabled {...Disabled.args} disabled />);
    const buttonElement = screen.getByRole('button');
    expect(buttonElement).toBeDisabled();
  });

  // Test case for rendering button instead of spinner when not loading
  test('should render button instead of spinner when not loading', () => {
    render(<Loading {...Loading.args} loading={false} />);
    expect(screen.getByRole('button')).toHaveTextContent('Button');
  });

  // Test case for rendering Spinner instead of button when loading
  test('should render Spinner instead of button when loading', () => {
    render(<Loading {...Loading.args} />);
    const spinnerElement = screen.getByTestId('spinner');
    expect(spinnerElement).toBeInTheDocument();
  });

});

Let's explore a couple more test cases, focusing on the Select component and the Login/Signup form:

▪️ Select component:

// Import necessary libraries and components
import React from 'react';
import { render, screen } from '@testing-library/react';
import InputSelect, { Option } from '.';

// Describe block for the InputSelect component
describe('InputSelect', () => {

  // Define options array for testing
  const options: Option[] = [
    { value: 'option1', label: 'Option 1' },
    { value: 'option2', label: 'Option 2' },
    { value: 'option3', label: 'Option 3' },
  ];

  // Create a mock onChange function
  const mockOnChange = jest.fn();

  // Test case for rendering label and options correctly
  test('should label and options correctly', () => {
    render(<InputSelect label='Select' options={options} value={null} onChangeAction={mockOnChange} />);

    // Get elements from the rendered component
    const labelElement = screen.getByText('Select');
    const selectElement = screen.getByRole('combobox');
    const optionElements = screen.queryAllByRole('option');

    // Assert label and select elements are in the document
    expect(labelElement).toBeInTheDocument();
    expect(selectElement).toBeInTheDocument();

    // Assert select element has correct aria-label attribute
    expect(selectElement).toHaveAttribute('aria-label', 'Select');

    // Assert each option element has correct text content
    optionElements.forEach((option, index) => {
      expect(option).toHaveTextContent(options[index].label);
    });
  });

  // Test case for rendering error message when error prop is provided
  test('should render error message when error prop is provided', () => {
    // Define an error object
    const error = { message: 'This field is required' };

    render(<InputSelect label='Select Option' options={options} value={null} error={error} onChangeAction={mockOnChange} />);

    // Get the error message element
    const errorMessage = screen.getByText('This field is required');

    // Assert error message is in the document
    expect(errorMessage).toBeInTheDocument();
  });
});

▪️ Login form:

// Import necessary functions and components from testing libraries
import { render, screen, fireEvent, act } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from '.';

// Describe block for the LoginForm Component
describe('LoginForm Component', () => {

  // Test case for rendering the login form correctly
  test('should render the login form correctly', () => {
    render(<LoginForm onhandleSubmit={() => {}} loading={false} />);

    // Get form elements
    const emailInput = screen.getByTestId('email');
    const passwordInput = screen.getByTestId('password');
    const rememberMeCheckbox = screen.getByLabelText('Remember me');
    const signInButton = screen.getByRole('button', { name: 'Sign in' });
    const signupLink = screen.getByRole('link', { name: 'Signup' });

    // Assert form elements are in the document
    expect(emailInput).toBeInTheDocument();
    expect(passwordInput).toBeInTheDocument();
    expect(rememberMeCheckbox).toBeInTheDocument();
    expect(signInButton).toBeInTheDocument();
    expect(signupLink).toBeInTheDocument();
  });

  // Test case for displaying error messages when form validation fails
  test('should display error messages when form validation fails', async () => {
    render(<LoginForm onhandleSubmit={() => {}} loading={false} />);

    // Get form elements
    const emailInput = screen.getByTestId('email');
    const passwordInput = screen.getByTestId('password');
    const signInButton = screen.getByRole('button', { name: 'Sign in' });

    // Simulate form submission
    await act(async () => {
      userEvent.click(emailInput);
      userEvent.click(passwordInput);
      fireEvent.click(signInButton);
    });

    // Get error messages
    const emailErrorMessage = screen.getByTestId('email-error');
    const passwordErrorMessage = screen.getByTestId('password-error');

    // Assert error messages are in the document
    expect(emailErrorMessage).toBeInTheDocument();
    expect(passwordErrorMessage).toBeInTheDocument();
  });

  // Test case for calling onhandleSubmit when form is submitted
  test('should call onhandleSubmit when form is submitted', async () => {
    // Mock the handleSubmit function
    const mockHandleSubmit = jest.fn();
    render(<LoginForm onhandleSubmit={mockHandleSubmit} loading={false} />);
    const emailInput = screen.getByTestId('email');
    const passwordInput = screen.getByTestId('password');
    const signInButton = screen.getByRole('button', { name: 'Sign in' });

    // Simulate form submission
    await act(async () => {
      userEvent.type(emailInput, 'test@test.com');
      userEvent.type(passwordInput, 'test123');
      fireEvent.submit(signInButton);
    });

    // Assert that handleSubmit function was called
    expect(mockHandleSubmit).toHaveBeenCalled();
  });
});

▪️ Signup form:

import { render, screen, fireEvent, act } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import RegisterForm from '.';

// Describe the RegisterForm component test suite
describe('RegisterForm Component', () => {
  // Define options for the select input
  let options = [{ label: 'lessor', value: 'lessor' }];

  // Test case for rendering the RegisterForm correctly
  test('should render the login form correctly', () => {
    render(<RegisterForm onhandleSubmit={() => {}} loading={false} roles={options} />);

    // Get form inputs and buttons
    const usernameInput = screen.getByTestId('username');
    const emailInput = screen.getByTestId('email');
    const passwordInput = screen.getByTestId('password');
    const selectInput = screen.getByTestId('selectrole');
    const signInButton = screen.getByRole('button', { name: 'Sign up' });
    const signupLink = screen.getByRole('link', { name: 'Login' });

    // Assert form elements are in the document
    expect(usernameInput).toBeInTheDocument();
    expect(emailInput).toBeInTheDocument();
    expect(passwordInput).toBeInTheDocument();
    expect(selectInput).toBeInTheDocument();
    expect(signInButton).toBeInTheDocument();
    expect(signupLink).toBeInTheDocument();
  });

  // Test case for displaying error messages when form validation fails
  test('should display error messages when form validation fails', async () => {
    render(<RegisterForm onhandleSubmit={() => {}} loading={false} roles={options} />);

    // Get form inputs and submit button
    const emailInput = screen.getByTestId('email');
    const passwordInput = screen.getByTestId('password');
    const signInButton = screen.getByRole('button', { name: 'Sign up' });

    // Simulate form submission
    await act(async () => {
      userEvent.click(emailInput);
      userEvent.click(passwordInput);
      fireEvent.click(signInButton);
    });

    // Get error messages
    const emailErrorMessage = screen.getByTestId('email-error');
    const passwordErrorMessage = screen.getByTestId('password-error');

    // Assert error messages are in the document
    expect(emailErrorMessage).toBeInTheDocument();
    expect(passwordErrorMessage).toBeInTheDocument();
  });

  // Test case for submitting the form with valid data
  test('should submit the form with valid data', async () => {
    const handleSubmit = jest.fn();

    render(<RegisterForm onhandleSubmit={handleSubmit} loading={false} roles={options} />);

    // Simulate form submission with valid data
    await act(async () => {
      fireEvent.change(screen.getByTestId('username'), { target: { value: 'testname' } });
      fireEvent.change(screen.getByTestId('email'), { target: { value: 'email@provider.com' } });
      fireEvent.change(screen.getByTestId('password'), { target: { value: 'test123' } });

      fireEvent.click(screen.getByTestId('selectrole'));

      const optionElements = screen.queryAllByRole('option');
      optionElements.forEach((option, index) => {
        fireEvent.click(screen.getByRole('button', { name: 'Sign up' }));

        // Assert option text content and form submission
        expect(option).toHaveTextContent(options[index].label);
        expect(handleSubmit).toHaveBeenCalled();
      });
    });
  });
});

We have reached the end of the process. If you have any further questions or need more tips, feel free to contact me. 👋

How to document components with storybook

Chafroud Tarek — Sun, 18 Jun 2023 14:07:37 +0000

After covering the setup process for Storybook, let's move on to the next topic: documenting components using this tool.

So first, we need to set up the paths from which Storybook will learn the files. In my case, I'm using the following setup:

▶️ .storybook/main.js

stories: [ // '../stories/**/*.mdx', // '../stories/**/*.stories.@(js|jsx|ts|tsx)' '../components/**/*.mdx', //this the main part for learn stories from components folder '../components/**/*.stories.@(js|jsx|ts|tsx)', '../app/**/*.stories.@(js|jsx|ts|tsx)', ],

by the way .mdx : for writing structured documentation and composing it with interactive JSX elements.

Second, we need to create a file with this extension : .stories.tsx
on my case :

To add the necessary imports, include the following lines of code:

Next, we move on to the main part of the process.

*The tags: ['autodocs'] * property will automatically generate a section that contains all the information about the props and the values they should take.

The last part is to create the stories based on the arguments (props) that each story should take.

the result will be like this:

another example of spinner component



import type { Meta, StoryObj } from '@storybook/react';
import Spinner, { sizetype } from './index';
import { action } from '@storybook/addon-actions';

const meta: Meta<typeof Spinner> = {
  title: 'Spinner',
  component: Spinner,
  tags: ['autodocs'],
};

export default meta;
type Story = StoryObj<typeof Spinner>;

export const DefaultSpinner: Story = {
  args: {
    size: sizetype?.default,
  },
};

export const SmallSpinner: Story = {
  args: {
    size: sizetype?.small,
  },
};

export const LargeSpinner: Story = {
  args: {
    size: sizetype?.large,
  },
};

let take a more complicated case on like login form :
Here is the code with comments for explanations :

And this is very impressive as it showcases the powerful capabilities of Storybook, including simulating and testing components in an interactive manner.

We have reached the end of the process. If you have any further questions or need more tips, feel free to contact me. 👋

HOW TO SETUP STORYBOOK WITH NEXTJS

Chafroud Tarek — Mon, 12 Jun 2023 08:15:20 +0000

Introduction:

Storybook is a vital tool for developing and documenting UI components.
It enables isolated component environments for efficient testing and sharing.
With its visual reference, Storybook promotes better collaboration and understanding within teams.
By showcasing components in different states, it ensures UI consistency and improves the developer experience.
Overall, Storybook streamlines development, enhances code quality, and encourages modular and reusable code.

The version of Storybook used in this tutorial is 7.0.11.

1/ Initialization
Storybook simplifies the setup process with its handy initializer: npx sb init. This initializer automatically detects the project type and adjusts accordingly. However, we can provide additional hints if needed.

For projects using Next.js v11 and later, which utilize Webpack 5, we can enhance integration and performance by configuring Storybook to use Webpack 5 as well. To achieve this, we utilize the builder option and execute the following command:



npx sb init --builder webpack5

2/ Add webpack resolution:

//package.json



 "resolutions": {
    "webpack": "^5"
  }

3/ in your .storybook/main.js file may you need this changes:

4/ a custom preview.js and main.js files you can use

▶️ ./peview.js



import '../styles/main.scss';
import * as NextImage from 'next/image';

const OriginalNextImage = NextImage.default;

Object.defineProperty(NextImage, 'default', {
  configurable: true,
  value: (props) => <OriginalNextImage {...props} unoptimized />,
});

export const parameters = {
  actions: { argTypesRegex: '^on[A-Z].*' },
  controls: {
    matchers: {
      color: /(background|color)$/i,
      date: /Date$/,
    },
  },
  previewTabs: {
    'storybook/docs/panel': { index: -1 },
  },
};

▶️ ./main.js



// .storybook/main.js

const path = require('path');

module.exports = {
  //To specify the location from which Storybook should read stories..
  stories: [
    '../stories/**/*.mdx',
    '../stories/**/*.stories.@(js|jsx|ts|tsx)',
    '../components/**/*.mdx',
    '../components/**/*.stories.@(js|jsx|ts|tsx)',
  ],
  // Specify the  location of our styles
  staticDirs: ['../public'],
  framework: '@storybook/nextjs',
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    '@storybook/addon-interactions',
    '@storybook/addon-coverage',
    {
      /**
       * NOTE: fix Storybook issue with PostCSS@8
       * @see https://github.com/storybookjs/storybook/issues/12668#issuecomment-773958085
       */
      name: '@storybook/addon-postcss',
      options: {
        postcssLoaderOptions: {
          implementation: require('postcss'),
        },
      },
    },
  ],
  core: {
    builder: 'webpack5',
  },
  webpackFinal: (config) => {
    /**
     * Add support for alias-imports
     * @see https://github.com/storybookjs/storybook/issues/11989#issuecomment-715524391
     */
    config.resolve.alias = {
      ...config.resolve?.alias,
      '@': [path.resolve(__dirname, '../src/'), path.resolve(__dirname, '../')],
    };

    /**
     * Fixes font import with /
     * @see https://github.com/storybookjs/storybook/issues/12844#issuecomment-867544160
     */
    config.resolve.roots = [path.resolve(__dirname, '../public'), 'node_modules'];

    return config;
  },
};

⚠️ : if you will use this file you need to install all of the addons :



npm i  @storybook/addon-links
npm i  @storybook/addon-essentials
npm i  @storybook/addon-interactions
npm i  @storybook/addon-coverage,

We will discuss this section and its utilities in upcoming chapters:

5/ in your package.json you will have something like this:
./scripts:

6/ To run Storybook, simply type



yarn run storybook



npm run storybook

you will get this :

In the upcoming chapters, we will cover the following topics:

1️⃣ Creating Components: We will learn how to create components in Storybook.

2️⃣ Testing Components with Storybook: We will explore how to leverage Storybook to test and showcase your components in isolation.

3️⃣ Creating Interactions and Scenarios: We will dive into creating interactive stories and scenarios within Storybook, enabling you to simulate user interactions and showcase different usage scenarios of your components.

MongoDB Relationships(one-to-one)(one-to-many)(many-to-many)

Chafroud Tarek — Fri, 05 May 2023 13:33:44 +0000

Step into the captivating world of MongoDB relationships, where data entities intertwine to form a powerful network of connections. In this blog, we embark on an exciting journey to unravel the mysteries of establishing relationships in MongoDB. Discover how MongoDB revolutionizes data organization, querying, and insights, as we explore the seamless power of connections. Join us as we unlock the true potential of data connectivity, reshaping the way we perceive and interact with information.

Let's Start 💻

Before diving into MongoDB relationships, let's table two essential concepts: Embedded Documents and Document References:

Embedded Documents:
In MongoDB, embedded documents allow us to nest related data within a single document.
Imagine you and your family living in a cozy home. In MongoDB, embedded documents are like each member of your family having their own room within that home. one 👨‍👩‍👧‍👦 one 🏫.

Document References:
Document References, on the other hand, establish relationships between documents by referencing one document from another.
Imagine a scenario where you have one family, but each member of this family lives alone in their own separate dwelling. one 👨‍👩‍👧‍👦 but each 👦 alone:

▶️: One-to-one
let's start with this powerful relation in mongodb:
One-to-one relationships can be likened to the scenario where each individual possesses only one passport.

▶️: One-to-Many
In a one-to-many relationship, it's similar to the idea that an author can write many books, but each book is written by only one author.

▶️: Many-to-Many

In a many-to-many relationship, it's similar to the concept that students can join multiple courses, and each course can be joined by multiple students.

In conclusion, MongoDB offers a wide range of relationship types, including one-to-one, one-to-many, and many-to-many. Developers can choose between embedding and referencing to establish connections between data.

With embedding, related data is stored within a single document, providing a self-contained structure that simplifies queries and improves performance. On the other hand, referencing involves storing references to related documents, allowing for more flexibility and scalability in managing interconnected data.

By leveraging these relationship modeling techniques, developers can design efficient and intuitive database schemas. MongoDB's support for both embedding and referencing empowers developers to optimize data storage, query performance, and data integrity according to their specific application requirements.

Whether you're building applications that require simple or complex relationships, MongoDB provides the necessary tools and flexibility to represent and manage connections between data effectively.

Securing Your Website: Protecting Against Top Cyber Attacks

Chafroud Tarek — Sat, 25 Feb 2023 16:21:44 +0000

Hello everyone 👋😁, I hope you're doing well. I'm excited to be back with a new blog post. Let's dive in and explore some interesting ideas together.

As a website owner, you put a lot of time and effort into creating your website.

But what happens when your website is attacked?❌

Unfortunately, website attacks are becoming increasingly common, and they can cause serious damage to your website's reputation and your users' personal information. In this article, we'll discuss some common attacks and how you can protect your website against them.

We will be discussing some of the most famous cyber attacks:

1/ Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a type of attack where a malicious user injects code into your website, which can then be executed by unsuspecting users. This can result in the theft of sensitive information, such as login credentials and personal information.

✅ To protect your website against XSS attacks, you can sanitize user input to ensure that any potentially malicious code is removed. You can also use Content Security Policy (CSP) to prevent the execution of any unauthorized scripts.

2/ SQL Injection

SQL Injection is a type of attack where a malicious user injects SQL code into your website's database, allowing them to access or modify sensitive information.

✅ To protect your website against SQL injection attacks, you should use prepared statements or parameterized queries to prevent the injection of malicious SQL code. You should also ensure that your website's database is properly secured, with strong passwords and limited access rights.

3/ Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS)

Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks are designed to overwhelm your website with traffic, rendering it inaccessible to legitimate users.

✅ to protect your website against DoS and DDoS attacks, you can use a web application firewall (WAF) to filter out malicious traffic. You can also implement rate-limiting to limit the amount of traffic that can be sent to your website from a single IP address.

4/ Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a type of attack where a malicious user tricks a legitimate user into executing a command on your website without their knowledge or consent.

✅ To protect your website against CSRF attacks, you can use anti-CSRF tokens to ensure that any request made to your website is legitimate. You can also implement double-submit cookies or same-site cookies to prevent unauthorized requests.

5/ Brute Force Attacks

Brute Force Attacks are a type of attack where a malicious user tries to guess a user's login credentials by trying different combinations of usernames and passwords.

✅ To protect your website against brute force attacks, you should enforce strong password policies, such as requiring users to use a combination of uppercase and lowercase letters, numbers, and special characters. You can also implement rate-limiting to limit the number of login attempts that can be made in a given period.

6/ Malware Attacks

Malware Attacks are a type of attack where a malicious user injects malware into your website, which can then infect your users' devices.

✅ To protect your website against malware attacks, you should ensure that your website's software is up-to-date, including any plugins or third-party software. You should also use a web application firewall to filter out any malicious traffic and regularly scan your website for any vulnerabilities.

By taking these measures, you can protect your website against a wide range of attacks. It's important to stay vigilant and stay up-to-date with the latest security trends and best practices to ensure that your website is protected against new and emerging threats. Remember, a little prevention can go a long way in keeping your website safe and secure.

In conclusion, protecting your website against attacks is a critical aspect of website ownership. In this article, we discussed some common attacks and how you can protect your website against them. By implementing measures such as sanitizing user input, using Content Security Policy (CSP), prepared statements or parameterized queries, rate-limiting, anti-CSRF tokens, strong password policies, and regularly scanning your website for vulnerabilities, you can safeguard your website against a wide range of attacks. It's important to stay informed about new and emerging threats and stay up-to-date with the latest security trends and best practices to ensure that your website remains secure. Remember, prevention is key in keeping your website safe and protecting your users' personal information.

Refresh Token implementation in Reactjs

Chafroud Tarek — Mon, 09 Jan 2023 07:58:10 +0000

In this tutorial, you will learn how to use refresh tokens to maintain access to a user's resources in your React application. Refresh tokens allow the application to obtain a new access token without requiring the user to re-authenticate, making it a useful tool for long-lived or background applications. Follow along as we walk through the process of implementing refresh token functionality in React.

You can check my previous post about Refresh Token implementation in nodejs

👋 You can also check my weekly posts in Linkedin

Requirements

Basic knowledge of reactjs.
Basic Knowledge of axios.

To get started, create a new file in your React app which you can name "axios.js" and place in a "helpers" folder, or anywhere else in your app as desired. This file will be used to set up and customize your application's HTTP requests with the axios library, and it will include all the logic for your refresh token implementation. It's a simple process, so let's get started!

start with :

const customFetch = axios.create({
  baseURL: "http://localhost:3000/api/",
  headers: {
    "Content-type": "application/json",
  },
  withCredentials: true,
});

This code creates a custom instance of the axios library with a specific configuration.

The baseURL field sets the base URL for all API endpoints that this instance will be used to call.In this case, it is set to "http://localhost:3000/api/".
The headers object defines the default headers that will be sent with every request made using this instance.
the withCredentials a boolean value that indicates whether or not to send the "Cookie" header with requests. When set to true, the "Cookie" header will be sent with every request.

You can use this custom instance of axios to make HTTP requests in the same way as the default axios object. The main advantage of using this custom instance is that it includes the default configuration specified in this code, so you don't have to include these options in every request.

▪️ To clarify, this interceptor can also be added for the purpose of retrieving the accessToken from local storage and including it in the Authorization header of the requests.

customFetch.interceptors.request.use(
  async (config) => {
    const token = getTokenFromLocalStorage();
    if (token) {
      config.headers["Authorization"] = ` bearer ${token}`;
    }
    return config;
  },
  (error) => {
    return Promise.reject(error);
  }
);

Now we will focus on the crucial part of this blog: the code below is responsible for refreshing the access token by sending a request to the server with the refresh token and receiving a new access token in the response.

const refreshToken = async () => {
  try {
    const resp = await customFetch.get("auth/refresh");
    console.log("refresh token", resp.data);
    return resp.data;
  } catch (e) {
    console.log("Error",e);   
  }
};

This is a function that sends a GET request to the "auth/refresh" endpoint using the customFetch instance of axios. If the request is successful, the function logs the response data to the console and returns it. If the request fails, the function logs the error to the console

▪️ The important interceptor for today is the code below:

customFetch.interceptors.response.use(
  (response) => {
    return response;
  },
  async function (error) {
    const originalRequest = error.config;
    if (error.response.status === 403 && !originalRequest._retry) {
      originalRequest._retry = true;

      const resp = await refreshToken();

      const access_token = resp.response.accessToken;

      addTokenToLocalStorage(access_token);
      customFetch.defaults.headers.common[
        "Authorization"
      ] = `Bearer ${access_token}`;
      return customFetch(originalRequest);
    }
    return Promise.reject(error);
  }
);

The interceptor function takes two arguments: a response object containing the response data, and an error object in case of a rejected response. The function returns the response object or a rejected Promise with the error object.

The interceptor first checks if the response has a status of 403 (Forbidden) and if the _retry property of the original request is not set. If both conditions are met, it sets the _retry property to true and calls the refreshToken function to attempt to refresh the access token. If the refresh is successful, the new access token is added to local storage and the Authorization header of the customFetch instance is updated with the new token. The original request is then retried with the updated customFetch instance. If the refresh is not successful or if the original response did not have a status of 403, the interceptor returns a rejected Promise with the error object.

This interceptor will be called for every response received by the customFetch instance of axios, and will attempt to refresh the access token and retry the request if the access token has expired and the server returns a 403 status code.

In conclusion: In this tutorial, we learned how to use refresh tokens to maintain access to a user's resources in a React application. We set up a custom instance of the axios library with a specific configuration, including an interceptor to add an Authorization header with a bearer token to every request. We also implemented another interceptor to handle expired access tokens by attempting to refresh the token and retrying the original request. With these techniques, we can keep our application authenticated and maintain access to the user's resources without requiring the user to continually provide their login credentials.