Forem: Denis Sirashev

Bringing locally running LLM into your NodeJS project

Denis Sirashev — Mon, 03 Nov 2025 18:36:05 +0000

Introduction

If you want to use AI in your project, it is easy to add the OpenAI ChatGPT library, which provides response and completion endpoints. However, you lack access or prefer not to pay for testing your application's functionality or experimenting with your ideas. In that case, you can download LLM to your local PC/laptop and run it through Docker. I will show you how easily you can implement all the required code.

Choosing model

First, go and check the Ollama website. It offers numerous LLM models you can download, fine-tune, and use with Ollama. Let's choose deepseek-r1, because I've used it in my project. I recommend running all your AI models on a GPU for faster and more effective results. Depending on your GPU memory size, you need to choose a proper model. For example, I have an RTX 4070 Ti with 12 GB, and deepseek-r1:14b is the best option for me because it has 9.0 GB size.

Docker containers

If you don't have Docker installed on your machine, visit https://www.docker.com/ and follow the installation guide for your system. Our next step is to bring up the Docker containers for Ollama, which will handle all requests to the AI model, and the Ollama WebUI to manage the models.

// docker-compose.yaml
version: '3'  

services:  
  ollama:  
    image: ollama/ollama:latest  
    pull_policy: always  
    restart: always  
    ports:  
      - '11434:11434'  
    volumes:  
      - ollama_data:/root/.ollama  
    environment:  
      - OLLAMA_KEEP_ALIVE=24h  
      - OLLAMA_HOST=0.0.0.0  
    deploy:  
      resources:  
        reservations:  
          devices:  
            - capabilities: ["gpu"]  
    networks:  
      - app-network  

  ollama-webui:  
    image: ghcr.io/open-webui/open-webui:main
    volumes:  
      - ollama_webui_data:/app/backend/data  
    depends_on:  
      - ollama  
    ports:  
      - 8088:8080  
    environment:  
      - OLLAMA_BASE_URLS=http://host.docker.internal:11434
      - ENV=dev  
      - WEBUI_AUTH=False  
      - WEBUI_NAME=Ollama AI  
      - WEBUI_URL=http://localhost:8088
      - WEBUI_SECRET_KEY=s3cr3t  
    extra_hosts:  
      - host.docker.internal:host-gateway  
    restart: unless-stopped   
    networks:  
      - app-network  

volumes:  
  ollama_data:  
  ollama_webui_data:  

networks:  
  app-network:

Notice the deploy syntax in the Docker Compose file:

deploy:  
  resources:  
    reservations:  
      devices:  
        - capabilities: ["gpu"]

It enables access to a machine GPU for the Docker container, precisely what we need.

Configuring Ollama

We need to configure the Ollama before using it. Right now, it doesn't have any AI model installed, and you can check it via the Web UI at http://localhost:8088 (you can use another port if you wish).

You will see a selector without any model to choose from for now. On this page, click the user's avatar, then select "Admin panel". Navigate to "Settings" and select "Connections" in the left nav menu.

Check the "Manage Ollama API Connections" section, which includes the "Manage" button. It will open a popup where you can download any model from Ollama.com. In the "Pull a model from" you can enter a model tag, for example, deepseek-r1:14b.

Click on the pull button, it will take some time to download all the required manifest and model files.

To confirm the model has successfully downloaded, check it in the "Delete a model" selector. Click on it and check the available models in

And now, if you'd like, you can chat with your GPT model in the Ollama Web UI. It will require some time to analyze and produce an answer to you, because you don't have enough (or have 😮) power.

Using your own hosted LLM model

It is time to check how it is working. To integrate into your own NodeJS project, you need to install the ollama package.

npm add ollama

To enable it and make a first request with your prompt, initialize a new ollama instance and send a chat request with proper params:

const ollama = new Ollama({
    host: 'http://localhost:11434', // type your host or IP address
});

const response = await ollama.chat({
    model: 'deepseek-r1:14b', // write your model
    messages: [
        {
            role: 'system',
            content: 'Your prompt for GPT model',
        },
        {
            role: 'user',
            content: 'User message'
        }
    ],
    format: 'json',
});

const data: YourData = JSON.parse(response.message.content);

YourData is a type for your concrete data. It will help you type the response generated by the GPT model.

Conclusions

And that's it. It's a locally running LLM model, but you can run it on another machine and connect to it. What did I do? I bought a static IP address from my local ISP, ran the LLM model and container on my Windows PC with an RTX card, and connected to it from my running server. It is suitable for a pet project but not for production, and it can still be a good starting point for testing your ideas and finding the best solution. Good luck to you!

Photo by Aerps.com on Unsplash

Quick tip 2 - Completely ignore node_modules for Docker in Monorepo

Denis Sirashev — Sun, 05 Oct 2025 14:52:52 +0000

The problem

While working on my NodeJS project, I encountered issues with large Docker images while building them from the source code. The problem was that Docker copied all files, including the node_modules folder, despite having a line in .dockerignore that excluded' node_modules'.

node_modules

The solution

Why didn't it work properly? It was a monorepo PNPM project, and ignoring the node_modules folder with a simple node_modules was not enough. The key was that the context of building images was rooted in the project's foundation. I didn't have node_modules in the project's root, but had it inside each application and package. To solve that, I've added another line in my .dockerignore file:

**/node_modules

So now, it doesn't copy any of the node_modules folders inside applications, packages, and services. Each image has its own node_modules folder during the installation process. Simple and clean.

Photo by Favour Usifo on Unsplash

Three levels of Breadth-First Search algorithm

Denis Sirashev — Sun, 26 Jan 2025 10:18:46 +0000

Introduction

Big tech companies such as Yandex, Google, Amazon, etc., develop an interview process to filter an enormous number of candidates. Therefore, they can't just give them a test task or ask theory questions about their subject. They add an algorithm section with different complex challenges depending on the section: frontend, backend, or machine learning. Yes, the front doesn't need to write quantum computations due to the lack of the client's machine performance, and usage of the computer algorithms is less critical. Still, it teaches us to use CPUs and Memory carefully and be able to write supereffective code.

Challenge

We have a graph with multiple connected points. The graph can be resolved synchronously and asynchronously. You need to answer two questions: Do you have a connection between randomly selected points, and can you build the shortest route to them?

const graph = {};

graph['A'] = ['B', 'C'];
graph['B'] = ['D', 'E'];
graph['C'] = ['D', 'F'];
graph['D'] = ['H', 'I'];
graph['E'] = ['G', 'H'];
graph['F'] = ['I'];
graph['G'] = ['J'];
graph['H'] = [];
graph['I'] = ['K'];
graph['J'] = ['K'];
graph['K'] = [];

// Sync graph resolver
const getGraph = (node) => graph[node];
// Async graph resolver
const getAsyncGraph = (node) => Promise.resolve(graph[node]);

// Paths to check: 
//  from -> to = do we have a connection? | the shortest route
//  A -> K = true | ["A", "C", "F", "I", "K"]
//  A -> H = true | ["A", "C", "D", "H"]
//  B -> A = false | false

Implementation

Typings

Let's start with a graph's code representation. We already have an initial code, but we need to add types before proceeding. I will add literals with all possible values for this challenge, but we can generally use strings for the graph's node value.

type GraphNode =
    | 'A'
    | 'B'
    | 'C'
    | 'D'
    | 'E'
    | 'F'
    | 'G'
    | 'H'
    | 'I'
    | 'J'
    | 'K';

type Graph = Record<GraphNode, GraphNode[]>;

I have an idea to split the Breadth-First Search (BFS) into two parts for education: a traveler and a condition checker. This would allow us to choose different "strategies" for BFS with one argument change.

What is a strategy? It should be a function with three arguments: the parent node from which we come, the current node, and our goal. The result should be an object with the success flag and the result itself.

type StrategyResult<R> =
    // If the strategy is unsuccessful, we don't need a result at all
    | { success: false }
    | {
        success: true;
        result: R;
    };

type Strategy<R> = (
    parentNode: GraphNode,
    currentNode: GraphNode,
    to: GraphNode
) => StrategyResult<R>;

Sync BFS

The BFS function works from a starting point to our destination and applies a strategy: a path exists or builds a route. In this case, it requires three arguments.

function syncBfs<R>(from: GraphNode, to: GraphNode, strategy: Strategy<R>) {
    // Build a traveler's queue
    const queue = [from];
    // We need a set of visited nodes to avoid duplicate runs
    const visited = new Set<GraphNode>();

    // Proceed until the queue is empty
    while (queue.length !== 0) {
        // Take the first element from the queue
        const node = queue.shift();
        // Check that we have a node
        if (!node) continue;
        // Move to the next element in the queue if it's already visited
        if (visited.has(node)) continue;

        // Mark as visited
        visited.add(node);

        // Resolve child nodes from the "data source"
        const childs = getGraph(node);

        for (let childNode of childs) {
            // Apply our strategy
            const r = strategy(node, childNode, to);
            // Return the result if the strategy finishes successfully
            if (r.success) return r.result;

            // Otherwise, push to the queue and proceed
            queue.push(childNode);
        }
    }

    // Return false on failure
    return false;
}

