DEV Community: Vsevolod

Tired of bloated installers and complex DevOps pipelines? I built pport.top — a terminal-based messenger — to demo a crazy simple idea: Instant CLI delivery over HTTP Just curl or irm, nothing else TypeScript on the fly via Deno Live deployment

Vsevolod — Sat, 26 Apr 2025 18:01:57 +0000

📝 I Built nowrite.fun – A Writing App That Deletes Your Text If You Stop Typing

Vsevolod — Wed, 23 Apr 2025 19:41:05 +0000

Hey devs!

So, I had a free afternoon, some chaotic energy, and an old idea rattling around in my head:
What if you had to write without stopping... or lose everything you’ve typed?

That’s how nowrite.fun was born — a simple, slightly unhinged writing app where:

You set a timer (e.g. 5 minutes)

You start typing

If you pause, even briefly… 💥 your text disappears. No second chances.

Why?
I’ve always been intrigued by tools like Write or Die or the old Svečki app (RIP). I wanted to see how fast I could build a modern twist on that idea using AI copilots — GPT-4o, Claude 3.7 — and a solid web stack:

🦕 Deno + TypeScript
🧠 XState for state logic
🎉 anime.js & canvas-confetti for ✨ vibes
🚀 Hosted on Deno Deploy

What’s it for?
Quick writing sprints: blog intros, tweets, journal entries, brainstorming.
You type → you survive.
You stop → it's all gone.
Brutal, but weirdly satisfying.

Wanna support?
I launched it on Product Hunt too — it’d mean a lot if you check it out or give it an upvote ❤️

💻 Try it out!

I’d love your thoughts, feature ideas, or "lol this is pure chaos" reactions.
Happy to answer any questions about the tech stack or the (admittedly unhinged) development process.

Cheers! 🙃

🦆 Introducing DevExp – a unified CLI platform for indie developers

Vsevolod — Mon, 14 Apr 2025 09:13:29 +0000

Hi dev.to! 👋

After years of juggling too many tools, managing subscriptions I barely used, and trying to remember endless CLI syntaxes, I finally snapped.

I'm not good at remembering a million commands. I don't want to babysit 5 different dashboards.
And I hate subscriptions. Especially when they start stacking like Tetris blocks in my brain.

So I decided to build the platform I’ve always wanted:
A single CLI-first tool that gives me everything I need to build, deploy, and operate — under one roof, with one subscription, and on my terms.

🚀 Meet DevExp (or simply dx)

DevExp is a programmable CLI platform for indie developers, solo hackers, and lean teams.

Think of it as a developer experience layer that wraps tunnels, secrets, git, databases, LLMs, automations — into one cohesive CLI.

You install dx, and boom — the toolbox is yours.

🔧 What it does (so far)

Here’s what’s working (or in active prototyping):

dx tunnel — fast HTTP/WS tunnels (think ngrok, but native)
dx vault — secure secrets & env management
dx hyper — process manager for Deno-based microservices
dx llm — use OpenAI, local models, or your own API
dx git - git identity switching, git flow and more

Coming soon:

Instant deployments
Database access & migrations
Remote script execution

All in one CLI. No tabs. No clutter.

🧠 Why I’m building this

I built dx for people like me:

Indie devs and makers
Solo founders and hackers
Small startups that want fewer tools, not more

I believe the best developer tools are:

Fast
Composable
Predictable
And respect your flow

DevExp is my shot at creating that.

🌱 What’s next?

Over the next year, I hope to grow DevExp into a truly unified dev experience.

One CLI. One install. Zero mental overhead.
From secrets to deploys to AI helpers — everything just works together.

Imagine never needing to “duct tape” your dev workflow again.

🙌 How you can help

DevExp is still early, but growing fast.
If this resonates with you — here's how to support:

⭐ Star the GitHub repo
📬 Join the waitlist
🐦 Follow and retweet @devexp
💬 Tell your dev friends or drop me feedback below

Thanks for reading! I’m building DevExp in the open — If you’ve ever wished for fewer tools, less cognitive load, and a developer stack that just works — you're not alone.

