DEV Community: Denis Sirashev

Making of StarTrack: From a Prompt Through Tasks to TestFlight

Denis Sirashev — Tue, 07 Jul 2026 17:19:12 +0000

One week of evenings, 9 issues from a PRD, one AI pipeline — and what I learned along the way.

It all started with an ordinary parenting problem: my son — he's nine — constantly wanted more screen time, and every conversation about it ended in an argument. My wife and I tried restrictions and control — it didn't work. Then Claude suggested a different approach: don't restrict — reward. A prize for every completed task. All that was left was tracking the tasks and the rewards, and I thought: why not build an app that takes care of that? That's how the idea of StarTrack was born.

Why I decided to entrust development to AI in the first place, and how it changed the very process of prototyping, I covered in detail in my previous article — How AI Changes Prototyping and Testing Ideas. This article is about the process itself: step by step, from the first prompt to testing in TestFlight.

Spoiler: 1 week from idea to TestFlight, working evenings only; 9 tasks carved out of the initial PRD; around 14 screens; budget — a Claude Max subscription.

The First Prototype in One Evening

I had prior experience building with React Native: you assemble features screen by screen, and then it all compiles into a working app for iOS and Android. But this time I decided to hand development over to AI as much as possible — following the Pareto principle I wrote about in the previous article: 20% of the effort for 80% of the result, without polishing the code to a shine in the early stages.

First, I asked the AI to sketch out a tracker based on the rules we had already defined for our son and the reward economy. The very first screen made a strong impression: there it was — an almost ready, working task tracker, right inside the chat with the AI. Interactive, keeping count of all the stars and rewards. Take it and run it, right now.

I decided this was a good starting point to get serious about building a working app — one that could be used beyond our family.

Product Requirements Document

Based on the rules we had already tested on our son, the requirements for tasks and rewards, and the fact that we needed a tracker app on our phones, I asked the AI to prepare a PRD (Product Requirements Document) — the initial document and foundation for development.

After digging into the nuances of both publishing and running the app, I settled on the Expo + Firebase stack. Expo is wonderful for fast development and testing: you write code, make changes — and it instantly compiles and runs on every platform. Firebase gives you a nearly free realtime database with push notifications, authentication, and subscriptions to data changes.

The core entity is the family: it defines the tasks the kid needs to complete, the rewards, and the family members themselves, with separate permissions for the child and the parent. To make inviting a new member easier, I asked to include QR code generation and a scanner.

After all the revisions, the AI produced a large, detailed document: project goals, database schemas, architecture, stack, a basic implementation of Cloud Functions, and access levels for the entities. A document like this should not be dumped into the AI with a request to "turn it into a finished product." It's a foundation that needs to be sliced into concrete tasks (issues) — and those you can feed to the AI.

Writing Tasks and Iterating

I did all the preparation in the Claude web chat, which lets you view documents, download them, or edit them on the spot. After downloading the PRD, I saved it into a pre-made folder for the future project so I could start the development loop in the console.

With the PRD in the project root, you can reference it in a prompt via @prd.md and ask the AI to prepare tasks for implementation. Each task should be built as a vertical slice — covering both the backend and the frontend, so that once it's done, you can launch it and test it visually. Each task is saved as a document in the project root.

Example prompt: Take @PRD.md and slice the project into separate tasks —
in such a way that after each task, the project can be launched and
verified on a simulator or a real device. Everything must be covered
by tests.

In the end, the first PRD gave me 9 tasks covering all the basic functionality of the app. These tasks were uploaded as issues to my project's GitHub repository — that makes it easier to track them and mark them done.

With the PRD broken into tasks, you can iterate through them one by one. "Accept mode" fits well here, so you don't get interrupted to approve every single edit. My goal was a working product without deep-diving into the code along the way; polishing would come later.

The process never becomes fully unsupervised, though: Claude still asks permission for particularly sensitive commands — the ones that could cause harm or read something they shouldn't. The human remains a mandatory participant. As I said, this mode is mostly about skipping the code reading: if something breaks, I'll catch it at compile time or during testing.

After the first task, I got a basic starting screen — still with mocks, but already reflecting everything essential I wanted to see in the app. The only thing I didn't like was the visual side. And here comes the magic that lets you change direction on the fly: in the web chat, which already had the project description, I asked for three design variants — in parallel with the console, where the app kept being built according to the prepared tasks.