We can't run the code because we don't have a strategy yet. Let's begin with the easiest one - a "path exists" strategy.

Strategies

"Path exists" strategy

In this strategy, we only need to check if a current node is our goal.

// Add a strategy type with a boolean as a result
const pathExistsStrategy: Strategy<boolean> = (
    // We don't need a parent node in this strategy, so name it as an underscore
    _: GraphNode,
    currentNode: GraphNode,
    to: GraphNode
) => {
    // Main condition
    const exists = currentNode === to;

    if (!exists) {
        return { success: false };
    }

    return {
        success: exists,
        result: exists,
    };
};

Let's check that our code is working:

console.log(syncBfs('A', 'K', pathExistsStrategy));
console.log(syncBfs('A', 'H', pathExistsStrategy));
console.log(syncBfs('B', 'A', pathExistsStrategy));

// In the console, we will see:
//   true
//   true
//   false

Success! Works perfect.

"Shortest route" strategy

This is the most interesting strategy. To build a route, we need to check the current node and keep all visited and connected nodes. Each run of the BFS function should have a separate storage space. A builder function and closures will help us.

// We will call this function to build a strategy function for us. The result is an array of all nodes.
const createShortestRouteStrategy = (): Strategy<GraphNode[]> => {
    // Storage for all visited and connected nodes
    const nodeConnections: Record<GraphNode, GraphNode> = {} as Record<GraphNode, GraphNode>;

    // Strategy function itself
    return (parentNode: GraphNode, currentNode: GraphNode, to: GraphNode) => {
        // Save a connection between nodes
        nodeConnections[currentNode] = parentNode;

        // If it's not a destination, report about it
        if (currentNode !== to) {
            return { success: false };
        }

        // If it's a destination, build a route
        const route: GraphNode[] = [];
        let routeNode = currentNode;
        while (routeNode) {
            // Push all visited nodes into an array
            route.push(routeNode);

            routeNode = nodeConnections[routeNode] ?? undefined;
        }

        return {
            success: true,
            // Reverse the array because it has been built from the end
            result: route.reverse(),
        };
    };
};

Time to check how it works:

// Notice: we call a function because it returns a strategy function
console.log(syncBfs('A', 'K', createShortestRouteStrategy()));
console.log(syncBfs('A', 'H', createShortestRouteStrategy()));
console.log(syncBfs('B', 'A', createShortestRouteStrategy()));

// Console output:
//   (5) ["A", "C", "F", "I", "K"]
//   (4) ["A", "C", "D", "H"]
//   false

Async BFS with async/await

No significant difference exists between sync and async code with async/await. You define an async function and await a response from an async "data source".

// Async function
async function asyncBfs<R>(
    from: GraphNode,
    to: GraphNode,
    strategy: Strategy<R>
) {
    const queue = [from];
    const visited = new Set<GraphNode>();

    while (queue.length !== 0) {
        const node = queue.shift();

        if (!node) continue;
        if (visited.has(node)) continue;

        // Mark as visited
        visited.add(node);

        // Await a response from the resolver
        const childs = await getAsyncGraph(node);

        for (let childNode of childs) {
            const r = strategy(node, childNode, to);

            if (r.success) return r.result;

            queue.push(childNode);
        }
    }

    return false;
}

Code to check that it works fine:

asyncBfs('A', 'K', createShortestRouteStrategy()).then(r => console.log(r));
asyncBfs('A', 'H', createShortestRouteStrategy()).then(r => console.log(r));
asyncBfs('B', 'A', createShortestRouteStrategy()).then(r => console.log(r));

// Console output
//   (4) ["A", "C", "D", "H"]
//   (5) ["A", "C", "F", "I", "K"]
//   false