I wonder, am I the only one who installs all sorts of tools like ripgrep, better man, and another hundred utilities whose names I can’t even remember the next day?)

Vsevolod — Fri, 13 Dec 2024 17:57:42 +0000

Ohhh, it feels like I've completely forgotten how to truly "code"

Vsevolod — Fri, 13 Dec 2024 15:12:38 +0000

Initially, programming for me was something akin to a hobby. It was interesting, fun, challenging enough, and there was always something to do: from creating a simple game to tackling a complex algorithm or rendering project. I still remember one summer evening in the countryside where I used to live: my friend and I were sitting late at night in a log cabin, coding our own version of Digger (remember that DOS game?) in Java Micro Edition on NetBeans 6.8, which somehow managed to take five minutes to load on an old Eee PC. Whole sleepless nights went by like this because I didn’t have internet, and solving even small problems took significant time. It was fascinating, thrilling, but not something that promised any money.

It’s worth noting that before I officially started my career, I didn’t have to justify my ideas or the time spent on them with concepts like “usefulness” or “practical application.” I hadn’t yet been drawn into this “cult of productivity.” What mattered to me was my interest and the joy I got from the process. And there was a lot of joy.

But years passed, and today the result is clear: I don’t create anything funny, fun, or interesting. Almost never. I always have to justify and prove the usefulness of my efforts—to myself, to colleagues, friends, or acquaintances. I can’t approach development casually anymore: I immediately start planning architecture, drawing flowcharts, setting up all kinds of configs and microservices. But why? Because that’s how it’s done, that’s the standard in the professional software development world, which has completely consumed me.

I started with large websites using Nuxt on the front end and Django on the back end, complete with admin panels and various effects and animations on Canvas and WebGL. Later, I moved on to designing network software as a systems programmer to manage thousands of e-ink display price tags using Python and C. Yes, I’m still interested in many things. For example, I still want to write my own Forth system with blackjack or maybe a text-based roguelike (like NetHack). But most of these ideas never go beyond thoughts. Why? Because they probably won’t bring any tangible benefits—or even money. Any such initiative feels like a waste of time, so I immediately discard it.

Back then, I wasn’t constrained by any frameworks or societal standards and rarely interacted with “industry peers.” This freedom allowed me not just to enter the IT field but also to grow and develop across various domains (from graphics and neural networks to reverse engineering), gaining a broad perspective. And I was happy! Then came serious work, deep thought behind every decision, and experience in designing and building large, complex systems. Along with it came the fear of potentially wasting time, money, and resources, which suddenly became endlessly important. This second phase completely replaced the first, allowing me to grow my income and see myself as a “seasoned pro” who’s worth something. But what’s next? Beyond this lies stagnation and endless attempts to break free from this vicious cycle. Sure, salary growth can continue for quite a while, but the ceiling is already palpable, and higher pay doesn’t make me happier or improve my quality of life—in fact, the opposite.

And here’s where I started thinking: what if this relentless pursuit of rationalizing every minute and ounce of effort is actually harmful and ultimately leads to stagnation rather than meaningful growth? What if, in fact, coding all kinds of silly things isn’t just okay but absolutely essential? Because it’s one of the few proven ways to create something genuinely interesting or innovative. Let me say it again: every idea I have goes through a series of questions about its theoretical usefulness, feasibility, profitability, and so on. And even if I try to reject this kind of “global” OCD in my life, the people around me will pressure me with the same standards. After all, we’re all “adults” who don’t waste time, right? And while I ask myself these questions or strain to come up with something “useful,” time slips away—time I could have spent developing something personally interesting to me. My energy drains, and I feel exhausted to the core of my mind. Overcoming this inner compulsion to rationalize everything is incredibly difficult! Of course, this doesn’t cancel out the need for a main job, a salary, and so on, but it also prevents me from thinking outside the box.

So what’s the result? I’m still that “seasoned pro” who knows how to design and build complex systems—but nothing more.