How I chose between the variants and why this way of testing hypotheses works at all is the subject of the previous article. Here I'll just talk about the choice itself: I felt the app should radiate tenderness, care, and warmth. After all, it's being made for my kid, and I want him to enjoy using it. So I went with variant A — warm and soft, but not "babyish."

Having settled on the palette, the typeface, and the overall skeleton, I asked the web version of Claude to prepare all the main screens — both for the big picture and as mockups Claude Code could rely on during implementation.

This process is genuinely impressive and inspiring. You're the leader of two parallel processes working on your idea: in one place you analyze and discuss business, marketing, and design questions; in the other, you actively develop, adjust, and fix bugs. And all of it happens in the blink of an eye.

Since a redesign is a very heavy operation that burns a lot of context, after preparing all the mockups I asked Claude to slice the redesign into tasks as well, so I could iterate through them one at a time. As a result, I had 13 tasks (issues) ready for implementation.

Refactoring and Improving the Code

To keep tech debt from piling up and to give the AI higher-quality code to work with, I decided to do a full refactor toward the end of development, including adopting a frontend architecture. Since the project is React Native — essentially a pure frontend app — I chose FSD (Feature-Sliced Design).

The code was already written reasonably well, but it was time to finally move everything into separate files and put the logic where it belongs. To start, I asked the AI to analyze the structure and the code and, with the move to FSD in mind, prepare a migration plan. The FSD migration didn't require burning through many tokens, so I asked the agent to continue working through the plan after first running the /compact command to preserve the most essential context. A good share of the files were simply distributed into different folders with console copy commands, instead of crowding together in one shared place.

The final structure turned out really well, and once again — the Pareto principle in action: 80% of the result for 20% of my effort.

Testing and Delivery

Right now I'm actively rolling the app out within the family to understand how convenient it is and whether I've accounted for everything. Bugs that pop up I fix quickly through the AI: I describe the problem and hint at which component might be the source.

Here's what the app looks like now — that same warm direction from variant A, alive and well in production:

As we use it, new ideas keep coming up. For example: tasks are different — some are urgent, others are daily; they have different completion times and different rewards. That's how a plan for different task types was born, each with its own quirks.

For fast delivery of changes, I hooked up EAS builds: they let you update just the bundle and push it instantly to the installed apps, bypassing the publishing and review process.

Testing on iOS via TestFlight turned out to be less intuitive than expected: it took time to figure out both the interface itself and how to invite users to the beta test, plus waiting for newly built versions to be approved — thankfully, EAS speeds this up a bit.

Takeaways

To wrap up, here are the key points and results:

Timeline: from idea to TestFlight — 1 week of evenings (of which the PRD took 2 days and development took 5 days)
What I'd do differently: I would probably have started real-world usage earlier — under "ideal" greenhouse conditions of simulation, you can't see the real problems, especially since iterating quickly is not an issue with AI
What's next: we'll bring in our second kid via the Android version so the kids can earn and spend points together — through a separate additional "family," keeping their areas of activity apart. Eventually, I'd like to publish the app for everyone, if it genuinely solves a real pain
Advice for anyone who wants to repeat this path: don't be afraid to try, and don't worry about how the code is written. These days, almost anyone with even a little technical background can test their hypothesis and decide whether it's worth investing further

Drop your questions in the comments — I'll be happy to talk through the pipeline.

How AI Changes Prototyping and Testing Ideas

Denis Sirashev — Sun, 05 Jul 2026 18:13:43 +0000

Introduction

It all started with an ordinary parenting problem. My son — he's nine — constantly wanted more screen time for games and YouTube, and every conversation about it ended in an argument. After a lot of thinking and experimenting with the help of Claude Opus, I arrived at the idea of StarTrack — an app where a kid earns stars for completed tasks and spends them on rewards like screen time. And while working on it, I realized just how dramatically AI has changed the process of building prototypes and MVPs.

The Road to a Solution

My wife and I spent a long time figuring out how to set up a system of control that would be painless both for us and for our son. First we came up with restrictions and rules on our own. That didn't work. Then I discussed the problem with Claude, and it suggested a different approach: don't restrict — reward. A prize for every completed task. It sounded reasonable, and as a bonus, it nudges kids toward chores they'd otherwise put off. The only problem was tracking: both the completed tasks and the rewards. And I thought — why not build an app that takes over tracking progress and awarding points?