Notice that the console output sequence is different from the sync function. A search is being executed in the microtasks queue now, and it depends on the network latency (we don't have it here) and the distance between nodes. It requires one additional tick to handle the route calculation for A->K.

Async BFS with promises

A promise-based BFS function requires a revision of working with the node queue and awaiting execution completion. How do we know that all promises are fulfilled? We can use a counter to keep a total number of queued promises. Another problem is the traveler loop - it works synchronously. It will finish execution after the first node. It will require us to use a "runner" function that re-runs the traveler loop the first time and after every promise is resolved.

function promisedBfs<R>(from: GraphNode, to: GraphNode, strategy: Strategy<R>) {
    // We need to return a promise first
    return new Promise((resolve, reject) => {
        // Queued promises counter
        let queuedPromises = 0;
        const queue = [from];
        const visited = new Set<GraphNode>();

        // Runner
        const run = () => {
            // All promises are resolved, the queue is empty; finish our function with an empty result
            if (queue.length === 0 && queuedPromises === 0) {
                resolve(false);
                return;
            }

            while (queue.length !== 0) {
                const node = queue.shift();

                if (!node) continue;
                if (visited.has(node)) {
                    // Re-run to check that nothing is left
                    run();
                    continue;
                }

                visited.add(node);
                // Increment the counter
                // For each node, there will be a promise to resolve the graph
                queuedPromises += 1;

                getAsyncGraph(node).then(childs => {
                    // Decrement the counter because the promise has been resolved
                    queuedPromises -= 1;

                    for (let childNode of childs) {
                        const r = strategy(node, childNode, to);

                        if (r.success) {
                            resolve(r.result);
                            return;
                        }

                        queue.push(childNode);
                    }

                    // Re-run the loop
                    run();
                });
            }
        };

        // Run the loop the first time
        run();
    });
}

Check the promise-based BFS function with test cases:

promisedBfs('A', 'K', createShortestRouteStrategy()).then(r => console.log(r));
promisedBfs('A', 'H', createShortestRouteStrategy()).then(r => console.log(r));
promisedBfs('B', 'A', createShortestRouteStrategy()).then(r => console.log(r));

// Console output:
//   (4) ["A", "C", "D", "H"]
//   (5) ["A", "C", "F", "I", "K"]
//   false

It works the same as an async BFS function with async/await. Nice!

Conclusion

As you can see, you can solve the challenge in multiple ways. Each solution provides bonus points and shows how deeply you can understand the algorithm and the language. Check the complete source code at https://github.com/6akcuk/BFS. Feel free to ask questions or comments. Thank you!

Photo by AltumCode on Unsplash

Build and run your project in Monorepo with PNPM

Denis Sirashev — Sun, 19 Jan 2025 07:40:04 +0000

Introduction

You have two variants of code organization for your projects:

Keep the project's code in different repositories like a polyrepo;
Keep everything in one single monorepo.

They are all good, and it is up to you which one is the best fit for your projects. A polyrepo is the current standard way of developing applications. You have multiple teams, each with its repo with build artifacts and pipelines. They have autonomy. It is their own decision about libraries to use, how to deploy, and who can contribute.

The opposite way is to have a monorepo. You split your projects into applications and packages, and you can easily re-use a code and share standard functionality. It helps you unify third-party package versions, recursively build dependencies' source code, and use the same tooling for CI/CD pipelines.

Many big tech companies use monorepo for their projects. For example, Yandex has everything in one big monorepo, splitting into small monorepos for business projects. It helps to share ideas and interesting code practices between teams and business units.

You can find more information about monorepos and tooling at https://monorepo.tools/. Here, we will focus on a simple solution with PNPM, which provides us with basic functionality to create and use monorepo in our projects.

Pnpm uses workspaces to unite multiple projects inside a single repository.

Setup

First, we need an empty folder for our new monorepo project. Inside the repo, let's initialize pnpm.

pnpm init

To enable the workspaces, create a pnpm-workspace.yaml file with a description of package folders:

// pnpm-workspace.yaml

packages:
  - 'packages/**'
  - 'apps/**'

We add shared libraries that every application could use inside the /packages folder. The /apps folder contains applications, such as separate mobile React Native applications and web applications that use the same components or connection libraries to communicate with an API server.

If you haven't seen my articles about creating a Telegram publish bot, please look at them. We will use its source code from GitHub: https://github.com/6akcuk/PublishBot. Download and unpack the ZIP file to the /apps/publish-bot folder.

Run the installation command inside the /apps/publish-bot folder:

pnpm install

We prepared the repository for this article. What's the plan? We will modify the code inside the publication bot's preview command. Right now, we cannot correctly preview the draft messages left by users. For future projects, it would also be nice to move the preview functionality into a separate package that other applications could use inside them.

Telegram package

Let's create our first package inside a monorepo. We have the /packages folder and create a folder called telegram-utils inside it.

For the telegram utils, we need to initialize pnpm and typescript:

pnpm init && pnpm add -D typescript && pnpm tsc --init

The package will provide only one function combining texts and captions from all messages - text, video, and photo. To format messages, we need to install a Telegraf package.

pnpm add telegraf

All source code should be located inside the /src directory. As it is a shared library/package, it is good to have different folders grouped by their features. The function will combine texts, so it works with text and should be inside a /texts folder. Here is the full source code for the combineTexts function:

// packages/telegram-utils/src/texts/combineTexts.ts

import { Message } from 'telegraf/types';
import { FmtString, join } from 'telegraf/format';

type GroupedMessages = {
    photos: Array<Message.PhotoMessage>;
    videos: Array<Message.VideoMessage>;
    text: Array<Message.TextMessage>;
};

export const combineTexts = ({ photos, videos, text }: GroupedMessages) => {
    // Get all captions from messages with photo
    const photoTexts = photos
        .map(photo =>
            photo.caption
                ? new FmtString(photo.caption, photo.caption_entities)
                : undefined
        )
        // Guard for array filtering function 
        .filter((t): t is Required<FmtString> => t !== undefined);

    // Get all captions from messages with video
    const videoTexts = videos
        .map(video =>
            video.caption
                ? new FmtString(video.caption, video.caption_entities)
                : undefined
        )
        .filter((t): t is Required<FmtString> => t !== undefined);

    const allTexts = [];

    // Combine text from text messages
    if (text.length) {
        allTexts.push(join(text.map(t => new FmtString(t.text, t.entities))), '\n');
    }
    if (photoTexts.length) allTexts.push(join(photoTexts, '\n'));
    if (videoTexts.length) allTexts.push(join(videoTexts, '\n'));

    // Final combination
    return join(allTexts, '\n');
};

Notes about the function's code:

The input of the function is grouped messages by their type: photo, video, or text;
Media messages should be transformed into an FMT string with caption and caption entities. We should return undefined for later filtering;
We join arrays of texts step-by-step and finally combine all of them into one big message.

It is good to create an index file for the texts feature:

// packages/telegram-utils/src/texts/index.ts

export * from './combineTexts';

Now, we need to set up exporting of the package's functionality. In the package.json file, we can use the exports field.

// packages/telegram-utils/package.json

"exports": {
    "./texts": {
        "import": "./src/texts/index.ts",
        "require": "./dist/texts/index.js"
    }
}

We don't want to provide an /src part when importing the package, so we declared it a custom import with ./texts. Inside the ./texts field, we declare that only the index file can import all required functionality. The import declares that we use a typescript file for ESModule, and the require declares that we use a compiled file for CommonJS.

To identify a monorepo package inside our applications, let's add a prefix for all of them - @monorepo. Rename the telegram utils package in the package.json file:

// packages/telegram-utils/package.json

"name": "@monorepo/telegram-utils"

We need a build script to compile our package for use. Update the scripts section in the package.json:

// packages/telegram-utils/package.json

"scripts": {
    "build": "tsc -p tsconfig.json"
}

Check the full version of the package.json for the @monorepo/telegram-utils:

// packages/telegram-utils/package.json

{
    "name": "@monorepo/telegram-utils",
    "version": "1.0.0",
    "main": "index.js",
    "scripts": {
        "build": "tsc -p tsconfig.json"
    },
    "keywords": [],
    "license": "ISC",
    "exports": {
        "./texts": {
            "import": "./src/texts/index.ts",
            "require": "./dist/texts/index.js"
        }
    },
    "devDependencies": {
        "typescript": "^5.7.3"
    },
    "dependencies": {
        "telegraf": "^4.16.3"
    }
}

Configure a TypeScript compiler: We enable incremental compilation to save some build time and work only on the changed parts of the package. We also enable a composite compilation to use the project with project references. Define a /src folder as a rootDir and an outDir of the package as/dist. Check the updated version of the tsconfig.json:

// packages/telegram-utils/tsconfig.json

{
    "compilerOptions": {
        // Incremental compilation enabled
        "incremental": true,
        // Composite enabled
        "composite": true,

        "target": "es2016",

        "module": "commonjs",
        // Source code location
        "rootDir": "./src",
        // Destination folder for a compiled code
        "outDir": "./dist",

        "esModuleInterop": true,
        "forceConsistentCasingInFileNames": true,

        "strict": true,
        "skipLibCheck": true
    }
}

Put it all together

Return to apps/publish-bot. Add our new @monorepo/telegram-utils package to the packages' dependencies. Note that we don't need to specify a package version; instead, we use a workspace notation.

// apps/publish-bot/package.json

"dependencies": {
    "@monorepo/telegram-utils": "workspace:*"
}

After that, install the dependencies inside the app:

pnpm install

Update the preview command of the publication bot. Only two lines require a change - we need an import of our function from the package and a function call:

// apps/publish-bot/src/commands/preview.ts

import type { InputMediaPhoto, InputMediaVideo } from 'telegraf/types';
// Instead of using Telegraf's formatting utils, import our package
import { combineTexts } from '@monorepo/telegram-utils/texts';

import { groupMessages, getInlineKeyboard } from '../helpers';
import type { Context } from '../types';

const preview = async (ctx: Context) => {
    if (ctx.session.messages.length > 0) {
        const { photos, videos, text } = groupMessages(ctx.session.messages);

        // Call a combineTexts function to get a thoroughly combined text message
        const fullText = combineTexts({ photos, videos, text });

        if (photos.length || videos.length) {
            const media = [
                ...videos.map<InputMediaVideo>(video => ({
                    type: 'video',
                    media: video.video.file_id,
                    ...video,
                })),
                ...photos.map<InputMediaPhoto>(photo => ({
                    type: 'photo',
                    media: photo.photo[photo.photo.length - 1].file_id,
                    ...photo,
                })),
            ];

            if (fullText.text) {
                media[media.length - 1].caption = fullText.text;
                media[media.length - 1].caption_entities = fullText.entities;
            }

            return ctx.replyWithMediaGroup(media);
        }

        return ctx.reply(fullText, getInlineKeyboard(ctx, { hidePreview: true }));
    }

    return ctx.reply('No messages to preview.');
};

export default preview;

You will receive a TS error message stating that @monorepo/telegram-utils/texts cannot be found. This is because TypeScript does not support custom exports from package.json by default. To fix it, update the application's tsconfig.json file, add a moduleResolution, set it to nodenext, and change a module to NodeNext.

// apps/publish-bot/tsconfig.json

{
    "compilerOptions": {
        "target": "es2016",
        "module": "NodeNext",
        "moduleResolution": "nodenext",
        "outDir": "./dist",
        "esModuleInterop": true,
        "forceConsistentCasingInFileNames": true,

        "strict": true,
        "skipLibCheck": true
    }
}

To build a source code for the application, we first need to build all our dependencies - @monorepo/telegram-utils. You can run manually a build command for each of the packages, or PNPM has an option flag -r that runs a command recursively:

pnpm -r build

Conclusion

That's it. Your publication bot uses an internal shared library/package and sits inside a monorepo. It allows us to build new functionality and reuse code for multiple applications quickly.

A publication bot is a small part of the significant service that could be created. It communicates with users via the Telegram interface and accumulates all messages. However, we don't have a backend yet to save incoming messages, moderate them, and notify subscribers. Stay tuned!

Photo by Gabriel Heinzer on Unsplash

Your own Telegram bot on NodeJS with TypeScript, Telegraf and Fastify (Part 3)

Denis Sirashev — Fri, 10 Jan 2025 21:32:38 +0000

The final chapter of the series covers an advanced example of a Telegram bot using Fastify as a server to listen to incoming requests. It also provides additional plugins and middleware capability. Please check the previous parts before proceeding if you haven't seen them.

Fastify

Express is the gold standard for a web framework in NodeJS. It has extensive online documentation and examples and a large community of developers. But why Fastify?

I chose it because it is lightweight, highly performant, and TypeScript-ready. It allows for writing async middleware, but Express v5 now supports promises, so this is no longer a massive benefit of Fastify. As I said, there are many examples and articles for Express but fewer for Fastify, so I added more information about using Fastify to create a Telegram bot.

Let's start by installing Fastify and additional plugins:

pnpm add fastify fastify-plugin pino-pretty @fastify/env @fastify/redis

We need to update the application's structure. The best practice for extending the Fastify application is using plugins, which should be used for each independent part. For these needs, create a new directory inside /src called parts

mkdir parts

Configuration

We directly added a bot token to our code, which is a mistake, mainly if you use a version control system (VCS) like Git. Instead, move it to a configuration file and connect it to our application.

In NodeJS applications, you can pass data through environment variables like process.env.BOT_TOKEN. To do that, we can export a value to an environment variable:

export BOT_TOKEN=<BOT_TOKEN> pnpm dev

It's okay to debug, test, or run an application in development mode to test your idea, but it's not practical. It is better to keep it in a configuration file and automatically pass it to your application when running.

We can create an environment configuration file .env. To use it in your application, you need a dotenv package. We use Fastify, and @fastify/env plugin is what we need. In VCS (like Git), the .env file is ignored, and all your sensitive information is safe. Add a .env.example file with examples of variables and default values with non-sensitive data to notice available configuration variables in your application. Do not forget to add the .env file with a bot token.

// .env.example

PORT=3000
BOT_TOKEN=
REDIS_URL=127.0.0.1:6379

After the configuration file, we can add a configuration part of the application.

// src/parts/config.ts

import fastifyEnv from '@fastify/env';
import type { FastifyInstance } from 'fastify';

const schema = {
    type: 'object',
    required: ['BOT_TOKEN', 'REDIS_URL'],
    properties: {
        PORT: {
            type: 'number',
            default: 3000,
        },
        BOT_TOKEN: {
            type: 'string',
            default: '',
        },
        REDIS_URL: {
            type: 'string',
            default: '127.0.0.1:6379',
        },
    },
};

const options = {
    schema,
    dotenv: true,
};

type BuildSchema<
    T extends {
        properties: { [key: string]: { type: string; default: unknown } };
    }
> = {
    [K in keyof T['properties']]: T['properties'][K]['default'];
};

export type Schema = BuildSchema<typeof schema>;

async function init(fastify: FastifyInstance) {
    fastify.log.debug('Registering config..');

    await fastify.register(fastifyEnv, options);

    fastify.log.debug(fastify.config, 'Registered with config');

    return fastify;
}

declare module 'fastify' {
    interface FastifyInstance {
        config: Schema;
        getEnvs(): Schema;
    }
}

export default init;

Notes about the code above:

We define a schema of our configuration to tell the plugin about the required variables and their type and default values;
We define options for the @fastify/env plugin with schema and the dotenv property to notice that we use environment files for our configuration;
The BuildSchema utility type creates a schema type from the schema object. It uses a default value to assign a type for a value;
Our init function takes a fastify instance as an argument, registers a new plugin with predefined options, and returns the fastify instance;
We extend the fastify module with a getEnvs method and a config property. Both return our schema so we can use it everywhere in our application with the proper typings.

Redis

We use a key-value store for our session and the bot's memory. It is another part of the application that keeps all user data in computer memory so that the bot's restarts don't erase the saved drafts.

// src/parts/redis.ts

import { type FastifyInstance } from 'fastify';
import redis from '@fastify/redis';

async function init(fastify: FastifyInstance) {
    const { REDIS_URL } = fastify.config;

    fastify.log.debug('Registering redis..');

    await fastify.register(redis, {
        url: REDIS_URL,
    });

    fastify.log.debug(`Redis connected to ${REDIS_URL}`);

    return fastify;
}

export default init;

The configuration provides a Redis URL, which we use to register the @fastify/redis plugin with the data. Logs help us debug the part's running steps.

Telegraf bot

Yes, the Telegraf bot is also another part of the application. We need to create a fastify plugin from the code written before.

// src/parts/bot.ts

import type { FastifyInstance } from 'fastify';
import fp from 'fastify-plugin';
import { session, Telegraf, type SessionStore } from 'telegraf';
import { message } from 'telegraf/filters';

import type { Context, Session } from '../types';
import { cancel, hi, publish, preview } from '../commands';
import { getDefaultSession } from '../helpers';

async function init(fastify: FastifyInstance) {
    const { BOT_TOKEN } = fastify.config;

    const store: SessionStore<Session> = {
        async get(key) {
            const value = await fastify.redis.get(key);

            return value ? JSON.parse(value) : null;
        },

        async set(key, value) {
            await fastify.redis.set(key, JSON.stringify(value));
        },

        async delete(key) {
            await fastify.redis.del(key);
        },
    };

    await fastify.register(
        fp<{ token: string; store: typeof store }>(
            async (fastify, opts) => {
                fastify.log.debug('Registering bot..');

                const hiRegExp = /^(hi|hello)$/i;
                const previewRegExp = /^(preview|status)$/i;
                const publishRegExp = /^(publish|send)$/i;
                const cancelRegExp = /^(cancel|clear|delete)$/i;

                const bot = new Telegraf<Context>(opts.token);

                bot.use(
                    session({
                        defaultSession: getDefaultSession,
                        store,
                    })
                );

                bot.start(hi);

                bot.hears(hiRegExp, hi);
                bot.command(hiRegExp, hi);
                bot.action(hiRegExp, hi);

                bot.hears(previewRegExp, preview);
                bot.command(previewRegExp, preview);
                bot.action(previewRegExp, async ctx => {
                    await ctx.answerCbQuery();
                    await preview(ctx);
                });

                bot.hears(cancelRegExp, cancel);
                bot.command(cancelRegExp, cancel);
                bot.action(cancelRegExp, async ctx => {
                    await ctx.answerCbQuery();
                    await cancel(ctx);
                });

                bot.hears(publishRegExp, publish);
                bot.command(publishRegExp, publish);
                bot.action(publishRegExp, async ctx => {
                    await ctx.answerCbQuery();
                    await publish(ctx);
                });

                bot.on(message('text'), async ctx => {
                    ctx.session.messages.push({ text: ctx.message });
                });

                bot.on(message('photo'), async ctx => {
                    ctx.session.messages.push({ photo: ctx.message });
                });

                bot.on(message('video'), async ctx => {
                    ctx.session.messages.push({ video: ctx.message });
                });

                bot.launch(() => console.log('Bot is running..'));

                fastify.decorate('bot', bot);
            },
            {
                name: 'publish-bot',
            }
        ),
        {
            token: BOT_TOKEN,
            store,
        }
    );

    return fastify;
}

declare module 'fastify' {
    interface FastifyInstance {
        bot: Telegraf<Context>;
    }
}

export default init;

It is almost the same bot, but there are a few differences. First, we change the store and switch to Redis instead of our map variable. The store has the same interface but is asynchronous and works with the @fastify/redis plugin.

// src/parts/bot.ts

const store: SessionStore<Session> = {
    async get(key) {
        const value = await fastify.redis.get(key);

        return value ? JSON.parse(value) : null;
    },

    async set(key, value) {
        await fastify.redis.set(key, JSON.stringify(value));
    },

    async delete(key) {
        await fastify.redis.del(key);
    },
};

The fp function defines a Fastify plugin. For our bot, we need two options - it's a token and the store we've created before. The function takes two arguments - a plugin handler and options. For consistency with other plugins, we decorate the fastify instance and add a new property bot with our bot instance. At the end of the file, we extend the fastify module with the property for proper typings.

Application

Let's combine all the new parts and run the Fastify application. First, we need an index file for the parts.

// src/parts/index.ts

export { default as bot } from './bot';
export { default as config } from './config';
export { default as redis } from './redis';

Then, we need a helper function to combine parts. As we have a dependency between our parts - we need a configuration for Redis, and the bot requires configuration and Redis itself; let's initialize them in an asynchronous pipeline each after.

// src/helpers/asyncPipe.ts

export const asyncPipe =
    <T>(...fns: Array<(arg: T) => Promise<T>>) =>
    async (arg: T) => {
        for (const fn of fns) {
            arg = await fn(arg);
        }
    };

It receives multiple functions as arguments and executes them in a returnable anonymous function with the passed argument. It mutates the argument on each iteration. Update a helpers index file:

// src/helpers/index.ts

export * from './asyncPipe';

It is time to update the main file. We want to initialize, configure, and run Fastify.

// src/index.ts

import Fastify from 'fastify';

import { asyncPipe } from './helpers';
import { bot, config, redis } from './parts';

const fastify = Fastify({
    logger: {
        level: 'debug',
        transport: {
            target: 'pino-pretty',
            options: {
                colorize: true,
            },
        },
    },
});

const start = async () => {
    try {
        await asyncPipe(config, redis, bot)(fastify);
        const { PORT } = fastify.config;

        await fastify.listen({ port: PORT });

        // Enable graceful stop
        process.once('SIGINT', () => {
            fastify.close();
            fastify.bot.stop('SIGINT');
        });

        process.once('SIGTERM', () => {
            fastify.close();
            fastify.bot.stop('SIGTERM');
        });
    } catch (err) {
        fastify.log.error(err);
        process.exit(1);
    }
};

start();

As you can see, the main file has been completely changed. Let's take a look:

We initialize the Fastify with a configuration for a logger. It uses pino under the hood, so it has some interesting options - colorize the logs output and decrease the level of messages to debug;
asyncPipe helps to register all the parts of our application in the correct order;
We register process listeners to shut down the application and the bot gracefully.

Docker and Docker Compose

One last thing: We can't run the application. We need Redis on our computer. If you already have it, just run it on port 6379. Otherwise, let's use Docker. Please download it from here.

Create a docker-compose.yaml file in the root of the bot's directory. This file contains the configuration for all the application's services. To check the session, we need only Redis and Redis UI.

// docker-compose.yaml

version: '3.8'

services:
    redis:
        image: redis:latest
        ports:
            - '6379:6379'
        networks:
            - app-network

    redis-ui:
        image: rediscommander/redis-commander:latest
        environment:
            - REDIS_HOSTS=local:redis:6379
        ports:
            - '8081:8081'
        depends_on:
            - redis
        networks:
            - app-network

networks:
    app-network:

Now, run the command to run all required services in the application's root directory:

docker-compose up -d

After creating the containers, the bot is ready to run. Check that everything works fine. Send a simple message, preview a draft, and visit http://localhost:8081 to check all sessions of the bot. It is a Redis UI that allows users to view Redis's current state. Here is an example of the saved draft

Conclusion

In this series, I've covered the popular topic of Telegram's bot. I started with the basics and increased the complexity of the code in each article. Of course, there are many things that I haven't covered, but I hope it helped you understand developing bots and will be a good starting point for future applications. See you soon!

The source code is available on my GitHub - https://github.com/6akcuk/PublishBot

Photo by Rubaitul Azad on Unsplash

Your own Telegram bot on NodeJS with TypeScript, Telegraf and Fastify (Part 2)

Denis Sirashev — Sun, 05 Jan 2025 21:29:15 +0000

In my previous article, we configured the project and wrote a simple, workable bot. We want to teach it to react to users' messages and have a memory to interact with the drafts.

Types

It is time to define some entities representing our bot application. Put it under the source directory and put it into the types.ts file.

// src/types.ts

import { Context as TelegrafContext } from 'telegraf';
import type { Message as TGMessage } from 'telegraf/types';

export type Message = {
    text?: TGMessage.TextMessage;
    photo?: TGMessage.PhotoMessage;
    video?: TGMessage.VideoMessage;
};

export type Session = {
    messages: Message[];
    mediaGroupIds: string[];
};

export type Context = TelegrafContext & {
    session: Session;
};

We have the Message entity that represents each message from a user before publication. It could be a text message, some photos or videos.

The Session entity represents a bot's memory for each chat room, which will help us accumulate drafts of incoming messages for future publication.

Context entity extends general Telegraf context and adds a session object.

Memory - Telegraf session

The Telegraf package provides a session to keep information between messages in the user's chat. We will use it to add memory for our bot and keep messages with photos and videos until they are published.

Let's create a session store that interfaces with the bot's memory. For now, it will be a simple object collection with chat ID as a key, which we will put into our main file, src/index.ts.

First, update the import of the telegraf package with the new session middleware function and SessionStore type.

// src/index.ts

import { session, Telegraf, type SessionStore } from 'telegraf';

Then, create a storage map that will keep messages and a store object that implements the SessionStore type with our previously defined Session as a generic parameter:

// src/index.ts

import { Session } from './types';

const storage = new Map<string, string>();

const store: SessionStore<Session> = {
    get(key) {
        const value = storage.get(key);

        return value ? JSON.parse(value) : null;
    },

    set(key, value) {
        storage.set(key, JSON.stringify(value));
    },

    delete(key) {
        storage.delete(key);
    },
};

It is a synchronous store with three methods: get, set, and delete. You can use everything you need, but we will keep it in the computer's memory for this part.

For the last part, we need a helper function to create our default state of the session - when we initialize our bot and when we need to fresh the data. Create a new directory inside the source folder called helpers and add the getDefaultSession.ts file:

// src/helpers/getDefaultSession.ts

import type { Session } from '../types';

export const getDefaultSession = (): Session => {
    return {
        mediaGroupIds: [],
        messages: [],
    };
};

We will add more helper functions in the future, so it would be a good practice to add an index.ts file and re-export everything you need from the helpers directory:

// src/helpers/index.ts

export * from './getDefaultSession';

Return to src/index.ts and import the getDefaultSession function.

// src/index.ts

import { getDefaultSession } from './helpers';

Use the newly created store with the session middleware. Each middleware could be added with a use method in the Telegraf instance. Add it after instantiating the bot.

// src/index.ts

const bot = new Telegraf('<BOT_TOKEN>');

bot.use(
    session({
        defaultSession: getDefaultSession,
        store,
    })
);

Commands

Let's define commands for our bot. Each command represents a single functionality of the bot and is located in a separate directory - /commands. They are asynchronous functions with the context as an argument. Create a folder first:

mkdir commands

Cancel command

The cancel command deletes a draft of a user's future message or post, allowing them to clear the current session.

// src/commands/cancel.ts

import { getDefaultSession } from '../helpers';
import type { Context } from '../types';

const cancel = async (ctx: Context) => {
    await ctx.reply('Draft has been deleted. You can start over.');

    ctx.session = getDefaultSession();
};

export default cancel;

We use the getDefaultSession function to set the current session to an empty state. We also need to reply to the user with a success message.

Hi command

We already have a command for incoming users as a welcome message, but let's move it into a separate file for consistency.

// src/commands/hi.ts

import { fmt } from 'telegraf/format';

import { Context } from '../types';

const hi = async (ctx: Context) => {
    await ctx.reply(fmt`
        Hello! Welcome to Publish Bot. I can help you publish your content to multiple channels at once.

    1. Write a message or send a photo/video.
    2. Check the preview of the message.
    3. If everything looks good, publish it to the channels.
`);
};

export default hi;

It looks better and has detailed instructions on using the bot to publish messages. One of the best practices for formatting messages is to use an fmt formatting function. The function has many helpers, but for now, we only need to write a multiline message.

Preview command

A preview command allows users to check their messages before publication. Unlike web or mobile applications, this functionality is essential because it cannot be seen in real-time.

Let's start with another helper function called groupMessages. This function combines all photos, videos, and text messages into separate groups to help us prepare a preview message on Telegram.

// src/helpers/groupMessages.ts

import type { Message as TGMessage } from 'telegraf/types';

import type { Message } from '../types';

export const groupMessages = (messages: Message[]) => {
    const photos: TGMessage.PhotoMessage[] = [];
    const videos: TGMessage.VideoMessage[] = [];
    const text: TGMessage.TextMessage[] = [];

    for (const message of messages) {
        if (message.photo) {
            photos.push(message.photo);
        }

        if (message.video) {
            videos.push(message.video);
        }

        if (message.text) {
            text.push(message.text);
        }
    }

    return {
        photos,
        videos,
        text,
    };
};

The next helper function is a canPublish. We don't need to allow users to publish short or empty messages. Let's say that we need at least 10 characters for publication.

// src/helpers/canPublish.ts

import type { Context } from '../types';

const MINIMUM_TEXT_LENGTH = 10;

export const canPublish = (ctx: Context) => {
    const { messages } = ctx.session;

    const hasMedia = messages.some(message => message.photo || message.video);
    const hasText = messages.some(message => message.text?.text.length ?? 0 > MINIMUM_TEXT_LENGTH);

    return hasMedia || hasText;
};

It is always good to have a constant for conditions or configuration values; we can move them to a separate config file or easily update them in the future.

Before going to the command itself, we need the last helper function. Telegram allows us to pass inline buttons for each message so that users can interact with your application.

// src/helpers/getInlineKeyboard.ts

import { Markup } from 'telegraf';

import { canPublish } from './canPublish';
import type { Context } from '../types';

type Options = {
    hidePreview?: boolean;
};

const PreviewButton = Markup.button.callback('Preview', 'preview');
const PublishButton = Markup.button.callback('Publish', 'publish');
const CancelButton = Markup.button.callback('Cancel', 'cancel');

export const getInlineKeyboard = (ctx: Context, options: Options = {}) => {
    const canPublishNow = canPublish(ctx);
    const { hidePreview } = options;

    if (hidePreview) {
        return Markup.inlineKeyboard([
            canPublishNow ? [PublishButton] : [],
            [CancelButton],
        ]);
    }

    return Markup.inlineKeyboard([
        [PreviewButton, CancelButton],
        canPublishNow ? [PublishButton] : [],
    ]);
};

We predefine buttons as callback buttons and assign them to individual variables for reusing. The first argument is the title of a button, and the second argument is the name of a callback, which will be defined below. The function has one option to hide the preview button if we don't need it in some scenarios.

Don't forget to update the index file in the helpers folder:

// src/helpers/index.ts

export * from './getDefaultSession';
export * from './getInlineKeyboard';
export * from './groupMessages';

We have everything that we need to implement the preview command.

// src/commands/preview.ts

import type { InputMediaPhoto, InputMediaVideo } from 'telegraf/types';
import { FmtString, join } from 'telegraf/format';

import { groupMessages, getInlineKeyboard } from '../helpers';
import type { Context } from '../types';

const preview = async (ctx: Context) => {
    if (ctx.session.messages.length > 0) {
        const { photos, videos, text } = groupMessages(ctx.session.messages);

        const fullText = join(
            text.map(t => new FmtString(t.text, t.entities)),
            '\n'
        );

        if (photos.length || videos.length) {
            const media = [
                ...videos.map<InputMediaVideo>(video => ({
                    type: 'video',
                    media: video.video.file_id,
                    ...video,
                })),
                ...photos.map<InputMediaPhoto>(photo => ({
                    type: 'photo',
                    media: photo.photo[photo.photo.length - 1].file_id,
                    ...photo,
                })),
            ];

            if (fullText.text) {
                media[media.length - 1].caption = fullText.text;
                media[media.length - 1].caption_entities = fullText.entities;
            }

            return ctx.replyWithMediaGroup(media);
        }

        return ctx.reply(fullText, getInlineKeyboard(ctx, { hidePreview: true }));
    }

    return ctx.reply('No messages to preview.');
};

export default preview;

Let's review the code:

If we don't have any messages in the session, report to the user that there are no messages to preview;
We group all messages by type to split the code lately for replying with attachments or with a text message;
Import FmtString class and join function to combine all text messages and captions into a single message while keeping all formattings;
If we have photos or videos, we need to reply with the media group and build an array of media. If there are text messages, add them to the media group caption with entities (describe string formatting);
Reply with the combined text messages and add an inline keyboard for further actions. Consider that there is a hidePreview option because we already looked at the draft's preview. ### Publish command

The central command of our bot. For now, we don't add any functionality to manipulate the draft; it's up to you what you want to do with it. In the next part, we'll see one of the variants.

// src/commands/publish.ts

import { getDefaultSession, groupMessages } from '../helpers';
import type { Context } from '../types';

const publish = async (ctx: Context) => {
    if (ctx.session.messages.length > 0) {
        const { photos, videos, text } = groupMessages(ctx.session.messages);

        const draft = {
            author: ctx.from,
            photos,
            videos,
            text,
        };

        try {
            // Do something with the draft
            draft;
        } catch (e) {
            console.error(e);
            return ctx.reply('There was an error while trying to publish your messages.');
        }

        ctx.session = getDefaultSession();

        return ctx.reply('Your messages has been published.');
    }

    return ctx.reply('No messages to publish.');
};

export default publish;

Inside the command, we prepare our draft object, which contains messages and information about an author from the context. In the try-catch section, we need to do something with our prepared draft - save it to a database or send it to a messages queue. Whatever you want to do with it. And, of course, don't forget to clear the session data by calling the getDefaultSession function and applying it to the session object.

Final touches

Create an index file for the commands to import them from one place.

// src/commands/index.ts

export { default as cancel } from './cancel';
export { default as hi } from './hi';
export { default as preview } from './preview';
export { default as publish } from './publish';

Each command could have multiple variations of text or callbacks that users could send to the bot. I recommend using regular expressions to handle all of them. Also, you need to import a message filter from Telegraf's filters to handle incoming messages by their type.

// src/index.ts

import { message } from 'telegraf/filters';

It is time to modify the application's main file to apply all the functionality written before.

// src/index.ts

const hiRegExp = /^(hi|hello)$/i;
const previewRegExp = /^(preview|status)$/i;
const publishRegExp = /^(publish|send)$/i;
const cancelRegExp = /^(cancel|clear|delete)$/i;

const bot = new Telegraf<Context>('<BOT_TOKEN>');

bot.use(
    session({
        defaultSession: getDefaultSession,
        store,
    })
);

bot.start(hi);

bot.hears(hiRegExp, hi);
bot.command(hiRegExp, hi);
bot.action(hiRegExp, hi);

bot.hears(previewRegExp, preview);
bot.command(previewRegExp, preview);
bot.action(previewRegExp, async ctx => {
    await ctx.answerCbQuery();
    await preview(ctx);
});

bot.hears(cancelRegExp, cancel);
bot.command(cancelRegExp, cancel);
bot.action(cancelRegExp, async ctx => {
    await ctx.answerCbQuery();
    await cancel(ctx);
});

bot.hears(publishRegExp, publish);
bot.command(publishRegExp, publish);
bot.action(publishRegExp, async ctx => {
    await ctx.answerCbQuery();
    await publish(ctx);
});

bot.on(message('text'), async ctx => {
    ctx.session.messages.push({ text: ctx.message });
});

bot.on(message('photo'), async ctx => {
    ctx.session.messages.push({ photo: ctx.message });
});

bot.on(message('video'), async ctx => {
    ctx.session.messages.push({ video: ctx.message });
});

Please note that we've updated the bot instantiating by adding the Context type defined previously.

You can re-build your code and try it on a mobile phone or web version of Telegram. Here is an example of chatting with my bot:

In the last part of the series, we'll make it more production-ready and add Fastify and some plugins to keep information between restarts and manage configuration.

Photo by mariyan rajesh on Unsplash

Your own Telegram bot on NodeJS with TypeScript, Telegraf and Fastify (Part 1)

Denis Sirashev — Fri, 03 Jan 2025 18:18:30 +0000

There are a lot of articles about creating your own Telegram bot. Many courses and boot camps use the "Telegram bot" idea as one of the entry points on your way to the top of the IT carrier.

"Spend a few hours, do this and this, and you have the very-super-smart bot that you can sell for billions..." - says nobody.

Telegram bots are critical nowadays and are another way of interfacing with your applications. In Yandex, for example, they help you control the quality of your deployment, communicate quickly with related teams, and coordinate incidents.

My idea is to create a bot that publishes news from people and to write about it step by step in this series of articles. So, let's go!

Project initialization

I will use pnpm as a package manager for the project. If you don't have it or don't know how to install it on your device, please check the official site for required information - https://pnpm.io/installation

Let's create a new folder (Mac OS/Linux commands)

mkdir PublishBot && cd PublishBot

To use packages as dependencies, we need to init pnpm locally. This will create a basic package.json, for which we'll add essential scripts to build and launch our bot correctly.

pnpm init

Typescript is a must; to add it, let's install it locally. And initialize then

pnpm add -D @types/node typescript && pnpm tsc --init

The file structure is simple: /src directory is for source code, and /dist is for compiled scripts. To enable /dist directory compilation, uncomment the outDir line in tsconfig.json in the compilerOptions section. Full version of tsconfig.json:

{
    "compilerOptions": {
        "target": "es2016",
        "module": "commonjs",
        "outDir": "./dist",
        "esModuleInterop": true,
        "forceConsistentCasingInFileNames": true,

        "strict": true,
        "skipLibCheck": true
    }
}

Before proceeding to the package.json file and creating scripts to build and launch our bot, we should install additional dev packages - concurrently and nodemon. Why do we need them? Concurrently will allow us to run multiple commands in one script. Nodemon will automatically monitor the files and re-run the application if they change.

pnpm add -D concurrently nodemon

We need four scripts to build and run our NodeJS application:

build - it will compile our source Typescript code into Javascript code;
build:watch - same as build, but it will watch for file changes and re-build the application;
start- it will start the server from the distributive folder with nodemon ;
dev- it will help us in the development process by simply watching for code changes, rebuilding the application, and re-running it.

Here is the fragment of the package.json scripts section

"scripts": {
    "build": "tsc -p tsconfig.json",
    "build:watch": "tsc -w -p tsconfig.json",
    "start": "nodemon dist/index.js",
    "dev": "concurrently \"pnpm build:watch\" \"pnpm start\""
}

In the dev command, concurrently helps us run two scripts simultaneously - we're re-building our source code and re-running the application on every saved change.

Telegramf bot

BotFather creates all bots in Telegram - you need to write @BotFather in your Telegram application and create a new bot with the command /newbot. Then, you choose a name for it, for example, My Publish Bot. Finally, you should select a unique username with a bot at the end of the name.

Finally, @BotFather will send you a token to access the HTTP API to control your bot. You don't need to manually write all requests to Telegram Bot API because there is a NodeJS library called telegraf. Install it via console command:

pnpm add telegraf

Now, we can start programming our publish bot. Let's create an index.ts file in the src directory:

mkdir src && touch src/index.ts

First, we need a Telegraf class instance with a bot token passed into a constructor. Let's import the class from the telegraf package.

import { Telegraf } from 'telegraf';

To use it, define a variable of the instance. Use a bot token that you received from the @BotFather:

const bot = new Telegraf(<BOT_TOKEN>)

Each bot should have a start/introduction screen. It's a common pattern, and the /start command can call it. To add it to your bot, the bot instance has a start method. It receives the callback function with a context variable, which has a lot of methods to simplify replying and getting the message from a user:

bot.start(ctx => ctx.reply('Welcome to Publish Bot!'));

And finally, to launch your bot, call a launch method with a callback. It is a good practice to log into the console with a message that your bot is running.

bot.launch(() => console.log('Bot is running'));

Here is the final version of the index.ts file:

import { Telegraf } from 'telegraf';

const bot = new Telegraf('<BOT_TOKEN>');

bot.start(ctx => ctx.reply('Welcome to Publish Bot!'));

bot.launch(() => console.log('Bot is running..'));

To test your bot, write in the console a command to run dev script from the package.json (don't forget to add your bot token):

pnpm dev

You should see a "Bot is running.." message at the end of the console's window. Everything is correct, and you can go to your Telegram application and write a /start command to your bot. You can find the chat with it in the "Search" field or go back to @BotFather and click on the link in the confirm message with your bot name.

If it is okay, you should have seen the "Welcome to Publish bot!" message in your chat with your bot. And that's it. You have a silly bot with a start screen, which is not what we wanted in these articles. To react appropriately, we must support our users' commands, actions, and text patterns and have a memory to work with users' drafts. These will be in the next part of the articles. See you soon!

Photo by Lana Codes on Unsplash

Secrets of numbers in JS

Denis Sirashev — Sat, 08 Oct 2022 10:54:01 +0000

Rounding errors

Interesting things could happen in Javascript if you don't know how it's working under the hood. For example, floating-point numbers cause some rounding errors. 0.1 and 0.2 cannot be represented precisely. Hence, 0.1 + 0.2 === 0.3 yields false.

So, why it's happening? Javascript uses 32-bit floating-point number system. Representing many decimals in binary requires an infinite number of digits. Trying to calculate 0.1 (1/10) results in an indefinite number of decimal points. The result of 0.1 + 0.2 is 0.30000000000000004 which doesn't equal 0.3.

Number.EPSILON

Number.EPSILON returns the smallest interval between two representable numbers. This is useful for the problem with floating-point approximation.

function numberEquals(x: number, y: number) {
    return Math.abs(x - y) < Number.EPSILON;
}

numberEquals(0.1 + 0.2, 0.3); // true

The difference between 0.1 + 0.2 and 0.3 will be smaller than Number.EPSILON.

Double dots

Numbers can be transformed into strings with a fixed number of decimal points. If you'll call toFixed() function directly on an integer, you'll need to use double dots notation like this: 5..toFixed(1) === '5.0'. Why should you do it? Simply because the first dot notation is for representing floating-point numbers: 0.77.toFixed(1) === '0.7'
You can use toFixed() function in the previous example to match equality (0.1 + 0.2).toFixed(1) === 0.3.toFixed(1)

Quick note: Primitives in Javascript aren't objects, but why can you use "string".length, 0.77.toFixed(1)? Well, Javascript creates a special wrapper object with a value for the primitive when you call a method and deletes it then after execution.

Minimums, maximums

Number contains interesting constants which represent maximum and minimum integers and floating-point numbers. Javascript has Infinity and -Infinity, but they aren't real numbers.

Number.MAX_SAFE_INTEGER returns the largest integer. It's equal to 9007199254740991 And this expression is true:

Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2; // true

Number.MAX_VALUE returns the largest floating-point number. It's equal to 1.7976931348623157e+308. Same expression for it:

Number.MAX_VALUE + 1.111 === Number.MAX_VALUE + 2.022; // true

Minimums are represented by Number.MIN_VALUE as the smallest floating-point number which is equal to 5e-324 and Number.MIN_SAFE_INTEGER which is equal to -9007199254740991.
Number.MIN_VALUE is also the closest floating point to zero.

Number.MIN_VALUE - 1 === -1; // true

Why is it true? Because this expression is similar to 0 - 1 === -1

Summary

Let's summarize the size of the Javascript numbers:

-Infinity < Number.MIN_SAFE_INTEGER < Number.MIN_VALUE < 0 < Number.MAX_SAFE_INTEGER < Number.MAX_VALUE < Infinity

When you're working with floating-point numbers, you should be careful and take into account rounding errors, because some numbers cannot be represented precisely. You can use third-party libraries or check differences between numbers with Number.EPSILON.

Photo by Volkan Olmez on Unsplash

Quick tip 1 - How to remove an index signature from a type?

Denis Sirashev — Sun, 02 Oct 2022 12:26:19 +0000

Prehistory

During my work as a React developer, I found a situation when you need to remove an index signature from a type.
A simple example, the type utility Omit doesn't work properly when a type has an index signature. I've worked with the react-select js library and I'd wanted to get all base attributes of a SelectProps using Omit<SelectProps>, but received an any type. Trying to solve the problem, I located a problem inside SelectProps - it extends from a SelectComponentsProps which is a mapped type.

Solution

The solution is to remove the index signature. How to do it? In TypeScript 4.1 and onwards, you can re-map keys in mapped types with an as clause. We can create a utility type with generic and it will remove all index signatures in a specified type:

type RemoveIndexSignature<T> = {
  [K in keyof T as string extends K ? never : number extends K ? never : symbol extends K ? never : K]: T[K]
}

What does it do?

It iterates through the keys of a type and checks, if a type of the key is string, number, or symbol, then removes it, otherwise keeps it in the type. In the end, you'll get a clean type without any index signature in it.

Example

type Base = { [key: string]: boolean }

type User = Base & {
  email: string
  name?: string
}

type Cleaned = RemoveIndexSignature<User>

type Cleaned = {
  email: string
  name?: string
}

Photo by Alex Kotliarskyi on Unsplash

Code snippets can improve your development

Denis Sirashev — Wed, 20 Jul 2022 08:40:30 +0000

As a developer, I hate making repetitive things. I’m working as a React developer and creating of all the functional components, hooks and styles again and again annoys me.

Most of the IDE and Code Editors support code snippets which help us create templates. I use the VS Code Editor and for each of a project that I’m working on, I’m trying to add code snippets.

Functional component

Let’s start with a simple example of a creating functional component:

import React from ‘react’
import * as S from ‘./${TM_FILENAME_BASE}.styles’

interface ${TM_FILENAME_BASE}Props {

}

function ${TM_FILENAME_BASE}(props: ${TM_FILENAME_BASE}Props) {

}

export { ${TM_FILENAME_BASE} }
export type { ${TM_FILENAME_BASE}Props }

I use a variable ${TM_FILENAME_BASE} which represents a filename without its extension. Usually, filename and the name of a component are the same, so it will automatically fill all variables with a component’s name.

Responsive component

I enjoy styling components with styled-components. You can check an article about it here on Dev.to As you can see in the example below, a code snippet contains everything we need to create a responsive component.

import React, { useCallback } from ‘react’
import { ${TM_FILENAME_BASE}Props } from ‘./${TM_FILENAME_BASE}’
import * as S from ‘./Responsive${TM_FILENAME_BASE}.styles’

type Responsive${TM_FILENAME_BASE}Props = ${TM_FILENAME_BASE}Props

function Responsive${TM_FILENAME_BASE}(props: Responsive${TM_FILENAME_BASE}Props) {
  const renderDesktop = useCallback(() => <S.Desktop${TM_FILENAME_BASE} {...props} />, [props])
  const renderMobile = useCallback(() => <S.Mobile${TM_FILENAME_BASE} {...props} />, [props])

  return <ResponsiveLayout renderDesktop={renderDesktop} renderMobile={renderMobile} />
}

export { Responsive${TM_FILENAME_BASE} as ${TM_FILENAME_BASE} }
export type { Responsive${TM_FILENAME_BASE}Props }

Responsive component styles

A code snippet with styles for a responsive component is trickier. The major problem is a regex syntax. We need to remove a conditional responsive word from the filename and the .styles part. By passing the /(Responsive|)(.*)\\..+$/$2/ we take only a name of a functional component and remove other parts.

import styled from ‘styled-components’
import { ${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/} } from ‘./${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/}’

const Desktop${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/} = styled(${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/})``
const Mobile${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/} = styled(${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/})``

export { Desktop${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/}, Mobile${TM_FILENAME_BASE/(Responsive|)(.*)\\..+$/$2/} }

Redux standard action

Here’s an example of a code snippet for a standard redux action. Interesting part is in the naming of a payload interface: if a component name starts with a capital letter, a redux action name shouldn't. To properly name the interface, we need to transform the filename using upcase word: /([A-z]{1})/${1:/upcase}/ select the first letter and transform to upper case.

import { createStandardAction } from ‘typesafe-actions’

interface ${TM_FILENAME_BASE/([A-z]{1})/${1:/upcase}/}Payload {

}

const ${TM_FILENAME_BASE}Action = createStandardAction(‘$0${TM_FILENAME_BASE}’)<
  ${TM_FILENAME_BASE/([A-z]{1})/${1:/upcase}/}Payload
>()

export { ${TM_FILENAME_BASE}Action }
export type { ${TM_FILENAME_BASE/([A-z]{1})/${1:/upcase}/}Payload }

Conclusions

As you can see, code snippets are the powerful things and they can improve and increase your development speed. If you have a repeating code structure or you need to create a lot of similar files, please look at the code snippets.

Photo by Adi Goldstein on Unsplash

How do styled-components help us to build responsive pages?

Denis Sirashev — Sun, 24 Oct 2021 06:16:37 +0000

There are different approaches to style components in React applications. Each of them has its pros and cons, and, of course, preference in choosing a particular library is sometimes subjective. It can cause misunderstanding in a team when you're not agreeing with using styled-components in your project because you'd already worked with one library before, and it's not prominent and easy to switch to see the benefits of a new approach. Here you have a question: "Why should I use this instead of this?" and we're going to answer it at first.

Why did we choose styled-components?

One of our team members asked this question because he always used CSS Modules and didn't understand why it's useful. Yes, adding classnames to HTML tags or even child components is very clear and understandable which styles we're implementing, but here becomes a mess of many div elements. You can use more semantic HTML tags like section, header, but anyway, it doesn't help so much.

Creating styled components and naming them as what they are for, we think, makes our code much readable and clear. You quickly see the wrapper, overlay, the body or header of our modal, etc. And no bunch of classnames depends on different conditions, only adding custom properties which also tell us what behavior we're covering using styles.

When you're using CSS Modules and changing class names by mistake, an error is only perceptible by running the app and looking into it. Implementing styled-components gives you a compilation error if anyone is trying to use a non-existent element.

Here's a simple example of implementing styled-components:

<Wrapper>
    <TitleContainer>
        <Title>Modal dialog</Title>
        <CloseButton highlighted={isCloseButtonHighlighted} />
    </TitleContainer>
    <TabsContainer>
        <Tabs {...} />
    </TabsContainer>
    <Content>
        Our cool modal content
    </Content>
</Wrapper>

Everything is clear, and you can take a first look at this modal component and get a whole idea of how it's structured and how it can behave on different property values. <CloseButton /> has highlighted property, which will add some background and other visual changes. We can easily implement it by defining custom property in the <CloseButton /> styled component:

const highlightedButton = css`
    background: ${props => props.theme.colors.softYellow};
    color: ${props => props.theme.colors.primaryText};
`

const CloseButton = styled.button<{ highlighted: boolean }>`
    background: transparent;
    color: ${props => props.theme.colors.secondaryText};

    ${props => props.highlighted && highlightedButton}
`

As you can see here, we defined custom CSS styles via the css utility and used predefined theme colors whenever we needed them. Let's go deeper and talk about configuring and structuring component styles.

How do we cook them?

How should we structure styles and styled components? Putting them in one file with React component is not a good idea because otherwise, it will not follow the principle of single responsibility.

For each component, we create a separate *.styles.ts file, which can contain styled components and re-usable CSS styles or style objects for third-party plugins like react-select.

It can be imported into a component file then all at once like this:

import * as S from './Component.styles.ts'

It gives us two benefits:

Compact way of importing all required styled components and using them with code completion support from IDE;
Create a stylable component and individually set style for different devices.

What is the stylable component?

"What is the stylable component?" In answering this question, we want to say that it's a component with a defined dictionary of all styled components used inside. We can create it with the utility function:

import React from 'react'
import styled, { isStyledComponent } from 'styled-components'

type StyledChildren = Record<string, React.ComponentType>
type StylableComponentType<P, S extends StyledChildren> = React.ComponentType<P> & { S: S }

function createStylableComponent<S extends StyledChildren, P>(
    styledChildren: S,
    component: ReactComponentType<P>,
): StylableComponentType<P, S> {

    const stylableComponent = 
        (isStyledComponent(component) ? component : styled(component)``) as React.ComponentType<P>

    Object.defineProperty(stylableComponent, 'S', { value: styledChildren })

    return stylableComponent as StylableComponentType<P, S>
}

It looks simple but gives us a powerful mechanism to create responsive views, which we use all over the application. It's possible to separate styled components for desktop and mobile versions, having one stylable component with business logic and layout. How to do it properly?

Responsive styled components

Let's use <Modal /> from the previous example and modify it to use our styled components from different styles files and create a stylable component from it:

import React from 'react'
import * as S from './Modal.styles.ts'

function Modal(props: ModalProps) {
    // Some logic goes here
    {...}

    return (
        <S.Wrapper>
            <S.TitleContainer>
                <S.Title>Modal dialog</S.Title>
                <S.CloseButton highlighted={isCloseButtonHighlighted} />
            </S.TitleContainer>
            <S.TabsContainer>
                <S.Tabs {...} />
            </S.TabsContainer>
            <S.Content>
                Our cool modal content
            </S.Content>
        </S.Wrapper>
    )
}

const StylableModal = createStylableComponent(S, Modal)

export { StylableModal as Modal }

Having the Modal component, we can define <ResponsiveModal />, which has two callback functions to render desktop and mobile versions of <Modal /> and passes these callbacks to another <ResponsiveLayout /> component which calls given functions depending on window size.

function ResponsiveModal(props: ModalProps) {
    const renderDesktop = useCallback(() => <S.DesktopModal {...props} />, [props])
    const renderMobile = useCallback(() => <S.MobileModal {...props} />, [props])

    return <ResponsiveLayout renderDesktop={renderDesktop} renderMobile={renderMobile} />
}

Same as for typical components, any responsive components also have their styles, mainly importing dependant children (<Modal /> as an example for <ResponsiveModal />). And here comes the magic of the stylable component, which gives the ability to granularly adapt every element for required devices with code completion from IDE.

import { Modal } from './Modal'

const DesktopModal = styled(Modal)``
const MobileModal = styled(Modal)`
    ${Modal.S.Title} {
        font-size: 0.75rem;
    }
`

export { DesktopModal, MobileModal }

Conclusions

To sum up, defining responsive components with the styled-components library is straightforward, follows the single responsibility principle, self-evident and clear understanding of what is for looking at folders' and code's structure. Creating components with the stylable component function gives advantages:

the ability to manipulate layout and elements without importing them from another style's files;
having a complete list of available elements and styled components.

Photo by Goran Ivos on Unsplash

Forem: Denis Sirashev

Bringing locally running LLM into your NodeJS project

Introduction

Choosing model

Docker containers

Configuring Ollama

Using your own hosted LLM model

Conclusions

Quick tip 2 - Completely ignore node_modules for Docker in Monorepo

The problem

The solution

Three levels of Breadth-First Search algorithm

Introduction

Challenge

Implementation

Typings

Sync BFS

Strategies

"Path exists" strategy

"Shortest route" strategy

Async BFS with async/await

Async BFS with promises

Conclusion

Build and run your project in Monorepo with PNPM

Introduction

Setup

Telegram package

Put it all together

Conclusion

Your own Telegram bot on NodeJS with TypeScript, Telegraf and Fastify (Part 3)

Fastify

Configuration

Redis

Telegraf bot

Application

Docker and Docker Compose

Conclusion

Your own Telegram bot on NodeJS with TypeScript, Telegraf and Fastify (Part 2)

Types

Memory - Telegraf session

Commands

Cancel command

Hi command

Preview command

Final touches

Your own Telegram bot on NodeJS with TypeScript, Telegraf and Fastify (Part 1)

Project initialization

Telegra​​m​f bot

Secrets of numbers in JS

Rounding errors

Number.EPSILON

Double dots

Minimums, maximums

Summary

Quick tip 1 - How to remove an index signature from a type?

Prehistory

Solution

What does it do?

Example

Code snippets can improve your development

Functional component

Responsive component

Responsive component styles

Redux standard action

Conclusions

How do styled-components help us to build responsive pages?

Why did we choose styled-components?

How do we cook them?

What is the stylable component?

Responsive styled components

Conclusions

Telegramf bot