What’s the solution, then? Should I throw myself into every random project that comes to mind, even if it’s a messenger for pink ponies on FreeDOS? Probably not. These are just thoughts, musings out loud, but I really want to return to those old, primal feelings of programming and achieving goals—even completely useless ones. I want to believe that going back to the beginning could help me grow meaningfully again, break free from the trap of middle-income comfort, and aim higher. Or maybe I’m fundamentally mistaken—who knows.

And more on my channel =)

Like Vim, but Helix

Vsevolod — Wed, 11 Dec 2024 08:17:45 +0000

The creator of Helix calls it a "post-modern text editor." What does that even mean? Who knows. But here's what really matters: multiple cursor support, imports, Tree-sitter, LSP, tons of beautiful themes with great support for popular programming languages — all of it available right after installation. You just download it, open the language config, tweak a couple of LSP settings for your Deno or Node.js projects, and you're good to go. No complicated setup rituals, no digging through obscure manuals, no configuring dozens of plugins (half of which probably won't even work). Even VSCode doesn't offer this kind of flexibility out of the box — but Helix just works.

When a vim-like editor immediately supports your favorite programming language, you don't have to get sidetracked by configuration — you can focus on what matters most: editing text. It sounds trivial, but with Vim, Neovim, or Emacs, I often didn't even make it to that point — I'd burn out during the setup phase. Helix is different. Sure, you won't memorize all the hotkeys for every mode right away, but the built-in hints and clear documentation help you ease into it quickly. It took me just a couple of days.

At first, the process feels like a game: you're exploring the editor's capabilities, learning key combinations, diving into the docs. It's fun because there are so many modes and tools. After a week, things start to click automatically. I’ve even caught myself trying to select text in Telegram like I would in Helix — habits form quickly. Yes, the system is complex, but it's intuitive. Once you master it, it becomes incredibly efficient.

So what’s the catch? Helix stands out because it has nothing extraneous, yet everything you need to just start coding. It doesn't waste your time with plugin setups or deciphering convoluted guides. It's simply an editor, with functionality focused purely on text editing.

However, there are a few things to keep in mind. Helix adheres to the Unix-way philosophy:

There are no plugins (yet), though they’re planned for the near future.
There’s no traditional file tree or tabs. Instead, Helix offers an alternative approach to managing files, which can quickly feel intuitive if you give it a chance.
It’s a fresh perspective on text editing and project structure. It's worth your attention. I’d strongly recommend Helix to anyone curious about vim-like editors but intimidated by the steep learning curve. Helix provides a smooth, intuitive introduction, making it easy to grasp the basics. Plus, it rekindles that spark of excitement you get when discovering something new. With Helix, editing text becomes genuinely enjoyable.

How do I use Helix?
Right now, it lets me keep dozens of personal and work projects readily accessible. That’s something I couldn't achieve with any IDE or editors like VSCode.

But remember: Helix is just a text editor. It's designed purely for editing text — nothing more. If you don't expect the impossible, it can be an outstanding tool for your daily workflow.

If you're looking for a fast, easy-to-learn, and powerful text editor, give Helix a try. It might just be exactly what you need.

And more on my twitter =)

💬 Daily meetings — sh*t?

Vsevolod — Fri, 13 Oct 2023 17:32:06 +0000

The thing is: I'm endlessly tired of "meetings" myself. I don't like conducting them, don't enjoy listening to all the nonsense unrelated to me, and struggle to recall their outcomes after some time. What's worse is that the timing of these meetings isn't always personally convenient for me. I don't want to step out of the "flow," switch gears, and so on. In general, daily/syncs/stand-ups in your Slack/Google Meet are a total mess (in most cases).

And what can be done about it? About a year and a half ago, I tried dailies in a text format. The essence is as follows: at a designated time, someone in the group chat sends a "daily message," and colleagues share how things are going in the thread. You won't believe it, but it works and works great. Now I can respond at a convenient time, gather my thoughts, analyze and remember all the work done during the day. It's already productive. But I'm a programmer, and that means automating such a routine. No problem! I wrote a simple script that sends this system message at a designated time. Even better, right? And no magic, everything is straightforward. But something is missing... Searching the chat after a month or two becomes inconvenient, so everything needs to be logged in a unified history and categorized by dates. No problem, now the script sends all replies to a special page in Notion.