Using AI lets you jump straight into testing any hypothesis that comes to mind and might solve your problem. One prompt — and 10–15 minutes later you have a working version that handles the core task. With capabilities like that, the only real constraint is the choice itself: what to build, what to pick, and where the line of "good enough for now" sits. Sure, the code quality won't be perfect, but I've come to like the Pareto principle — 20% of the effort gives you 80% of the result. What if we apply it to writing code, with AI doing the writing? There's no need to burn energy polishing the code and its structure to a shine when a little effort is enough to get a good result. Not excellent, not perfect — good. The kind that works and bears fruit.

And that's when I noticed the bottleneck had shifted: the question is no longer how to build, but what to build.

The Shift in Approach

As you keep working on and improving your product, you want to understand which direction to take next — there can be several paths and solutions. I asked Claude to sketch out three design variants for the main screen. No, they're not perfect, but perfection isn't the goal here and now.

Right there in the chat, you can try out three completely different variants. All it took was context and plain human language. If none of them fit, you can say right there what you like or what you'd want to see — a couple of minutes, and you have new options.

In the end, having picked variant A and prepared a prompt based on its description, Claude Code can implement it right away. Of course, the result will differ visually, but after uploading the mockup and pointing out the flaws, the AI brings the implementation in line with the mockup you're aiming for. All of this takes a couple of clicks and keystrokes — no explanations, no handoffs from one person to another. The design → handoff → code gap disappears.

You can also test not just the visuals but the mechanics themselves. For example, at some point an idea came up: lock the rewards store until the kid finishes the mandatory tasks. It sounded logical — chores first, spending stars later. Instead of arguing about it in theory, I quickly described the mechanic in the chat and got an interactive mockup. And almost immediately it became clear the idea was bad: it freezes stars the kid has already earned, duplicates the existing bonus-unlock mechanic, and breaks if the parent hasn't confirmed a task yet. Fifteen minutes — and the hypothesis was discarded, without a single line of code in the actual app. In the past, I most likely would have coded that idea, discovered the problems in production, and rolled it back.

Running two parallel processes — Claude Code and the Claude web chat — lets you first express a rough idea, discuss it, refine and rework it, and then get a ready prompt or a ready document/mockup to implement in the Claude console. This kind of workflow transforms your role as a developer: you're now the conductor, not the performer of every part. A good chunk of the routine work goes away, letting you focus on what actually matters.

Where It Breaks Down

The human doesn't disappear from this process. You can't fully hand development over to AI yet: you need to understand what's happening in the code and correct course in time. Taste remains a human thing — it's the human who decides which color works better, what the app feels like to use, and what others will get out of it.

AI introduces bugs, implements something other than what you expected, or forgets certain requirements. What helps here is breaking large tasks into smaller ones and using the vertical slices approach: you take each piece of functionality to a state where you can launch it and test it right away, and fix any bugs or deviations from the spec on the spot. I learned this the hard way: at first I quickly implemented several features at once, and after launch discovered that some of them didn't work — the QR invite would sometimes hang during scanning and never notified either side whether the operation succeeded. After that, I started taking every feature to a "launched and verified" state before moving on to the next one.

There's also a code problem: tech debt piles up, quality declines, and you have to stop, look at the structure and content, and decide whether it's time to refactor. Working on the app, I noticed how badly the files had started to balloon — some of them already held 5–10 functions each, and the line count had passed 2,000. It couldn't go on like that: code quality would only drop with every iteration. So before moving forward, I decided to adopt the FSD (Feature-Sliced Design) architecture and split the code into separate folders and files, improving readability and quality.

Conclusion

It's already hard to imagine a modern engineer without an AI tool. It looks like the next turn of the same evolution: assembly → high-level languages → natural language.

I didn't start with an app — I started with the wish that my kid would do his chores without fights. And I ended up understanding how much the very process of making things has changed. AI didn't write the product for me — it removed the expensive part of production and left me the part that matters most now: deciding what to build, feeling what the app should be, and saying in time, "this is it — and this isn't." Code has become cheap. Taste hasn't. And it seems that's exactly what the developer's new job is.

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

DEV Community: Denis Sirashev

Making of StarTrack: From a Prompt Through Tasks to TestFlight

The First Prototype in One Evening

Product Requirements Document

Writing Tasks and Iterating

Refactoring and Improving the Code

Testing and Delivery

Takeaways

How AI Changes Prototyping and Testing Ideas

Introduction

The Road to a Solution

The Shift in Approach

Where It Breaks Down

Conclusion

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

Telegramf bot