DEV Community: The Ecstatic Engineer

Deploying Novu on a Virtual Machine

The Ecstatic Engineer — Sun, 18 May 2025 21:00:00 +0000

Any good product these days must have some way to send notifications to users across different channels. As an engineer, building and managing the infrastructure required can be a time-consuming endeavour, especially if we have complex scenarios and multiple notification channels. In this article, we will be looking at how to deploy Novu, an open-source notification system, on a virtual machine.

Let's get started!

Getting Started

This article is the second part of a short series on deploying Novu, an open-source notification system. The first part of the article can be read here.

This article builds on the first one, so it is necessary to read that first.

When deploying to a VM using just the VM's IP address, the official guide is sufficient.

However, if we need our setup to use domain names or subdomains, we need to make some changes to our .env files in our Docker folder.

This article focuses on using Nginx as a proxy server on a Linux virtual machine. To properly set up our Novu application, we must also make some changes to our Nginx configuration.

Let's assume that we want to deploy our Novu applications to the following URLs:

Novu Application: http://notifications.example.com
Novu Websocket URL: http://notifications-ws.example.com

We use a different URL for the WebSocket service because the WebSocket URL has to be configured to a root path.

Configuring Nginx to Serve Our Applications

We need different Nginx configurations for the various parts of the app.
One thing to note is to make sure that the root path points to the web app.
Since we can only have one root path per configuration, we need a different configuration that will have a root path that points to the WebSocket service.

Let's create a configuration for our Nginx server in the /etc/nginx/sites-enabled folder:

> cd /etc/nginx/sites-enabled

# create a new file
> sudo touch novu

# open the file for editing
> sudo vim novu

Next, we edit the content of the config file to proxy for both the Novu app and the API:

server {
    server_name notifications.example.com;
    access_log  /var/log/nginx/access.log;
    client_max_body_size 40M;

    location / {
        proxy_pass http://localhost:4200;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /api {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        rewrite ^/api/(.*) /$1 break;
    }
}

Here we configure our Nginx to proxy all requests to http://notifications.example.com to the container running on http://localhost:4200, which is the Novu application dashboard.

We also configure http://notifications.example.com/api to proxy to http://localhost:3000, which is the Novu API server. The last line rewrite ^/api/(.*) /$1 break; ensures we strip away the /api/ before forwarding it to localhost:3000.

Since our WebSocket service will be on a different path, let's create a new Nginx config for the WebSocket service:

# create a new file
> sudo touch novu-ws

# open the file for editing
> sudo vim novu-ws

We then add the Nginx config for WebSocket to novu-ws:

server {
    server_name notifications-ws.example.com;
    access_log  /var/log/nginx/access.log;
    client_max_body_size 40M;

    location / {
        proxy_pass http://localhost:3002;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Here, we proxy all traffic to http://notifications-ws.example.com to the WebSocket service running on http://localhost:3002. The request is upgraded to a WebSocket request, and a timeout is also set.

Configuring the Novu Application

Once we have Nginx configured, we must configure our Novu application to reference the new URLs.

Let's edit the content of our .env file in the folder containing our Novu Docker compose file:

> cd novu/docker/community

# open the file for editing
> sudo vim .env

Since we have absolute paths for the Novu Dashboard, API, and WebSocket, we need to update our .env file to reference these new locations.

First, let's add the absolute URLs as variables:

## code committed for brevity

# Host
HOST_NAME=https://notifications.example.com
API_HOST_NAME=https://notifications.example.com/api
WS_HOST_NAME=https://notifications-ws.example.com

Next, we change the values for API_ROOT_URL and REACT_APP_WS_URL:

# Root URL
REACT_APP_WS_URL=$WS_HOST_NAME

# code committed for brevity
API_ROOT_URL=$API_HOST_NAME

We then rebuild our Docker containers and restart nginx:

> sudo docker compose down

# start container
> sudo docker compose up -d

# restart Nginx 
> sudo systemctl restart nginx

The Novu dashboard should be available on http://notifications.example.com.
The API URL and Websocket should be available on http://notifications.example.com/api and http://notifications-ws.example.com, respectively.

We can secure our application by configuring SSL for our application using this LetsEcrypt guide.

Conclusion

In the second part of our series, we focus on configuring our Novu application when hosting it on a virtual machine.

Delploying Novu on Local Machine

The Ecstatic Engineer — Sat, 10 May 2025 21:11:09 +0000

The Ecstatic Engineer

May 10 '25

Run Novu on a Local Machine

#novu #opensource #docker #notifications

Comments

6 min read

Run Novu on a Local Machine

The Ecstatic Engineer — Sat, 10 May 2025 21:06:08 +0000

Any good product these days must have some way to send notifications to users across different channels. As an engineer, building and managing the infrastructure required can be a time-consuming endeavour, especially if we have complex scenarios and multiple notification channels. In this article, we will learn how to deploy Novu, an open-source notification system, to solve this problem.

What Is Novu?

Novu is an open-source notification system that is used to send notifications over multiple channels, such as Chat, Email, SMS, In-App, and Push.

One great feature of Novu is that it allows non-technical people to create and manage Notification workflows. This means the engineering team is not bogged down with always making the smallest changes when required.

Another great feature of Novu is the <Inbox /> component for web apps that enables real-time notifications. With a few lines of code, we get an Inbox that is real-time and reactive.

The easiest way to get started with using Novu is to sign up for a plan and start integrating right away.

To have more control over the usage and data, let's deploy and configure our own version of Novu.

Deploying Using Docker

This post serves to complement the official Novu documentation, including some tips and tricks to make deployment easier on a local machine.

This article uses Windows OS for our deployment, but the commands are the same for Linux, with some slight modifications.

First, we need to make sure Docker and docker-compose are installed.

Next, let's pull the code into a folder:

> git clone --depth 1 https://github.com/novuhq/novu

Let's open the docker/community folder and create a copy of the default environment variables:

> cd novu/docker/community

> copy .env.example .env
# For Linux, use cp instead of copy

This will create a copy of the .env.example and copy it into .env file.

We need to change some configurations in our .env file to make our deployment more secure. The following settings should be changed:
JWT_SECRET
STORE_ENCRYPTION_KEY must be 32 characters long.
NOVU_SECRET_KEY
MONGO_INITDB_ROOT_USERNAME
MONGO_INITDB_ROOT_PASSWORD

We can use the Guid for the secret keys. Let's use PowerShell to generate Guid:

PS> New-Guid

This command will generate a 32-character Guid for us to use. We can generate as much as we need for our configuration.
For the STORE_ENCRYPTION_KEY, we must remove the dashes (-) from the generated Guid.

Once we have our configuration set, let's start running the app in Docker detached mode:

> docker compose up -d

If, while running docker compose, we get an error that indicates that a port is in use, we can change to a different port in our .env file.

For example, if we get an error that port 3000 is in use, we must change all references to port 3000 in the .env file. We can change it to 3001.

We can then view the app on http://localhost:4200, create an account, sign in, and complete the onboarding.

Following the on-screen instructions will lead to creating an account on Novu, which is great. In our case, we want to set up all our services locally.

If, after onboarding, the app does not redirect to the workflows, we use http://localhost:4200/workflows/create to navigate to the page to create new workflows.

Setting up the Bridge Application and Local Studio

After onboarding, we need to set up our Bridge Application and Local Studio.

The Bridge Application is the application where workflows are written. Consider workflows as definitions of how notifications are processed.

The Local Studio provides a way to define detailed workflows programmatically or using the Visual Editor. This makes it easy to define, test, and refine workflows before moving them to production.

Setting up the Bridge Application

To initialize our Bridge Application, we first need to get an API key from our application. We can get our API Key from our application dashboard or via the URL http://localhost:4200/api-keys.

Let's create the Bridge Application:

> npx novu@latest init --secret-key=<secret key> --api-url=<api-url>

Here, the <secret key> is the API key we get from our dashboard. The <api-url> is the deployed API URL, including the port number as defined by API_ROOT_URL in our .env file. In this case, http://localhost:3000.

We then install the dependencies and run the application:

> npm install

# Run the bridge application
> npm run dev

Let's verify that our bridge is working using the URL http://localhost:4000/api/novu. We should get a JSON response that should indicate that the server is running:

{
  "status": "ok",
  "sdkVersion": "2.6.6",
  "frameworkVersion": "2024-06-26",
  "discovered": {
    "workflows": 1,
    "steps": 2
  }
}

Using the Bridge Application URL as Bridge URL

We also need to set up to use the Bridge URL as a tunnel instead of the auto-generated one.

If using Linux, we can just run the following command:

> npx novu@latest dev -d <application_url> -p <bridge_application_port>

In this case, <application_url> is http://localhost:4200 and <bridge_application_port> is 4000.

But since we are using Windows, we need to make changes to our docker-compose.yml file for our Novu application.

Let's stop our Docker instance:

> docker compose down

Then we add the following configuration to each service in our docker-compose.yml file:

extra_hosts:
    - "host.docker.internal:host-gateway"

We must add the configuration to the api, web, worker, and ws services in the docker-compose.yml file:

#code omitted for brevity
web:
    image: 'ghcr.io/novuhq/novu/web:2.1.1'
    depends_on:
      - api
      - worker
    container_name: web
    restart: unless-stopped
    logging:
      driver: 'json-file'
      options:
        max-size: '50m'
        max-file: '5'
    environment:
      REACT_APP_API_URL: ${API_ROOT_URL}
      REACT_APP_ENVIRONMENT: ${NODE_ENV}
      REACT_APP_WIDGET_EMBED_PATH: ${WIDGET_EMBED_PATH}
      REACT_APP_IS_SELF_HOSTED: 'true'
      REACT_APP_WS_URL: ${REACT_APP_WS_URL}
    ports:
      - 4200:4200
    command: ['/bin/sh', '-c', 'pnpm run envsetup:docker && pnpm run start:static:build']
    extra_hosts:
      - "host.docker.internal:host-gateway"
#code omitted for brevity

As a last step, let's add our Novu API URL to the .env.local of our bridge application:

NOVU_API_URL=<api_url>

In this case, our <api_url> is http://localhost:3000. This will help prevent issues with the local studio authenticating against the API URL.

The .env.local also contains values for secret key, application identifier, and subscriber ID. We can change these values if we do a key rotation or want to test with a different subscriber.

Finally, let's run the bridge application again:

> npx novu@latest dev -d <dashboard_url> -p <bridge_port> -t <tunnel_url>

Here, the <dashboard url> is http://localhost:4200, the <bridge_application_port> is 4000 and the <tunnel url> is http://host.docker.internal:4000.

The Local Studio will open on http://localhost:2022. It will also authenticate against the main app running on http://localhost:4200.

Using Local Studio to Create Workflows

It is important to note that to start creating workflows in the Local Studio, we have to do so programmatically in code.

First, let's create a new workflow folder named event-notification in the workflows folder in our Bridge Application folder. The folder is located in app/novu/workflows/event-notification.

Next, let's create a workflow named eventNotification in the workflow.ts file:

import { workflow } from "@novu/framework";
import { payloadSchema } from "../welcome-onboarding-email/schemas";

export const eventNotification = workflow(
  "event-notification",
  async ({ step, payload }) => {
    await step.inApp("In-App Step", async () => {
      return {
        subject: payload.inAppSubject,
        body: payload.inAppBody,
        avatar: payload.inAppAvatar,
      };
    });
  },
  {
    payloadSchema,
  }
);

Then we go to /app/api/novu and add our new workflow to routes.ts file:

import { serve } from "@novu/framework/next";
import { welcomeOnboardingEmail } from "../../novu/workflows";
import { eventNotification } from "../..//novu/workflows/event-notification/workflow";

export const { GET, POST, OPTIONS } = serve({
  workflows: [welcomeOnboardingEmail, eventNotification],
});

We can then view the new workflow on the workflows page of the Local Studio.

Syncing Changes From Local Studio to Novu Application

Once we make changes to our workflow on the Local Studio, we need to sync it to the main app running on https://localhost:4200:

> npx novu@latest sync --bridge-url <bridge_url> --secret-key <secret_key> --api-url <api_url>

Here, the <bridge_url> is http://host.docker.internal:4000/api/novu, and the <api_url> is http://localhost:3000. The <secret_key> is the key we get from the dashboard of our Novu application.

Promoting a Workflow From Development to Production

After developing a workflow using the Local Studio and syncing it to the Novu application, the workflow will show up on the development environment on our Novu dashboard.

To make the workflow available on the production environment, we must promote it.

To do this, we use the URL http://localhost:4200/changes to see all the workflow changes and promote the workflows to production.

Tip: The <Inbox /> component is currently undergoing a lot of updates. If it's throwing a 400 error, use the npm version 3.1.0.

Conclusion

In the article, we learned how to deploy and configure Novu, an open-source notifications system using Docker. We also learned how to use the Local Studio to create workflows, sync the workflows to the Novu app, and promote workflows from development to production.

Resources

List of URLs:

Dashboard URL: http://localhost:4200
Bridge Application URL: http://localhost:4000/
Bridge API URL: http://localhost:4000/api/novu
Bridge Tunnel URL: http://host.docker.internal:4000/api/novu
Local Studio URL: http://localhost:2022/studio
API URL: http://localhost:3000/v1
Websocket URL: http://localhost:3002

Solving Port Exhaustion Issue In .NET

The Ecstatic Engineer — Mon, 24 Feb 2025 07:43:40 +0000

When developing applications that connect to an external resource such as databases, queues, or storage systems, we use classes that make these connections by abstracting away the underlying implementation.

In this article, we will look at how to properly use such classes to avoid port exhaustion.

Let's get started!

Port Exhaustion Issue

When we access external resources over TCP or UDP, we do so over a port. And while there are 65,535 ports available, our system can quickly run out of ports to use if we improperly instantiate classes that use these ports.

A good example of such a class in .NET is the HttpClient class. Other examples include classes in the Azure SDK such as:

ServiceBus.Messaging.QueueClient for Azure Service Bus
Azure.Documents.Client.DocumentClient for Azure Cosmos DB
StackExchange.Redis.ConnectionMultiplexer for Redis Cache
Azure.Storage.Blobs for Azure Storage Blob

These classes ought to be instantiated once and used for the lifetime of the application.

When we use HttpClient to request a URL:

public class HttpService
{
    public HttpService() { }

    public async Task<string> GetDataAsync()
    {
        string url = "https://www.google.com";

        using var _client = new HttpClient();

        var response = await _client.GetStringAsync(url);

        Console.WriteLine(response);
        return response!;
    }
}

Here, we can see that we instantiate a new HttpClient each time we want to make a request to the URL. While this may work fine for an application that is run once, this could lead to socket exceptions when we have an application that processes a lot of requests e.g. a web application.

When this happens, our application throws a SocketException error:

"An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"

Diagnosing Port Exhaustion Issues

Port exhaustion issues can lead to SocketException errors and increased resource usage which will make our applications unresponsive.

One quick way of diagnosing the problem is to run the netstat command:

> netstat

This would produce a list of running processes accessing the ports and we can quickly see which process has opened a lot of ports:

Properly Instantiating Classes

To solve this, we must instantiate one instance of the class if the class is thread-safe. This can be achieved by creating a shared singleton instance or a pool of instances.

We can refactor our HttpService to use a single instance of HttpClient:

public class HttpService
{
    private static HttpClient? _client;

    public HttpService()
    {
        _client = new HttpClient();
    }

    public async Task<string> GetDataAsync()
    {
        string url = "https://www.google.com";

        var response = await _client!.GetStringAsync(url);

        Console.WriteLine(response);
        return response!;
    }
}

Here, we can see that we declare a static instance of the HttpClient and initialize it once. This ensures that only one instance of the HttpClient is used throughout the lifetime of the application.

If our application is using Dependency Injection, we can inject the HttpClient by registering it during startup:

public void ConfigureServices(IServiceCollection services)
{
    services.AddHttpClient();
}

We can then access the HttpClient in our code:

public class HttpService
{
    private readonly IHttpClientFactory _clientFactory;

    public HttpService(IHttpClientFactory clientFactory)
    {
        _clientFactory = clientFactory;
    }

    public async Task<string> GetDataAsync()
    {
        string url = "https://www.google.com";

        HttpClient _client = _clientFactory.CreateClient();
        var response = await _client!.GetStringAsync(url);

        Console.WriteLine(response);
        return response!;
    }
}

Properly Instantiating Azure Services

Let's look at how to instantiate some Azure services in a way that doesn't lead to part exhaustion.

If our application uses Dependency Injection, we could easily use the Azure extension method to register our services and let the Inversion of Control library manage the pool of resources:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAzureClients(builder =>
    {
        builder.AddBlobServiceClient("ConnectionString");

        builder.AddServiceBusClient("ConnectionString");
    });
}

Here, we use the Azure SDK extension to register our Azure Blob and Azure Service Bus services.

We can then use the services in our code:

public class ServiceClass 
{
    private readonly ServiceBusClient _client;
    private readonly BlobServiceClient _blobServiceClient;

    public ServiceClass(ServiceBusClient client, BlobServiceClient _blobServiceClient)
    {
        _client = client;
        _blobServiceClient = blobServiceClient;
    }
}

For Azure CosmosDb, we create a singleton that can be reused across our application. We do this because the CosmosClient is thread-safe and one instance can be shared:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<CosmosClient>(provider => 
    {
        CosmosClientOptions cosmosClientOptions = new CosmosClientOptions()
        {
            ConnectionMode = ConnectionMode.Direct
        };

        var client = new CosmosClient("Connection string", "Authentication Key", cosmosClientOptions);

        return client;

    }
}

Conclusion

Properly instantiating classes that use the network helps us avoid issues within our application. In this article, we learned how to avoid instantiating these classes in a way that will not lead to port exhaustion and other issues in our application.

Useful links:

Implementing Breadcrumbs in React using React Router v6

The Ecstatic Engineer — Sat, 28 Sep 2024 21:57:56 +0000

Breadcrumbs are important in the development of webpages as they provide users with a way to keep track of their current location within our webpage and also aid in the navigation of our webpage.

In this guide, we will be implementing breadcrumbs in React using react-router v6 and Bootstrap.

React-router v6 is a routing library used in React and React Native for navigating within a webpage or web app.

Our implementation uses Typescript but it can also easily be used for a Javascript based project.

Setting up

First, let's install react-router-dom in our project if it hasn't already been installed:

npm install react-router-dom

Or alternative, using yarn:

yarn add react-router-dom

Let's also install bootstrap for styling our component:

npm install bootstrap

Implementing our component

We then create a Breadcrumbs.tsx component which will contain the markup for the breadcrumbs and also include the necessary logic to determine the current location relative to the root location.

Let's start by adding a simple markup for the component:

 <div className='text-primary'>
   <nav aria-label='breadcrumb'>
      <ol className='breadcrumb'>
        <li className='breadcrumb-item pointer'>
          <span className='bi bi-arrow-left-short me-1'></span>
            Back
        </li>
      </ol>
   </nav>
</div>

The component currently has just a back button. Let's add a simple implementation for the back button such that when clicked, the previous page should be loaded:

  const goBack = () => {
    window.history.back();
  };

The next step will be to write a function that will use the matchRoutes function from react-router to get the current route and apply transformations to filter out all related routes to the current route.
The matchRoute function accepts an array of objects of type AgnosticRouteObject and returns an AgnosticRouteMatch<string, T>[] | null where T is the type of object we pass in.
Also important to note is that the object must contain a property named path.

Let's first declare an interface for our route:

interface IRoute {
  name: string;
  path: string; //Important
}

Let's then declare our routes:

const routes: IRoute[] = [
  {
    path: '/home',
    name: 'Home'
  },
  {
    path: '/home/about',
    name: 'About'
  },
  {
    path: '/users',
    name: 'Users'
  },
  {
    path: '/users/:id',
    name: 'User'
  },
  {
    path: '/users/:id/settings/edit',
    name: 'Edit User Settings'
  }
];

We also declare a variable to hold the useLocation hook and also another to hold our breadcrumbs in state:

const location = useLocation();
const [crumbs, setCrumbs] = useState<IRoute[]>([]);

Next, let's implement our function:

const getPaths = () => {
  const allRoutes = matchRoutes(routes, location);
  const matchedRoute = allRoutes ? allRoutes[0] : null;
  let breadcrumbs: IRoute[] = [];
  if (matchedRoute) {
    breadcrumbs = routes
      .filter((x) => matchedRoute.route.path.includes(x.path))
      .map(({ path, ...rest }) => ({
        path: Object.keys(matchedRoute.params).length
          ? Object.keys(matchedRoute.params).reduce(
              (path, param) => path.replace(`:${param}`, matchedRoute.params[param] as string), path)
          : path,
        ...rest,
      }));
  }
  setCrumbs(breadcrumbs);
};

Here, we first get all routes that match the current location:
const allRoutes = matchRoutes(routes, location);

We then do a quick check to see if any result is returned at all and we take the first one:
const matchedRoute = allRoutes ? allRoutes[0] : null;

Next, we filter out all routes that match the current route:
routes.filter((x) => matchedRoute.route.path.includes(x.path))

Then let's use the result to create a new array that checks if the path has params and then swaps out dynamic routes with the params value:

 .map(({ path, ...rest }) => ({
          path: Object.keys(matchedRoute.params).length
            ? Object.keys(matchedRoute.params).reduce(
                (path, param) => path.replace(`:${param}`, matchedRoute.params[param] as string),
                path
              )
            : path,
          ...rest,
        }));

This ensures that if we declare a route as /users/:id/edit in the routes and the id is passed as 1, then we get /users/1/edit.

Next, let's call our function in a useEffect so that it runs every time our location changes:

  useEffect(() => {
    getPaths();
  }, [location]);

With this done, we can then use the crumbs in our markup:

{crumbs.map((x: IRoute, key: number) =>
  crumbs.length === key + 1 ? (
    <li className='breadcrumb-item'>{x.name}</li>
      ) : (
        <li className='breadcrumb-item'>
          <Link to={x.path} className=' text-decoration-none'>
            {x.name}
          </Link>
        </li>
      )
 )}

Here, display all the crumbs with their links except for the last one which only displays the name.

With that, we now have our full BreadCrumbs.tsx component:

import { useEffect, useState } from 'react';
import { Link, matchRoutes, useLocation } from 'react-router-dom';

interface IRoute {
  name: string;
  path: string;
}

const routes: IRoute[] = [
  {
    path: '/home',
    name: 'Home',
  },
  {
    path: '/home/about',
    name: 'About',
  },
  {
    path: '/users',
    name: 'Users',
  },
  {
    path: '/users/:id/edit',
    name: 'Edit Users by Id',
  },
];

const Breadcrumbs = () => {
  const location = useLocation();
  const [crumbs, setCrumbs] = useState<IRoute[]>([]);

  const getPaths = () => {
    const allRoutes = matchRoutes(routes, location);
    const matchedRoute = allRoutes ? allRoutes[0] : null;
    let breadcrumbs: IRoute[] = [];
    if (matchedRoute) {
      breadcrumbs = routes
        .filter((x) => matchedRoute.route.path.includes(x.path))
        .map(({ path, ...rest }) => ({
          path: Object.keys(matchedRoute.params).length
            ? Object.keys(matchedRoute.params).reduce(
                (path, param) => path.replace(`:${param}`, matchedRoute.params[param] as string),
                path
              )
            : path,
          ...rest,
        }));
    }
    setCrumbs(breadcrumbs);
  };

  useEffect(() => {
    getPaths();
  }, [location]);

  const goBack = () => {
    window.history.back();
  };

  return (
    <div className=''>
      <nav aria-label='breadcrumb'>
        <ol className='breadcrumb'>
          <li className='breadcrumb-item pointer' onClick={goBack}>
            <span className='bi bi-arrow-left-short me-1'></span>
            Back
          </li>
          {crumbs.map((x: IRoute, key: number) =>
            crumbs.length === key + 1 ? (
              <li className='breadcrumb-item'>{x.name}</li>
            ) : (
              <li className='breadcrumb-item'>
                <Link to={x.path} className=' text-decoration-none'>
                  {x.name}
                </Link>
              </li>
            )
          )}
        </ol>
      </nav>
    </div>
  );
};
export default Breadcrumbs;

We can then use the component in any part of our application, preferably in the layout.

Conclusion

We have seen how to implement a simple breadcrumbs component which we can add to our app to improve navigation and UX.

Useful links

https://stackoverflow.com/questions/66265608/react-router-v6-get-path-pattern-for-current-route

https://medium.com/@mattywilliams/generating-an-automatic-breadcrumb-in-react-router-fed01af1fc3 which this post takes inspiration from.