It turned out to be an extremely useful automation: truly productive dailies at a convenient time + keeping a history of replies that you can refer to and analyze the work done, problems, and difficulties the team faced. And this amazing experience, I implemented it with my colleagues as a test bot DailyLog (currently in testing, only for Telegram). Give it a try, test it out, evaluate this format of daily meetings, and share your experience with me @itnigilist or in the comments under this post.

🔥🔥🔥 Important: tell your friends, colleagues about it. I'm sure many will be happy to reconsider the classic format and increase their productivity!

💬 Дейлики — это фигня?

Vsevolod — Fri, 13 Oct 2023 17:28:39 +0000

Дело вот в чем: я сам бесконечно устаю от "созвонов". Не люблю их проводить, не люблю слушать всякую дичь, которая не имеет ко мне никакого отношения, с трудом вспоминаю их результаты через какое-то время. Еще хуже то, что время таких встреч не всегда удобно персонально мне, не хочется выходить из "потока", переключаться и так далее. В общем, дейлики/синки/стендапы в этих ваших Slack/Google Meet — тотальная хрень (в большинстве случаев).

И что с этим можно сделать? Где-то полтора года назад я попробовал дейлики в текстовом формате. Суть в следующем: в назначенный час в групповой чат кто-то отправляет некий "daily message", а товарищи в тред рассказывают о том, как у них дела. Вы не поверите, но это работает и работает отлично. Теперь я могу ответить в удобное время, собраться с мыслями, проанализировать и вспомнить всю проделанную за день работу. Это уже продуктивно. Но я программист, а это значит, что подобную рутину надо автоматизировать. Без проблем! Написал простенький скрипт, который отправляет это системное сообщение в назначенный час. Еще лучше, не правда ли? И никакой магии, все предельно просто. Но чего-то не хватает... Поиск по чату через месяц-два перестает быть удобным, а значит надо все это логгировать в единую историю и разбивать по датам. Без проблем, теперь скрипт все реплаи отправляет на специальную страничку в Notion.

Получилась крайне полезная автоматизация: действительно продуктивные дейлики в удобное время + ведение истории реплаев, по которой можно ориентироваться и проанализировать проделанную работу, проблемы и трудности с которыми сталкивалась команда. И этот потрясающий опыт я со своими товарищами реализовал в виде тестового бота DailyLog (пока в состоянии тестирования, только для телеги). Попробуйте, протестируйте, оцените данный формат ведения ежедневных встреч и расскажите о вашем опыте мне @itnigilist или в комментах под этим постом.

🔥🔥🔥 Важно: расскажите про это вашим друзьям, коллегам. Я уверен, что многие будут рады пересмотреть классический формат и повысить свою продуктивность!

💌 Safe message sending script in Telegram with just 49 lines of code? Really?

Vsevolod — Sun, 01 Oct 2023 12:05:37 +0000

Mass messaging in messengers is always a challenging task that's hard to solve effectively. I won't be discussing any hacks or workarounds right now; instead, I'll share my approach that fully complies with the platform's usage rules (in this case, Telegram). And yes, I'm a fan of TypeScript + Deno. The latter is actively evolving, gaining new features and functions. One of the recent innovations is queues based on Deno KV, which is why I chose Deno for this article. Intrigued? Then, let's dive in!

Limitations

The legal way to send messages on Telegram is through bots. However, they come with indefinite restrictions that may change based on the bot's load, Telegram itself, the positions of stars, and magnetic storms. In general, it's approximately ~28 messages per second. What happens if you exceed this limit? Telegram will return a status 429 and indicate in the 'retry_after' header how many seconds you need to wait before continuing with the sending.

Requirements

Based on the aforementioned limitations, I propose implementing a mechanism for mass message distribution on Telegram with the following characteristics:

Strict adherence to the number of messages sent per second.
Tracking instances of exceeding the limit with a subsequent delay for the specified number of seconds.
Ability to resend messages in case of failure a certain number of times.
Waiting for a response to sending is interrupted after a specified timeout.
Option for delayed sending.
Script failures and crashes should not result in data loss, and message sending should resume after the script is back on track.
Whew, sounds complicated? Well, not really!"

Instruments

>> Deno KV
Let's start by choosing our tools. The first thing I want to draw your attention to is Deno KV, the built-in key-value database in the Deno runtime. As mentioned earlier, Deno KV now includes a queue mechanism. It's quite straightforward to use and comes with a delay feature. Here's a brief example where a message will be taken from the queue after 1 minute:

const db = await Deno.openKv();

db.listenQueue(async (msg) => {
  await post(msg.chat_id, msg.text);
});

await db.enqueue({ chat_id: -23423423423, text: "Hello, World!" }, {
  delay: 60000,
});

It's crucial to understand that Deno KV is stored as files on your hard drive. So, we have a mechanism for saving data and their deferred processing through a queue right 'out of the box'!

>> Fetchify
Next up are the requests, and we need to somehow limit their quantity per unit of time. It would also be good to handle retries in case of errors and manage delays when receiving a 429 status. Yes, this could be implemented manually, but I'll opt for my fetchify package, about which I've jotted down notes: one, two. It more than meets the needs in this case. Here's a quick example:

const api = fetchify.create({
  limiter: {
    // Number of requests per second
    rps: 3,
    // You can handle the occurrence of a 429 error
    // and return the time in ms that the request loop should delay
    "429": (response) => 1000,
  },
  baseURL: "https://jsonplaceholder.typicode.com",
  headers: {
    "hello": "world",
  },
});

for (let i = 30; i--;) {
  console.log(`send ${i}`);
  // All basic methods supported: get post put delete head patch
  api.get(`/posts/${i}`).then((data) => console.log(`${i} ${data.status}`))
    .catch((err) => console.log(`${i} ${err}`))
    .finally(() => {
    });
}

You can find more details here: GitHub deno.land/x npm

Implementation

Now we have everything we need. Ready? Let's take a look at the next 49 lines of code and rejoice:

import fetchify from "https://deno.land/x/fetchify@0.2.8/mod.ts";

class TelegramMailer {
  private tgApi;
  private queue: Deno.Kv = undefined as unknown as Deno.Kv;

  constructor(token: string) {
    this.tgApi = fetchify.create({
      baseURL: `https://api.telegram.org/bot${token}/`,
      limiter: {
        rps: 28, // 28 requests per second
        "429": (res) =>
          res.headers.get("retry_after") as unknown as number *
            1000 || 1000,
      },
      headers: {
        "Content-Type": "application/json",
      },
    });
  }

  async start() { // call before sending!!!
    this.queue = await Deno.openKv();
    this.queue.listenQueue(async (msg) => {
      // @ts-expect-error
      const { chat_id, text } = msg;

      try {
        const res = await this.tgApi.post("sendMessage", {
          timeout: 10000,
          body: JSON.stringify({ chat_id, text }),
        });

        console.log(
          `message delivered to ${chat_id}; ${res.status} ${res.statusText}`,
        );
      } catch (e) {
        console.log(`the message was not delivered to ${chat_id}`);
        console.log(e);
      }
    });
  }

  async notify(chat_id: number, text: string, delay?: number) {
    await this.queue.enqueue({ text, chat_id }, {
      delay,
    });
  }
}

That's all for them! Nothing more is needed. Now we can invoke the notify function, save messages to the queue, and send them to Telegram with delays and limits. Of course, this code can be broken with excessive load, but for most tasks, it'll do just fine :)

Conclusion

In the end, I managed to implement a fairly complex message distribution mechanism for Telegram, considering limits, making it resilient to crashes, and network issues. And all of this in just 55 lines of TypeScript code for Deno!

PS: I'd be happy if you subscribe to my channel IT NIGILIZM and join the russian-speaking deno runtime community ❤️!

🦖 My attempt to make an HTTP client...

Vsevolod — Fri, 29 Sep 2023 19:34:33 +0000

Earlier, I explained in two parts why all of this is needed: PART 1 и PART 2

✅ DENO RU COMMUNITY

fetchify

GitHub deno.land/x npm

This package is designed to make the process of interacting with various APIs
that have strict limitations more convenient and careful. For example, this
could be APIs like Notion or Telegram, which have stringent limits.

👋 👋 ATTENTION!

This package is under development and will be frequently updated. The author
would appreciate any help, advice, and pull requests! Thank you for your
understanding 😊

Import

Deno:

From deno.land/x:

import fetchify from "https://deno.land/x/fetchify@0.2.7/mod.ts";

Or esm.sh:

import fetchify from "https://esm.sh/gh/sevapp/fetchify@0.2.7/mod.ts";

Node.JS:

Install from npm:

npm i --save @sevapp/fetchify

And import:

import fetchify from "fetchify";

Usage:

The first thing available to you is the fetchify function

const json = await (await fetchify("https://catfact.ninja/fact")).json();
console.log(json);

This function has a similar interface to the classic fetch but extends it
with additional options, for example:

const json = await (await fetchify(
  "https://catfact.ninja/fact",
  {
    timeout: 1000, // Now, the waiting for a response will be interrupted after 1000 ms.
  },
)).json();

console.log(json);

But you can also create an instance with a set base URL and rate-limiting
constraints:

const jph = fetchify.create({
  limiter: {
    // Number of requests per second
    rps: 3,
    // You can handle the occurrence of a 429 error
    // and return the time in ms that the request loop should delay
    "429": (response) => 1000,
  },
  baseURL: "https://jsonplaceholder.typicode.com",
  headers: {
    "hello": "world",
  },
});

for (let i = 30; i--;) {
  console.log(`send ${i}`);
  // All basic methods supported: get post put delete head patch
  jph.get(`/posts/${i}`).then((data) => console.log(`${i} ${data.status}`))
    .catch((err) => console.log(`${i} ${err}`))
    .finally(() => {
    });
}

Yes, all methods comply with the fetch interface but also extend it with
additional options, for example:

await jph.get(`/posts/10`, {
  // Number of attempts
  attempts: 10
  // Time after which we stop waiting for a response
  timeout: 1000
});

If you need to make a request to the configured baseURL but not through the
request queue, you can add the flag:

await jph.get(`/posts/10`, { unlimited: true });

🦖 Gentle, promise-based HTTP client for Deno and Node.js (part 2)

Vsevolod — Wed, 27 Sep 2023 17:27:39 +0000

GitHub deno.land/x npm

✅ DENO RU COMMUNITY

PART 1 (please review the first part before reading this article <3)

Hello! It's Vsevolod again 😎 In the first part, I outlined the problem: when working with various APIs, we often encounter limits and restrictions that the standard fetch function cannot handle. During my contemplation, I arrived at a solution (source code), which involved creating a queue through which all fetch requests would pass at a certain interval. Yes, this resolves the problem described above, but it is highly inefficient...(

❤️ And please, support the project by starring it on GitHub or subscribing to my Telegram
channel IT NIGILIZM!
This motivates me to continue developing this topic, writing new articles, and improving this tool!

🫠 Mistakes analysis:

So, what's the plan? Let's tackle this! The solution from the first part is inefficient because we're making N requests at equal time intervals, waiting for each request to complete. Let's assume we need to make 3 requests per second, no more, right? Take a look at the code from the previous article:

while (true) {
  await delay(interval);
  const req = queue.shift();
  if (!req) continue;

  try {
    const response = await fetch(req.url);
    req.resolve(response);
  } catch (error) {
    req.resolve(error);
  }
}

What could go wrong? Let's calc:

1st request ~300ms +
2nd request ~200ms +
3rd request ~250ms +
interval 1000ms = 1750ms!!!

So, it means that it will take us a long time to complete the first three requests, and the next three requests will only start after 1750ms. But we wanted to make 3 requests per second. What can be done about this? The most obvious solution is not to send requests sequentially, waiting for responses, but to do it "in parallel".

✨ New Solution!

Alright, let's start by adding a few new fields to HTTPLimiter (hereinafter referred to as "Limiter"):

requestsPerIteration - This field will serve as a counter, keeping track of the number of requests sent during one "iteration."
iterationStartTime - This is the start time of the batch request sending process in milliseconds.
loopIsWorking - A flag indicating whether the loop is active (I want to stop the request processing loop if the queue becomes empty). In IHTTPLimiterOptions, let's add rps: number (requests per second) for configuring the Limiter's loop.

Additionally, we will make some changes to the fetch function so that it triggers the request processing loop as needed:

  fetch(input: FetchInput, init?: RequestInit): Promise<Response> {
    const promise = new Promise((resolve, reject) => {
      this.#queue.push({
        input,
        init,
        resolve,
        reject,
      });
    });

    // Now we don’t have to run the loop “manually”
    // and leave it running in the background forever
    if (!this.#loopIsWorking) {
      this.#loopIsWorking = !this.#loopIsWorking
      this.#loop();
    }

    return promise;
  }

Great, now let's move on to the breakdown of the new loop. First and foremost, we need to remember the time when we started the loop and began sending requests. This is important because now we will make an honest effort to accurately count the number of requests per second:

async #loop() {
    this.#iterationStartTime = new Date().getTime();

The first thing to do when entering the loop is to check the number of requests we have already made. If it exceeds the allowed limit per second, we skip the iteration:

    while (true) {
      if (this.#requestsPerIteration >= this.#options.rps) {
        await delay(this.#options.interval);
        continue;
      }

Unlike the previous implementation, now fetch is executed asynchronously compared to other fetches in the queue. We don't wait for a response to the previous request to send the next one; instead, we simply increment the counter and decrement it when a response arrives:

      const entity = this.#queue.shift();

      if (entity) {
        this.#requestsPerIteration++;
        fetch(entity.input, entity.init)
          .then((response) => {
            entity.resolve(response);
          })
          .catch((error) => {
            entity.reject(error);
          })
          .finally(() => {
            this.#requestsPerIteration--;
          });
      }

Next, I establish the termination rule for the loop, namely:
if the queue is empty, we don't expect any more responses to the sent requests:

      if (!entity && this.#requestsPerIteration == 0) {
        this.#loopIsWorking = !this.#loopIsWorking;
        return;
      }

🤢 Here's a small workaround that prevents the request processing loop from blocking, which would otherwise hinder the handling of other promises:

      if (!entity && this.#iterationStartTime > 0) {
        await delay(0);
      }

And the last part of the loop, controlling the intervals. If we hit the limit on the number of requests, we calculate the time we need to delay before starting the next iteration. It's not a perfect solution, but it works:

      if (this.#requestsPerIteration == this.#options.rps) {
        const timeOffset = this.#iterationStartTime + 1000 -
          new Date().getTime();
        await delay(timeOffset);
        // !!! there are no guarantees that sent requests will be executed after this delay
        this.#iterationStartTime = new Date().getTime();
      }
    }
  }

Certainly, this is not a perfect solution: it can lead to many problems (for example, if the requests themselves have a very long delay) and errors. But now the loop operates much more efficiently than the approach in the first part.

🫶 In conclusion and for the future...

Thank you very much for reading the second part of the article! You can find the entire code on GitHub, and I've also created a port for nodejs, which is now available on NPM (all links below). I hope to create a good alternative to great modules like ky or axios, taking into account the limits and requirements of various APIs. I'll certainly appreciate any suggestions or pull requests.

GitHub deno.land/x npm

🦖 APIs, fetch and Deno or how I make rate limiter (part 1)

Vsevolod — Mon, 25 Sep 2023 18:20:43 +0000

GitHub deno.land/x npm

✅ DENO RU COMMUNITY

PART 2

Hello, my name is Vsevolod! And you know what? I've grown very fond of Deno! And you know what else? I really love TypeScript! These two tools faithfully serve me on the challenging path of developing various integrations, automations, and all sorts of tools.

❤️ And please, support the project by starring it on GitHub or subscribing to my Telegram channel IT NIGILIZM!
This motivates me to continue developing this topic, writing new articles, and improving this tool!

Of course, during our work, we often have to interact with various APIs. For example, these could be the Telegram Bot API or the Notion API. Do you know what they have in common? Well, all these APIs come with certain rate limits. For instance, when using the Notion API, it's recommended not to exceed an average of 3 requests per second. But what do you do if your application generates far more requests than the limits of a specific API allow? What if the minimum time intervals between requests can vary dynamically?

💭 Let's explore:

The first thing that came to my mind is to create a queue of requests. The idea is simple: instead of using fetch, we push all our requests into a queue (which could be a regular Array). Then, in a loop, we gradually process these requests, calling our beloved fetch for each one and storing the received data somewhere. Of course, the request processing loop should adhere to the intervals between them according to the limits of the specific API. Isn't it beautiful? Let's look:

import { delay } from "https://deno.land/std@0.202.0/async/delay.ts";

interface IMyRequest {
  id: number;
  url: string;
}

let id = 0;
const queue: IMyRequest[] = [];
const responses: { [id: number]: Response | Error } = [];

const loop = async (interval: number) => {
  while (true) {
    await delay(interval);
    const req = queue.shift();
    if (!req) continue;

    try {
      const response = await fetch(req.url);
      responses[req.id] = response;
    } catch (error) {
      responses[req.id] = error;
    }
  }
};

const myFetch = (url: string): number => {
  id += 1;
  queue.push({
    id,
    url,
  });
  return id;
};

Excellent! Now we can create a single request or a series of requests to be executed sequentially with a 100ms interval. Yes, we'll have to wait for a while, and then retrieve the results from responses by their id:

loop(100);
myFetch(`https://jsonplaceholder.typicode.com/todos/1`);

Of course, tracking errors/responses in this example would not be very convenient. We could add a callback to IMyRequest that would be invoked after receiving the data. However, that would bring us back to callback hell))) But this code already partially solves this problem!

💡 Idea:

Yes, fetch is much more convenient. Why? Well, fetch returns a promise, and we can easily wait for it using either await or then (whichever you prefer). And I think it would be great to preserve this mechanism. In other words, we need a fetch that allows us to await a response but sends requests in accordance with the specified limits through a queue. What if myFetch returns a Promise that will resolve when the request reaches the queue and the data is returned or an error occurs? In that case, we can use async/await to wait for the data, even though the requests go through a queue. Let's give it a try:

import { delay } from "https://deno.land/std@0.202.0/async/delay.ts";

interface IMyRequest {
  url: string;
  resolve: (value: Response | Error) => void;
}

const queue: IMyRequest[] = [];

const myFetch = (url: string) => {
  const promise = new Promise((resolve) => {
    queue.push({
      url,
      resolve,
    });
  });

  return promise;
};

const loop = async (interval: number) => {
  while (true) {
    await delay(interval);
    const req = queue.shift();
    if (!req) continue;

    try {
      const response = await fetch(req.url);
      req.resolve(response);
    } catch (error) {
      req.resolve(error);
    }
  }
};

Amazing! Now we can create a large number of requests and await their responses using await or then:

loop(100);

for (let i = 100; i--;) {
  myFetch(`https://jsonplaceholder.typicode.com/todos/${i}`).then(
    async (response) => {
      if (response instanceof Error) {
        console.log(response);
      } else {
        console.log(await response.json());
      }
    },
  );
}

🏁 Final result:

Not bad already)
But that was just an example, not "production" code. Using it would be challenging because myFetch is far from perfect; it needs to be made similar to fetch.

Well, I decided to create a basic version and publish it as a separate package on deno.land/x. Try it out:

import fetchify from "https://deno.land/x/fetchify@0.0.2/mod.ts";

const limiter = new fetchify.HTTPLimiter({
  interval: 100,
});

for (let i = 10; i--;) {
  console.log(i);
  await limiter.fetch(
    `https://jsonplaceholder.typicode.com/todos/${i}`,
  );
}

🥰 Conclusion!

I hope that these thoughts will be helpful to someone. I understand that there may already be existing modules for Deno or Node.js that partially solve this problem, but I was interested in figuring it out on my own. And don't let my imperfect English deter you. Thank you for your attention!

GitHub deno.land/x npm