Forem: Petr Tcoi

How I Tried to Handle Customer Support in Telegram and Ended Up Building a Tool for It

Petr Tcoi — Thu, 26 Mar 2026 22:39:56 +0000

This didn’t start as a startup idea. I wasn’t trying to build a SaaS product. I just needed a simple way to handle customer support for my own projects without exposing my personal Telegram account or dealing with complex tools.

At first, Telegram felt perfect. Everyone already uses it, there’s no onboarding, no friction, no extra accounts. A client just sends a message and you reply. It’s fast, natural, and works out of the box.

And for a while, it really does work.

The problems don’t show up immediately. In the beginning, you have a few conversations per day, everything is manageable, and you can keep context in your head. Then you launch another project. Then another. Messages start coming in at different times, from different people, about different things.

You reply from your personal account, then maybe create a separate work account, then start forwarding messages to yourself or teammates. Over time, Telegram turns into a mix of personal chats, client conversations, and random forwarded messages. It becomes harder to understand what’s going on at any given moment.

The tricky part is that it doesn’t break in an obvious way. It slowly degrades. Responses get delayed, some messages are missed, sometimes two people reply to the same client, sometimes no one replies because everyone assumes someone else already did. Nothing critical, but enough to hurt the overall experience.

I tried a few workarounds. Multiple accounts, groups, pinned messages, manual labeling, forwarding flows. All of them help a bit, but none of them solve the core issue. Telegram is just a list of chats. There is no structure, no clear overview, no shared context.

Switching to a CRM or helpdesk didn’t feel right either. Not because those tools are bad, but because they’re often overkill for small teams or solo projects. You get dashboards, ticket statuses, workflows, onboarding, and another system you need to constantly keep open. Meanwhile, your actual communication still happens in Telegram, just routed through something else.

At some point it became clear that I didn’t need another tool. I needed a way to make Telegram itself more structured.

The idea ended up being very simple. Instead of clients messaging me directly, they message a bot. Every incoming message is forwarded into a private Telegram group where each client gets their own thread. One client, one thread. All history stays in one place, no forwarding, no confusion.

You reply directly inside that thread, and the bot sends the response back to the client.

Nothing fundamentally changes from the user’s perspective. It still feels like a normal Telegram chat. But internally, everything becomes structured. You can immediately see all active conversations, understand which ones need attention, and multiple people can work in parallel without stepping on each other.

Most importantly, your personal account is no longer part of the support flow at all.

I originally built this just to solve my own problem. But after using it for a while, I realized this pattern applies to a lot of people. Freelancers, small teams, indie projects, small businesses. Many of them rely on Telegram for communication, run into the same limitations, and don’t want to switch to heavy tools.

That’s how it turned into a small product.

If you're curious how this approach works in practice, I put together a simple explanation here:

👉 https://gramdeskbot.com

It’s not trying to replace a CRM or compete with full helpdesk platforms. It’s just adding a missing layer to Telegram so it can function as a lightweight support system.

And in practice, for small setups, that turned out to be a much better fit than anything more complex.

If you’re already using Telegram as your main communication channel, you’ll likely run into the same issues at some point. The question is whether you keep patching it manually or introduce a bit of structure on top of what you already use.

Monavo Architecture — Building a Telegram-First Solana Swap Service

Petr Tcoi — Thu, 12 Mar 2026 10:20:19 +0000

I recently launched the beta version of Monavo, a Telegram-first service for token swaps on the Solana network. The project is currently running in public testing, and the main goal of this stage is to observe how the architecture behaves in a real production environment. In this article, I want to explain the Monavo architecture, why the system is split between an edge API and a private backend service, and what engineering decisions help protect the system from duplicate requests, network issues, and unreliable external APIs.

When working with cryptocurrency transactions, infrastructure becomes just as important as the user interface. A duplicated request or network retry can potentially trigger the same operation twice. Because of that, the main focus during the development of Monavo was reliability. The system needed to remain predictable even when dealing with unstable networks, webhook retries, and third-party API limits.

Monavo was designed as a Telegram-first product. Telegram is responsible for authentication, notifications, and action triggers. The web application (/app) is used to confirm operations and display transaction details before they are executed.

🧩 Overall System Architecture

Monavo is implemented as a monorepo with clearly separated modules. This structure keeps business logic isolated from infrastructure and makes the project easier to evolve over time.

The system has several core components. A public API runs on Cloudflare Workers and receives all incoming requests. A separate backend service performs heavier operations and interacts with the Solana ecosystem. The web application acts as the user interface where transactions are reviewed and confirmed.

Shared data contracts and types live in a dedicated package, while the database schema and migrations are maintained in a separate module. This structure allows infrastructure or UI layers to evolve independently without affecting the domain logic.

⚡ Edge Architecture

One of the most important architectural decisions in Monavo was to adopt an edge-first design.

The public API runs entirely on Cloudflare Workers. Workers process Telegram webhooks, handle requests from the web app, manage user sessions, and apply rate limiting.

Workers effectively act as a gateway between users and the internal backend service. This approach ensures that the public interface remains fast while critical logic stays isolated from direct internet access.

Since Workers run on Cloudflare’s edge network across multiple regions, API responses remain fast regardless of where users are located.

🔐 Private Swap Engine

The heavy business logic is handled by a separate internal service, often referred to as the swap engine. This service prepares swap transactions and interacts with Solana infrastructure.

The backend server is not publicly accessible. It runs behind a Cloudflare Tunnel and accepts requests only from Workers.

This separation means the internal service is never exposed directly to the internet. Even if the public API is targeted by attacks, the core swap engine remains unreachable from outside the system.

Workers communicate with the backend using a service authorization key that is validated by the server. This creates a clear security boundary between the edge layer and the internal infrastructure.

🧠 API Contracts and DTOs

All data exchange within the system is built around DTO contracts. Every incoming and outgoing payload is validated at the API boundary.

These contracts are defined using Zod and serve as a shared source of types across all parts of the system. This ensures that every service interprets the same data structures consistently.

This approach significantly reduces the risk of runtime errors and makes the API easier to maintain as the project evolves.

🧯 Result-Based Error Handling Instead of Exceptions

Monavo follows an approach similar to functional languages such as Elixir or Rust. Instead of throwing exceptions, functions return structured result objects.

Each response includes an isFault flag that indicates whether an error occurred. If an error happens, the response also includes an error code and a message.

This approach prevents unexpected exceptions from interrupting execution flows. Clients always receive a predictable response structure and can safely handle errors.

Example responses look like this:

{
  "isFault": false,
  "data": {}
}

{
  "isFault": true,
  "code": "RATE_LIMIT",
  "message": "Too many requests"
}

🔁 Protection Against Duplicate Requests

One of the most common issues in distributed systems is duplicate requests. These may appear due to network retries, repeated HTTP requests, or duplicated webhook deliveries.

To address this, Monavo implements idempotency for command operations. Each request receives a unique key, and the system stores both the request hash and its result.

If the same request is received again, the previously stored response is returned. If the payload differs, the server returns a conflict error.

This mechanism ensures that operations cannot be accidentally executed multiple times.

🛡 Session Security

User authentication begins in Telegram. After authentication, the web application receives a one-time token used to establish a session.

This token has a limited lifetime and is stored in the database only as a hash. Once consumed, it becomes invalid.

The session itself is stored in a secure cookie with the following security attributes:

HttpOnly
SameSite
Secure (in production)

Session tokens are also periodically rotated, which reduces the risk of token compromise.

⚙️ Reliability of External Integrations

Monavo interacts with several external services, including Solana infrastructure providers.

To prevent API overload and accidental blocking, these integrations are wrapped in request rate limiters. Additional caching and periodic updates are used to reduce external load and improve system responsiveness.

This combination ensures that the system remains stable even when external services behave unpredictably.

📦 Deployment

Workers are deployed using GitHub Actions. Whenever code changes are pushed, the deployment pipeline automatically updates the Cloudflare Workers environment.

Deployment uses configuration options that prevent accidental overwriting of runtime secrets and environment variables.

The internal backend service runs on a VPS and is managed with PM2. This setup allows fast updates and provides a simple mechanism for monitoring and restarting the service if necessary.

⚠️ Problems and Lessons Learned

Despite the planned architecture, several issues appeared during early testing of Monavo.

The first problem involved Telegram webhooks. Initially the system did not use idempotency. In practice, Telegram sometimes delivers the same event multiple times, especially during network delays or webhook retries.

This occasionally caused the same operation to run twice. The solution was to introduce idempotency keys and payload hashing so duplicate requests return the original result.

Another issue appeared after moving the entire API to Cloudflare Workers. Workers are excellent for fast API operations, but they are not ideal for long-running or computationally heavy tasks.

Some swap flows required longer execution times than edge functions comfortably support. As a result, the architecture was adjusted so Workers act as a gateway while heavy operations run on a dedicated backend service.

A third challenge appeared when interacting with Solana RPC nodes. Everything seemed stable during testing, but higher request volumes led to rate limit errors and inconsistent responses.

This required adding request limiters, caching layers, and controlled request queues for RPC calls.

Another important lesson came from error handling. Early versions of the system relied heavily on exceptions. Over time this created complex try/catch chains and unpredictable API responses.

Eventually the system was refactored to the result-based approach described earlier. This change made error handling much more predictable and simplified client-side logic.

🧭 Why Monavo Uses This Architecture

The core idea behind the Monavo architecture is to separate the system into two layers.

The edge layer handles user interaction and must remain extremely fast. The core layer executes critical business logic and stays isolated from direct public access.

This approach reduces the attack surface, simplifies scaling, and makes the system more resilient to network instability.

🧪 What Comes Next

Monavo is currently running in beta. The primary goal of this stage is to observe how the architecture performs under real-world conditions and identify potential bottlenecks as the user base grows.

If the system proves stable under production traffic, the next step will be expanding the platform with additional tools for interacting with the Solana ecosystem.

The beta version is already live and gradually opening to more users, so the coming months will provide a good test of how well the current architecture performs in practice.

How I Stopped Checking amoCRM Every Morning and Built a Telegram Bot Instead

Petr Tcoi — Fri, 06 Feb 2026 12:50:10 +0000

I use amoCRM every day as a small business owner. We do not have a large sales department or a complex hierarchy, but we still rely on pipelines, deals, and tasks. Very quickly I noticed that a significant part of my time was spent not on decision-making, but on repetitive manual checks inside the CRM.

Every morning looked almost the same. Open pipelines. Check if there are any unassigned leads. See whether active deals have tasks. Look for overdue tasks where nothing has happened for a while. None of this is difficult, but it is routine. And when you skip it or postpone it, the problem usually surfaces later, when the lead is already cold or the opportunity is lost.

At some point, it became obvious that automating these checks was easier than forcing myself to repeat them manually every day.

That is how LeadsAlarm started.

The project is already live: https://leadsalarm.ru/

Using it is intentionally simple. You just message the Telegram bot at https://t.me/LeadsAlarmBot go through the official amoCRM OAuth flow, select pipelines, and that is it. The service runs in the background and sends notifications when something in your deals requires attention.

Why Alerts Instead of Reports

CRM reports and analytics are useful, but they solve a different problem. They are great for weekly or monthly reviews.

In daily operations, what matters more is not an overview but a timely signal. I did not want to constantly open the CRM UI, filter deals, and manually check timestamps. I wanted the system to tell me when something went wrong.

That is why alerts turned out to be the most convenient format.

Why Telegram

The answer is simple. Telegram is always open.

A separate dashboard is just another place you need to remember to visit. A message in a messenger appears exactly where attention already is and does not turn monitoring into a separate task.

The bot does not spam. It sends short, contextual messages only when it makes sense. If everything is fine, it stays silent.

What the Signals Look Like

When an actual issue appears, the bot sends a clear and focused signal. No long tables, no excessive details.

For example, if a deal has an overdue task, the message contains the pipeline name and deal ID. This is enough to decide whether you need to react immediately or can look at it later.

For unassigned leads, the logic is slightly different. The bot does not notify on every new lead. It waits for a configured time window and sends an aggregated alert only if the problem persists. This significantly reduces noise.

Data Safety by Design

From the beginning, I decided that the service should not work with deal contents.

LeadsAlarm uses only metadata: deal and task statuses, pipeline stages, timestamps, and responsible users. Contacts, notes, comments, and message texts are neither fetched nor stored.

This was a conscious design choice. It minimizes data leakage risks simply by excluding sensitive data from storage. It also keeps the architecture simpler and more predictable. On top of that, full deal content would generate too much data for a stable and economically reasonable analysis, especially within a low-cost subscription model.

Why No Working Hours or Calendars

Initially, I considered building checks around schedules: business hours, weekends, holidays, vacations.

Very quickly it became clear that this approach adds complexity while still producing false positives. Every team works differently, and there is no universal calendar that fits everyone.

Instead, I switched to a simpler activity-based model. The system does not care about days of the week or hours. It only looks at facts: whether there were any events related to a deal within a given time window.

If there was activity, it is considered working time.

This approach has limitations. If a manager has zero activity during the day, a signal might not trigger. In practice, such cases are rare, and if there is no activity at all, the problem is usually obvious even without automated alerts.

Tech Stack and Architecture Choices

I also used this project as an opportunity to work with PHP more intentionally. Before that, my experience with PHP was mostly limited to WordPress projects. Here, I wanted to take a popular and modern framework and go through the full cycle from idea to production.

I chose Laravel 12, which at the time was the latest and most up-to-date release. It turned out to be a good fit for this type of service. Clear structure, built-in queues, solid database tooling. Everything needed for a small SaaS is already there.

Development felt a bit slower compared to my usual Node.js stack, but that was expected and not a real issue. Predictability and ease of maintenance were more important. Over time, I expect this choice to pay off.

On the frontend side, I deliberately avoided complexity. The service has only a few public pages whose purpose is to explain what the tool does and how it works. I implemented them as simple static HTML pages without introducing a separate frontend stack. This allowed me to focus entirely on core logic and notifications.

A Production Issue I Did Not Expect

One interesting problem appeared after the system was already running.

At some point, I noticed that background workers occasionally stopped processing jobs, while the jobs themselves were still marked as successfully completed. From the outside, everything looked fine, but in reality some checks were silently skipped.

It took some time to understand what was happening, review logs, and adjust how workers were supervised and restarted. This was not a Laravel-specific issue. Similar problems can happen in Node.js systems as well. It was a good reminder that background processing in production needs proper monitoring and defensive design, regardless of the stack.

AI and Future Direction

At the moment, LeadsAlarm checks only basic situations that I previously monitored manually. The service has a free tier and a paid tier, which I continue to extend gradually.

In parallel, I am already experimenting with AI-based analysis to reduce noise and highlight deals that deserve attention first. This is not about surveillance or employee control. The goal is to build a prioritization assistant, not a judge.

I do not expect AI to be 100 percent accurate. Its role is to help focus attention, not to make decisions.

I also plan to port the service to Kommo CRM, which has a very similar API to amoCRM. This should make the transition mostly architectural rather than conceptual.

Conclusion

For me, this project started as a way to remove routine from daily CRM usage and focus on things that actually matter. If you use amoCRM and find yourself repeatedly checking the same things manually, this alert-based approach might be useful for you as well.

Project: https://leadsalarm.ru/
Telegram bot: https://t.me/LeadsAlarmBot

When You Should “Wet” Your Code: Why Blindly Following DRY Can Hurt Your Project

Petr Tcoi — Wed, 12 Nov 2025 09:06:15 +0000

The DRY principle (Don’t Repeat Yourself) is probably one of the first rules we learn as developers. Its idea seems flawless: don’t repeat code, don’t duplicate knowledge, and move everything that repeats into a single place.

In practice, this means that if a piece of logic appears in multiple places, it should be centralized - as a function, class, module, or component.

This makes the project cleaner, easier to maintain, and safer to modify. Fix a bug in one place - and it disappears everywhere.

In business logic, especially on the backend, DRY works beautifully. Data validation, discount calculations, and authorization rules are perfect examples of knowledge that must be centralized. When such logic is scattered across different services, inconsistencies and bugs are inevitable. In these cases, DRY can literally save months of work, make the system predictable, and simplify refactoring.

But my personal experience - and I mostly work with startups and fast-changing frontend projects — has shown that this principle, when applied dogmatically, can do real damage. When requirements change every week and design lives its own life, strict DRY often becomes a development bottleneck rather than a path to clean code. The more “mature” a project becomes, the “drier” it can be. But in the early stages, too much dryness can be fatal.

DRY in Theory: The Original Idea and Its Strengths

DRY wasn’t created as a fight against repeating code just for aesthetics - it was a fight against repeating knowledge. The authors of the principle, Andrew Hunt and David Thomas, explained in The Pragmatic Programmer that if the same business rule appears in multiple places, it’s a sign of an architectural flaw.

The core idea is simple:

Every piece of knowledge should exist in one and only one place.
Changing that knowledge should require changing only one fragment of code.

This ensures consistency, reduces the risk of bugs, and simplifies testing. DRY makes code stable and transparent when it comes to recurring data structures, formulas, business rules, calculations, or constants.

Where DRY Really Works

Everything related to backend logic is where DRY shines. For example:

shared database access functions
centralized error handling
unified pricing and discount calculation rules
recurring data models and validation

In these areas, duplicating logic leads to divergence and unpredictable behavior. Here, DRY doesn’t just save lines of code — it preserves the integrity of the system’s meaning.

When DRY Turns Into a Trap

The Risk of Over-Abstraction and Poor Readability

The biggest mistake is applying DRY automatically without context.

The desire to “combine everything” often creates monstrous abstractions.

Developers merge similar chunks of code and end up with a giant function full of conditions, flags, and optional parameters that tries to do everything — but no one remembers exactly what.

Such “universal” modules become black boxes: hard to modify, painful to debug, and confusing to newcomers.

Once, I worked on a project where I just needed to change the color of a button on one page. But the button component was so “dried up” — with factories, dozens of props, and global styles — that it took me four hours to make a tiny change. Ironically, there were only about ten buttons in the entire interface. That was a textbook example of how blind DRY can turn simplicity into chaos.

Tight Coupling and Fragile Design

When everything depends on one shared module, every small change becomes a minefield. You fix something for one page — and something breaks elsewhere. This creates tight coupling, where independent parts of the system become hostages of shared logic.

Ironically, the famous DRY argument “fix it once, fix it everywhere” works in reverse: introduce a bug once — and it spreads everywhere. The result is a fragile, rigid system where touching one line can cause a chain reaction.

Premature Abstraction – the Enemy of Flexibility

DRY was never meant to eliminate every visual repetition — only repetition of knowledge. But developers often merge pieces that are only visually similar, not conceptually identical. At first, it feels smart: “Why write this twice?”. Then you realize these pieces evolve differently, and the abstraction becomes a burden.

In startups, I see this all the time. Requirements change weekly, designs daily. Premature abstraction slows everything down — you keep adding exceptions, flags, and branching logic just to preserve a “shared” structure.

It’s often far easier to duplicate a small piece of code, let it evolve independently, and only later refactor it once the functionality stabilizes. This follows the “Rule of Three”: if you write the same thing three times, that’s the moment to abstract.

Architectural Traps and the “Distributed Monolith”

In microservice architectures, DRY can be downright dangerous.

Developers create shared libraries “to avoid duplication,” but in reality, they end up with a distributed monolith — a system where all services depend on one shared core.

Now you can’t deploy anything independently; every minor update risks breaking multiple components. Over time, those shared “commons” libraries turn into dumping grounds for everything no one dares to delete. Instead of elegance, DRY breeds technical debt.

Frontend teams are especially vulnerable: shared “UI utility” libraries quickly become bloated, outdated, and terrifying to touch. Everything looks dry, but nobody understands how it works anymore.

When DRY Conflicts With Common Sense

In the real world, systems are rarely symmetrical or stable.

In frontend projects especially, “universal components” often become nightmares: a single mega-component for buttons, taking ten props and supporting countless variants — until someone clones it anyway to make “a rounded one with a gradient hover.”

When the designer suddenly wants three shapes of buttons, forty color shades, and unique hover states, the DRY dream collapses. Sometimes it’s far better to have three separate, simple components than one monstrous one.

In young, evolving projects, universal abstractions don’t speed things up — they create inertia. When the priority is speed, iteration, and experimentation, duplication is often cheaper and safer.

When It’s Better to “Wet” Your Code

Sometimes, duplication is an intentional, pragmatic decision.

If similar pieces of code serve different purposes, evolve at different paces, or belong to different contexts — keep them separate. This mindset even has a name: WET — Write Everything Twice.

It’s not an argument for chaos — it’s an acknowledgment that duplication is often cheaper than the wrong abstraction. This is especially true in frontend development and young products, where requirements change faster than architecture can stabilize.

In business logic and backend development, DRY still shines — for calculations, validation, and data access layers. But in user interfaces and early-stage products, pragmatism must win over dogma.

Conclusion

DRY is an excellent principle — when used consciously. It keeps systems consistent and maintainable. But when treated like a religion, it becomes a source of rigidity and pain.

In frontend development and fast-moving projects, dogmatic DRY causes more harm than good. The faster your product evolves, the more important flexibility, independence, and clarity become.

Let the code repeat a little — as long as it stays readable, local, and easy to change. After all, programming isn’t about eliminating repetition — it’s about balancing clarity, speed, and common sense.

Example of caching Google Translate translation results for a multilingual site on NextJS

Petr Tcoi — Wed, 21 May 2025 21:08:28 +0000

I am sharing my experience organizing the translation of content into different languages. I work on a multilingual website using the Next.js i18n + MongoDB (Mongoose) stack. The site contains a significant amount of text that is occasionally updated.

Google Translate is used to translate the texts in the project. Initially, a simple function was created to translate the view.

// @/lib/translate.ts

import "server-only";
import { z } from "zod";

const { Translate } = require("@google-cloud/translate").v2;

const ApiKey = z.string().parse(process.env.GOOGLE_TRANSLATION_API_KEY);
const googleTranslate = new Translate({ key: ApiKey });

export async function translateFromEn(text: string, locale: string): Promise<string | null> {
  try {
    if (locale === 'en') return text.trim(); 
    const translations = await googleTranslate.translate(text, locale);
    const result = translations[0];
    return result;
  } catch (error) {
    return null;
  }
}

Then it was used everywhere when preparing pages. To avoid translating the same texts repeatedly, I used the "unstable_cache" function (despite its name, I've never had any problems with it).

// .../page.tsx

type Params = { locale: string };

export default async function Page({ params }: { params: Params }) {
  const {  locale } = params;

  ...

  const translatedTitle = await unstable_cache(
      async () => await translateFromRu(post.title, locale),
      [`post:title:${post.slug}:${locale}`],
      { revalidate: false, tags: [`post:${post.slug}`] },
  )();

  const translatedShortDescription = await unstable_cache(
      async () => await translateFromRu(post.metaCustom.shortdescription, locale),
      [`post:shortDescription:${post.slug}:${locale}`],
      { revalidate: false, tags: [`post:${post.slug}`] },
   )();


    return {
      ...
    }

  }

Accordingly, whenever the blog post was updated, the revalidateTag() method was called and the translations were updated.

While this was a working solution, the cache was reset every time the site was updated, which was a flaw. Consequently, this risked a large bill from Google.

Therefore, I added a feature that stores the translation results in the Mongo database. The idea is as follows:

Create a unique ID for each translation entity.
Before accessing the Google API, we check the database to see if there is a record with this ID and if it matches the text to be translated.
If so, we return the record from the database.
If not, we request a translation via the API, return the result, and save it in the database.

I use hashing for simple text matching. With the new logic, the translateFromEn function looks like this:

import "server-only";

import crypto from "crypto";
import { z } from "zod";
import { TranslateResult, zTranslateResult } from "../mongoModels";
const { Translate } = require("@google-cloud/translate").v2;

const ApiKey = z.string().parse(process.env.GOOGLE_TRANSLATION_API_KEY);
const googleTranslate = new Translate({ key: ApiKey });

// -------------------------------------------------------------------

type GetTranslationKeyProps = {
  locale: string; // en, ko, ch...
  entity: string; // user, post, comment
  entityType: string; // shortDescription, metaTitle
  entityId: string; // slug, _id ...
};
function getTranslationKey(props: GetTranslationKeyProps) {
  const { locale, entity, entityType, entityId } = props;
  return `${locale}-${entity}-${entityType}-${entityId}`;
}

// --------------------------------------------------------------------
// 1. If locale === 'en' - just return text
// 2. Generate Key and Check if translation exists in DB
// 3. Generate hash from text
// 4. If old Db Translation exist and hash is the same - return translation
// 5. If hash is different or hash not the save - create new translation
// 6. Return translation
// --------------------------------------------------------------------

export async function translateFromEn(
  text: string,
  idData: GetTranslationKeyProps,
): Promise<string | null> {
  try {
    // 1. If locale === 'en' - just return text
    if (idData.locale === "en" || text.trim().length === 0) {
      return text.trim();
    }

    // 2. Generate Key and Check if translation exists in DB
    const key = getTranslationKey(idData);
    const oldTranslateDoc = await TranslateResult.findOne({
      key,
    }).lean();

    // 3. Generate hash from text
    const textHash = crypto.createHash("SHA-256").update(text).digest("hex");

    // 4. If old Db Translation exist and hash is the same - return translation
    if (oldTranslateDoc && oldTranslateDoc.hash === textHash) {
      return oldTranslateDoc.translation.trim();
    }

    // 5. If hash is different or hash not the save - create new translation
    const translations = await googleTranslate.translate(text.trim(), idData.locale);
    const translateResult = translations[0];

    const newTranslationResult = zTranslateResult.parse({
      key,
      hash: textHash,
      translation: translateResult,
    });

    await TranslateResult.findOneAndUpdate({ key }, newTranslationResult, {
      upsert: true,
    });

    // 6. Return translation
    return translateResult;

    // ---
  } catch (error) {
    return null;
  }
}

This allowed us to significantly reduce the number of calls to the Google Translate API and stay within budget.

My stack for online store on NextJS

Petr Tcoi — Mon, 16 Sep 2024 07:25:53 +0000

I recently finished another online store for heating equipment. I would like to share the technology stack I used for it.

Website: https://radiatorlux.ru
Github

At the time of its launch, the store had about 19,000 products grouped by models and collections. In the future, it is planned to expand the assortment to 40-50 thousand products.

Framework and database

The basis of the project is NextJS framework and MongoDB database (I used Mongoose to work with it). The latter was chosen mainly because of its flexibility (there are many specific characteristics for different models of radiators) and the availability of an excellent application MongoDB Compass, which allows you to fill and update the database via CSV import (the database of goods is initially stored in Google Sheets).

Communication between documents and collections is done via the slug text field instead of _id. This approach makes updating and transferring data much easier. For example, if products and models are not successfully populated into the database, they can simply be deleted and re-populated by importing a CSV file without worrying about preserving the links between entities.

The same approach works well with SQL databases.

Database query caching

I had some concerns about how unstable_cache would work with mongoose, but so far the caching is working as expected. Since the data on the site is rarely updated, the caching time is set to 12 hours.

A typical request might look like this

const line = (await unstable_cache(
  async () => await Line.findOne({ slug: lineSlug }).lean(),       
  ["cache:line", lineSlug], 
  {revalidate: 60 * 60 * 12 )()
) as TLine | null;

Wordpress as CMS

WordPress is used here as a CMS. This greatly simplifies the work of managing page content. To identify the needed content, the values of the slug field are used for the corresponding entities.
For example, the description for the collection "Cube" is located at page-content-line-cube. The exact configuration of WP for use as a CMS I have seen in this video.

Unfortunately, I couldn't use WP's built-in meta tags, so I used the Advanced Custom Fields plugin, which allows you to create custom fields for pages and records.

Image Component and CDN

CDNNow is used to deliver product images.

Customization is easy, just specify in the image component the required image sizes based on the window size and the component itself will pass the appropriate width to the loader function:

<Image
  loader={({ src, width }) =>`${CdnUrl}/${src}?width=${width}`}
  src={img.src}alt={img.alt}
  sizes="(max-width: 768px) 50vw, (max-width: 1280px) 33vw, 25vw"
/>

CdnUrl' - the address the server provides when registering your site.

UI

The visuals are generated by tailwindcss and shadcn. This is my default for most projects. Although with the last library and occasionally there are difficulties. For example, in this project, the Drawer component was responsible for displaying variants of paint and radiator connections and did not work correctly on mobile phones. So it had to be replaced by a similar component called Sheet.

My experiment with HTMX and Astro

Petr Tcoi — Thu, 20 Jun 2024 16:44:25 +0000

I share my first experience with the htmx library. I created a simple site (https://tubog-showcase.ru) consisting of a home page with an initial set of apartment cards and 5 buttons that display apartments filtered by number of rooms.

Stack: Astro + HTMX + Tailwind

Implementation is very simple:

// src/pages/index.astro

<form
  id='filter-form'
  hx-trigger='change'
  hx-post='/api/cases'
  hx-target='#serch-results'
  hx-swap='innerHTML'
  hx-indicator='#loading'
>
    ...
    <label>
      <input
    type='radio'
    name='rooms'
    value='1'
        class='hidden peer'
      />
      <div class='hover:border-slate-500 peer-checked:opacity-100 peer-checked:shadow-xl peer-checked:border-slate-400'>
    1 комната
      </div>
   </label>

    ...
</form>

<div id='loading'>
  Loading...
</div>

<div id='serch-results'></div>

Соответственно, при выборе нового варианта фильтра, по адресу /api/cases выполняется POST-запрос с данными о выбранном варианте.

Индикатором рабты запроса является <div id='loading'>. Результат (готовый HTML) выводится внутри <div id='serch-results'></div>.
На стороне api код выглядит примерно так:

// src/pages/api/cases.ts

export const POST: APIRoute = async ({ request }) => {

   const formData = await request.formData()
   const rooms = formData.get('rooms')

   // Получаем список комнат на основе rooms

   return new Response(
     `
      <div>
         ${filteredFlats.map(flat => ` {some flat html here} `)}
      </div> 
     `,
     {
        status: 200,
    headers: {
       'Content-Type': 'text/html+htmx',
    },
      }
   )

And that's it.

First Impressions

This approach to create web applications is rather not for me. Implementing with the same React seems simpler and with more potential for improvement. What I didn't like:

The blurring of application logic. The backend doesn't just return data, but also deals with frontend tasks;
The need to harmonize the layout on the client side and the server side (in our case it's the default display of maps and search results output).

Yes, I made it a bit more difficult for myself by not using page partials, but their use within the same Astro in conjunction with HTMX seemed a bit too far-fetched to me.

Still, I have a number of tasks where HTMX is a perfect fit: I have several old static sites and sites implemented on CMS like WordPress. For these, the will to add interactivity (especially using page partials) is a great prospect. For sites written in Next or Astro, I haven't seen a use for it yet.

P.S. An unexpected problem

In this project I've connected View Transitions and it seems to break the HTMX library. As soon as you make a transition between pages, the site ends up static. Fortunately, I came across this article which describes the solution: you need to add the following script to the page with HTXM code.

// src/pages/index.astro

<script>
  document.addEventListener('astro:page-load', () => {
    const contentElement = document.getElementById('filter-form')
    if (contentElement) { 
      htmx.process(document.body)
    }
  })
</script>

A small example of how to use the satisfies operator in TypeScript

Petr Tcoi — Fri, 15 Mar 2024 15:23:43 +0000

The satisfies operator tells TS what type of variable we expect, without overriding its own type. In some cases, this feature can be very useful. Let's look at a simple example where this operator can be useful.

We have a list of products listA and we need to prepare an object whose keys would be arbitrary strings and whose values would be any of the items in the list.

const listA = ['apples', 'oranges', 'peaches'] as const;

type ListA = (typeof listA)[number]; // "apples" | "oranges" | "peaches"

const listMap1: Record<string, ListA> = {
  a: 'apples',
  b: 'oranges',
  c: 'peaches',
  d: 'apples',
};

If we try to specify a value that is not in the list, for example carrot, we get a warning, which was necessary.

Now we need to infer the type of the keys contained in the listMap1 object. And here we have a problem, because at the very beginning we defined its type as Record<string, ListA>. This means that the key is an arbitrary string:

type Key1 = keyof typeof listMap1;

const keyOne: Key1 = 'Y';  // const keyOne: string

We don't get an error, although we should. This is where the satisfies operator comes in handy, telling TS that we don't define the type of the variable, but just expect the keys to be strings and the values to be something from the fruit list.

const listMap2 = {
  a: 'apples',
  b: 'oranges',
  c: 'peaches',
  d: 'apples',
} satisfies Record<string, ListA>;

In this case, the above code will work as it should:

type Key2 = keyof typeof listMap2;

const keyTwo: Key2 = 'Y'; // const keyTwo: "a" | "b" | "c" | "d"

we get the error Type '"Y"' is not assignable to type '"a" | "b" | "c" | "d", which is what we needed.

NextJS API + React Query + Zod = type safety

Petr Tcoi — Wed, 06 Sep 2023 15:49:05 +0000

One of the advantages of Next.js is the ability to combine frontend and backend within a single project and use shared types and interfaces. Unfortunately, the server-side part of the framework operates independently from the frontend, functioning as a largely standalone application. Therefore, ensuring type safety requires additional effort. In this article, I will share my experience in addressing this issue.

Folders

For each entity, a separate folder is created in which all methods related to it are defined.

│
├── database
│   ├── items
│   │   ├── api
│   │   │   ├── get-item-by-id
│   │   │   │   ├── getItemByIdClient.ts
│   │   │   │   ├── getItemByIdServer.ts
│   │   │   │   ├── config.ts
│   │   │   │   └── index.ts
│   │   │   └── index.ts
│   │   ├── lib
│   │   │   ├── getItemById.ts
│   │   │   └── index.ts
│   │   ├── hooks
│   │   │   ├── use-get-item-by-id
│   │   │   │   ├── queryKey.ts
│   │   │   │   ├── useGetItemById.ts
│   │   │   │   └── index.ts
│   │   │   └── index.ts
│   │   ├── items.types.ts
│   │   └── index.ts
│   └── index.ts

Let's go through these levels, starting from the base.

items.types.ts

Main File. This is where types related to the entity are defined: how they are stored in the database, how data is retrieved from the database, and the required fields for creation or editing.

To define the structure, Zod is used. In my last project, I used Strapi, so it looked something like this:

// How data is stored in the database
export type DbItem = z.infer<typeof zDbItem>;
export const zDbItem = z.object({
    id: z.number().int().positive(),
    name: z.string().nonempty({ message: "City name cannot be empty" }),
    sku: z.string().optional().or(z.null()),
    description: z.string().optional().or(z.null()),
});

// How data is returned from the database when queried
export type DbItemQuery = z.infer<typeof zDbItemQuery>;
export const zDbItemQuery = zDbItem.pick({ id: true }).merge(
    z.object({
        attributes: zDbItem.omit({ id: true, ...omitDates })
        })
);

// If needed, you can also define an object here for populating the response
export const itemQueryPopulate = {
    brand: { fields: ["id", "name"] },
    manufacturer: { fields: ["id", "name", "rating"] },   
}

/lib - Database Interaction

This folder contains all the methods that will be used in the code. It is the only place where direct database interaction occurs.

In the method files, zod schemas and expected responses are defined. For example:

// .../lib/getItemById.ts

export type GetProps = z.infer<typeof zGetProps>;
export const zGetProps = z.object({
    id: z.coerce.number().int().positive(),
});

export type GetResult = z.infer<typeof zGetResult>;
export const zGetResult = zDbItemQuery;

export const getProductById = async ({ id }: GetProps): Promise<GetResult> => {
try {
        const query = await strapiSdk.findOne<DbItemQuery>(dbTables.items, id, {
            populate: itemQueryPopulate,
        });

        if (!query) {
            return fault({ code: ErrCode.CantFindError });
        }
        const { data } = z.object({ data: zDbItemQuery }).parse(query);

        return success(data);

        //catch
    } catch (error) {
        if (error instanceof ZodError) {
            return fault({ code: ErrCode.DbReturnWrongFormat });
        }
        return fault({ code: ErrCode.SomeError });
    }

}

Now we have isolated methods in a separate folder for working with the database. If something changes in its logic or if you need to optimize a specific query, you can do it right here while preserving the argument and response types.

/api - Bridging Frontend and Backend

Functions in this folder are responsible for executing the application's business logic. Each feature is isolated in a separate folder and contains both a function that will be called on the frontend side (getItemByIdClient) and a function that will perform work on the server (getItemByIdServer).

api
 ├── get-item-by-id
       ├── getItemByIdClient.ts
       ├── getItemByIdServer.ts
       ├── config.ts
       └── index.ts

The main file here is config.ts, which contains information about the types and interfaces used by the functions, as well as the path to the API route that will be called from the frontend.

// .../api/get-item-by-id/config.ts

import { z } from "zod";
import { paths } from "configs";

import { zGetResult, zGetProps } from "../../lib/getItemById";

// path
export const PATH = paths.api.items.root;

// type Props
export type TPropsServer = z.infer<typeof zPropsServer>;
export const zPropsServer = zGetProps;

export type TPropsClient = z.infer<typeof zPropsClient>;
export const zPropsClient = zPropsServer;

export type TResult = z.infer<typeof zGetResult>;

Essentially, this is a set of re-exports needed to simplify code organization.

In this example, the arguments for both Client and Server are the same, but they can differ if, for instance, the Server function requires additional user ID obtained from cookies in the route.ts file and passed to the getItemByIdServer function.

Yes, the necessary code is located in another folder. Currently, this is the way it needs to be organized. When Server Actions are no longer experimental, you can eliminate this step. Additionally, I haven't tried the ts-rest library, which is aimed at solving a similar problem.

The file looks something like this:

// app/api/items/[id]/route.ts

export async function GET(req: NextRequest) {
    const { pathname } = new URL(req.url);
    const id = pathname
        .split("/")
        .filter(part => part !== "")
        .at(-1);

    const result = await getItemByIdServer({ id });

    return NextResponse.json(result, { status: result.statusCode });
}

The getItemByIdServer function not only returns a response but also an HTTP status code:

// getItemByIdServer.ts

export default async function getItemByIdServer(props: TPropsServer): Promise<TResult> {
    const checkProps = zQueryProps.safeParse(props);

    if (!checkProps.success) {
        return({ code: "WrongData", message: checkProps.error }, HttpStatusCode.BadRequest);
    }

        const { data } = checkProps

    try {
        const result = await getCompanyById(data);
        if (isSuccess(result)) {
            return (result.payload, HttpStatusCode.Ok);
        }

        return ({ code: result.payload.code }, HttpStatusCode.BadRequest);

    } catch (e) {
        return({ code: ErrCode.UnknownError, message: "Неизвестная ошибка" }, HttpStatusCode.InternalServerError);
    }
}

Here, instead of returning a regular error code, we throw an error because the function will be used in the useQuery hook from ReactQuery.

Both the server-side and client-side validate the received data using Zod.

/hooks - Adding ReactQuery

Hooks are placed in separate folders.

│   │   ├── hooks
│   │   │   ├── use-get-item-by-id
│   │   │   │   ├── queryKey.ts
│   │   │   │   ├── useGetItemById.ts
│   │   │   │   └── index.ts

In the queryKey file, you simply define and export the key that will be used for this hook. It can be used in other parts of the application, for example, if you need to perform an invalidate operation for the query.

// .../queryKey.ts

export const QUERY_KEY = "item-get-by-id";

The hook itself is simple - it only calls a previously created function for the frontend part:

import { useQuery } from "@tanstack/react-query";
import { GetItemByIdPropsClient, getItemByIdClient } from "shared/database";
import { QUERY_KEY } from "./queryKey";

export type UseGetItemProps = GetItemByIdPropsClient;

export const useGetItemById = ({ id }: UseGetItemProps) => {
    const queryKey = [QUERY_KEY, id];

    return useQuery(queryKey, () => getItemByIdClient({ id }), {
        suspense: true,
    });
};

...and all of this is exported in the index.ts file:

// index.ts

export { QUERY_KEY as QUERY_KEY_GET_ITEM } from "./queryKey";
export { useGetItemById } from "./useGetItemById";

Now, in your component, you can simply call the hook to retrieve the necessary data:

const { data: item } = useGetItemById({ id })

Conclusion

In the example provided, it may seem like an excessive separation of a simple query into so many parts. However, this approach allows you to organize your code into isolated and reusable components, each focused on handling a specific level of abstraction.

As a result, understanding the code and conducting refactoring becomes easier, as it is immediately clear which types of tasks are being solved where. This modular structure also promotes code maintainability and scalability, making it easier to work on and extend the application over time.

My experience with FSD (Feature-Sliced Design) architecture.

Petr Tcoi — Mon, 03 Jul 2023 07:45:08 +0000

In this article, I want to share my experience of developing applications using the FSD (Feature-Sliced Design) approach. I won't go into detail about it here, as plenty of good resources are already available, primarily the official website.

I found this approach to be very convenient. It not only applies well to new projects that can be structured appropriately from the start but also to projects that someone else had previously worked on and left in a tangled state. By following simple rules step by step, it is possible to organize and make any codebase convenient for further development. This article will focus on these simple rules, which I couldn't find and had to develop through my own experience. I hope my experience will be useful to others.

The basic idea

The entire code is divided into layers:

app - the top-level of the application;
pages - individual pages or screens of the application;
widgets - interface blocks that make up a page. For example, a top menu, a shopping cart, etc. Ideally, a page should be as "thin" as possible and primarily consist of widgets, each of which operates independently of others;
features - a business feature that provides value to the user. For example, adding and removing items from a shopping cart, calculating the total amount and discounts;
entities - simplified, these are the project's data entities: products, users, blog posts, etc.;
shared - resources used by all other layers within the application. This can include utilities, interfaces, and configurations for third-party services (database connections, Twilio CLI, etc.).

Each element is self-contained and contains everything necessary for its operation: UI components, types, and interfaces, utilities, etc. Only what needs to be accessible from the outside, via a public API, is exported.

Hierarchy is important here. Elements can only import and use elements from lower-level layers. For example, an element in the features layer can use elements from the entities and shared layers, but it cannot utilize elements from its layer or higher layers. This rule ensures that the project maintains a clear and structured organization.

For instance, when making changes to the "Cart" widget, we don't have to worry about impacting the "Product List" widget or altering the logic of the feature responsible for calculating discount amounts. The changes will only affect the widget itself and the pages where it is located. Therefore, the lower the level we descend, the more global and impactful the changes become.

Now, let me describe the approach that helps me create projects with a convenient structure for development.

Step 1. Shared Layer: Third-Party Services

Configuring database connections, authentication, SMS sending services, and so on. For these purposes, I have created a separate folder called "shared/services."



shared
├── services
│     ├── pinata
│     ├── prisma
│     │     ├── config
│     │     │     ├── prisma.ts
│     │     ├── index.ts
│     ├── twilio

You can also include the main types related to the operation of a REST API and similar functionalities.



shared
├── types
│     ├── api
│     ├── result

Now that all the third-party services with which our application will interact are neatly organized in one place, we can move on to the second step.

Step 2. Defining Entities

This step also does not require any complex project assessments. Here, you define the business entities and the interfaces for interacting with them. The goal of this stage is to abstract the work with entities as much as possible for all the elements in the higher layers.

For example, let's consider the business entity "NFT" (Non-Fungible Token) in the context of using Prisma as an example.



entities
├── collection
├── drop
├── nft
│     ├── db
│     │     ├── dbGetNftBasic.ts
│     │     ├── dbGetNftBasicList.ts
│     │     ├── dbGetNftMint.ts
│     │     ├── ...
│     ├── selectors
│     ├── types
│     ├── ui
│     │     ├── BuyButton
│     ├── utils
│     ├── index.ts

db - This is where all the database queries and interactions used in the application are defined. This allows for easier testing and enables query optimization if needed. selectors - These are selectors used for querying the database through Prisma.
types - These are types generated from the selectors. In principle, the selectors and types can be combined into a single folder if desired.
ui - This folder contains any shared UI components. In your case, it includes a button component that redirects visitors to the NFT purchase page. Placing the button component here makes sense because it is used in multiple features, and code sharing between features is prohibited since they are in the same feature layer.
utils - This folder contains utility functions.
index.ts - This file defines what will be exposed to the rest of the code from all the aforementioned folders.

Step 3. Widgets and Features

These two layers contain the business logic. I combined them into one step because the boundary between them is not always clear. Formally, the distinction should be as follows:

Feature: Represents a valuable action, such as user registration or product editing form.

Widget: Renders components, creating an isolated block that can be placed on pages.

In practice, there are many boundary situations. Therefore, by default, I recommend treating any element as a Widget and placing all related code in its folder. If a part of a widget is needed in another widget, it is extracted into a separate feature - it is moved to a lower layer to become available for all widgets.

The sequence of actions is as follows:

After defining the connections with external services and business entities, start creating a widget in a separate folder, placing all the necessary code in it without trying to separate its parts into separate elements outside that folder.
Ideally, the widget should be self-contained, only interacting with our entities, and freely placed on any page. All the code related to it will be located in one place and guaranteed not to impact other parts of the application.
If, when adding other widgets, it becomes apparent that they need to use the code from our widget, for example, a form for entering credit card data and processing a payment request, that form is extracted as a separate element in the feature layer. Now different widgets can use it for their purposes, and the widget where it was originally located remains isolated as before.
In case, for some reason, the functionality of sending a payment request from a card is needed in another feature, it can be moved to the lowest layer - shared. This way, it becomes something like this (assuming the authorizenet service handles card-related tasks):



shared
├── services
│     ├── authorizenet
│     │     ├── config
│     │     ├── utils
│     │     │     ├── chargeCreditCard.ts
│     │     ├── index.ts
│     ├── twilio

Yes, the general rule is to try to place the code at the highest possible layer, which is within the widgets, and move it to lower layers only when necessary. This approach helps to maintain a clear separation of concerns and isolate the functionality within its respective layer. The goal is to strike a balance between encapsulation and reusability, ensuring that each layer has its specific responsibilities while allowing flexibility when needed.

Step 4. Pages

This step involves the highest level of architecture. Pages should be kept as "thin" as possible and only handle tasks such as loading data related to the page (e.g., fetching information about a product based on the product slug in the URL) and determining the layout of widgets.

Summary

Upon initial reading, the FSD architecture may raise more questions than answers. However, in practice, it proves to be quite understandable and straightforward to work with.

A significant portion of the code is organized into the shared and entities folders, serving general purposes. The remaining elements are encapsulated within isolated widgets, and as needed, they can be moved to lower layers.

Code structured in this way is relatively easy to maintain. You can quickly identify "safe" and "risky" parts for modification, as well as understand the impact of changes. When modifying a bank card input form located in the features layer, for example, you can make changes without worrying about unforeseen effects on other features or code located in lower layers. You only need to review the few widgets that use the form. If a utility is placed within a widget's folder, it means it is used exclusively by that widget and nowhere else.

Compare this convenience to dealing with cluttered components and lib folders.

For my projects, I now always strive to align the code with this architecture, regardless of the application's size.

State management with Astro and @nanostores

Petr Tcoi — Fri, 12 May 2023 05:25:24 +0000

A convenient opportunity arose to try creating a small website using the AstroJS framework - the radiator store velarshop.ru (more like an online catalog).

Astro's work is based on an "islands architecture" approach: each page of the website is considered not as a whole but as a set of islands responsible for displaying their respective parts of the page. Most of these islands consist of statically generated HTML that is sent to the client immediately. Islands that require JavaScript functionality load it after rendering, adding the necessary interactivity. This approach allows for achieving astonishing speed in application performance.

For example, the product page has such PageSpeed scores.

An additional advantage is that both Vanilla JavaScript components and components written with React, Vue, Solid, Preact, or Svelte can be used as interactive components.

For my stack, I chose Preact because it closely resembles React, which I am familiar with, and it has minimal size.

It's desirable to keep such components small and place them as far as possible in the application's structure. This way, we achieve atomic "islands" that communicate with each other solely through shared state and, when it comes to page transitions, through localStorage.

Application Structure

The application is quite simple: it consists of a set of pages generated based on the price list and technical catalog of the manufacturer. These pages provide descriptions of products with the ability to add selected items to the shopping cart.

The state is only needed here to store information about the products added to the cart and the options chosen by the visitor (such as radiator color, casing material, etc.).

Since Astro is a set of separate pages, I used the @nanostores/persistent library to persist the state between page transitions. This library synchronizes the data with localStorage and retrieves the latest data from it upon each page reload.

Below is a diagram of a product page, indicating the main blocks that require interactivity, modification, or consume data from the state.

The blocks that modify the state are marked in red:

Product options: color, connection type, etc.
Adding/removing products from the shopping cart.

The blocks that consume the state are highlighted in blue:

Product names and prices, which change depending on the selected filters.
The shopping cart, displays the quantity and total amount of the added products.

Item Options Selection

The fundamental element of the state is the product options. They determine both the price and the item titles.

For each option, we create a separate folder with the following structure:

│
├── features
│     ├── options
│     │     ├── SelectConnection
│     │     ├── SelectGrill
│     │     ├── SelectColor
│     │     │     ├── store
│     │     │     │     ├── color.ts
│     │     │     ├── SelectColor.tsx
│     │     │     ├── index.ts
│     │

We end up with isolated folders, each containing everything necessary: a JSX component that can be placed anywhere on the website, and a piece of state in the store folder. In the case of color, the store looks like this:

/src/features/options/SelectColor/store/store.ts

import { сolors } from "@entities/Сolor"
import { persistentAtom } from "@nanostores/persistent"
import { computed } from 'nanostores'

const version = await import.meta.env.PUBLIC_LOCAL_STORAGE_VERSION

const colorId = persistentAtom<string>(`velarshop_color_active/${ version }`, "")

const color = computed(colorId, (colorId) => {
  return colors.find((color) => color.id === colorId)
})

const colorPostfix = computed(color, (color) => {
  if (!color) return ''
  return `, ${ color.name }`
})

const colorPricePerSection = computed(color, (color) => {
  if (!color) return 0
  return parseInt(color.price_section)
})

export {
  colorId,
  colorPostfix,
  colorPricePerSection
}

Here, I used a version of the store called "version" in case there are updates to the price list or color palette, to ensure that old data from localStorage doesn't mix with the updated data.

There is only one variable, colorId, which represents the user's selection. The other variables are derived from it. Their values are automatically recalculated whenever the user changes the color.

Color contains all the data about the color. It is selected from an array based on colorId. This variable is not exported and is used to derive the following two variables.
colorPrefix is computed based on the color and is used in the application to display the item title (e.g., VelarP30H white or VelarP30H black).

colorPricePerSection represents the price of painting one radiator section. It is used in calculating the final cost of the radiator.

Thus, we have a set of isolated components that can be placed in a convenient location for the user to choose suitable options.

colorPrefix is simply added at the end of the displayed item titles.
colorPricePerSection is used in a more complex manner and is involved in calculating the final cost of each item.

Calculating the cost of the radiator

We can't simply add the cost of painting one radiator section to the final cost because we also need to know the number of sections.

For example, for cast iron radiators, we display the following table:

In each row, a different number of sections is displayed, ranging from 3 to 15. Consequently, the total cost of painting the radiator varies. Therefore, we cannot simply pass the painting price value from the store. Instead, we will pass a function that calculates the radiator cost based on the radiator data, including the number of sections.

To achieve this, we create a separate store responsible for calculating the product price based on the available parameters:

/src/features/item/ItemTotalCost/store/store.ts

import { computed } from 'nanostores'
import { colorPricePerSection } from '@features/options/SelectColor'

.... 
// другие опции
...

const getColorCost = computed(colorPricePerSection, (colorPricePerSection) =>
  (model: ModelJson, radiator: RadiatorJson) =>
     colorPricePerSection * (parseInt(radiator?.sections || "0"))
  ))

...

const getItemTotalCost = computed(
  [ getColorCost, getConnectionCost, getSomeOtherCost ],
      ( getColorCost, getConnectionCost, getSomeOtherCost ) => 
           (model: ModelJson, radiator: RadiatorJson) => (
                 getColorCost(model,radiator) + getConnectionCost(model,radiator) + ...
           )
)

export { getItemTotalCost }

Now we have a function that we can pass to the product table and obtain the total cost for each variant. The cost will automatically update every time the user changes the selected options.

Shopping cart

The shopping cart is also placed in a separate folder, which contains the <BuyButton /> component responsible for adding items to the cart, as well as the store responsible for calculating the total purchase amount.

The store looks like this:

/src/features/order/ShoppingCart/store/store.ts


import { persistentAtom } from "@nanostores/persistent"
import { computed } from 'nanostores'
import type { ShoppingCart } from "@entities/shopping-cart"

const version = await import.meta.env.PUBLIC_LOCAL_STORAGE_VERSION

const storeShoppingCart = persistentAtom<ShoppingCart>(`velarshop_shopping_cart/${ version }`, { items: [] }, {
  encode: JSON.stringify,
  decode: JSON.parse,
})

const storeCartTotalPrice = computed(storeShoppingCart, (shoppingCart) => {
  return shoppingCart.items.reduce((total, item) => total + item.price * item.qnty, 0)
})

const storeCartTotalQnty = computed(storeShoppingCart, (shoppingCart) => {
  return shoppingCart.items.reduce((total, item) => total + item.qnty, 0)
})

const storeUniqueItemsQnty = computed(storeShoppingCart, (shoppingCart) => {
  return shoppingCart.items.length
})

export {
  storeShoppingCart,
  storeCartTotalPrice,
  storeCartTotalQnty,
  storeUniqueItemsQnty
}

Here, the logic is similar: there is the main variable, storeShoppingCart, where the added items are stored, and there are derived variables used to display data in the application.

The only difference is the addition of the encode/decode properties when creating storeShoppingCart. Since it is not a primitive but an array of objects, specifying how to transform the data before saving and retrieving it from local storage is necessary.

Summary

Working with AstroJS has proven to be quite simple and enjoyable. The need to embed JSX components as isolated blocks help maintain the overall architecture of the application.

When compared to NextJS, at least for small and simple websites, Astro is much easier and more pleasant to work with. If we add the impressive PageSpeed scores to the equation, the choice in favor of this framework becomes even more evident.

P.S. I haven't had the opportunity to work with the new features of Next13 (with the app folder) yet. Therefore, the comparison with Astro may not be entirely fair.

Performance of the spread operator

Petr Tcoi — Tue, 04 Apr 2023 19:32:01 +0000

In React, a common way to modify object properties is by using the spread operator. Its syntax is simple and easy to understand.

While the spread operator is a convenient way to achieve this, it can be less performant than using a traditional loop. This is because the spread operator creates a new array or object every time it is used, which can be expensive when working with large arrays/objects.

Let's consider an example: we have an input array of objects, and we need to create a new object of key-value pairs from it.

const { faker } = require('@faker-js/faker')

// generate fakeData
const fakeData = []
for (let i = 0; i < 5; i++) {
  fakeData.push({ key: faker.datatype.uuid(), name: faker.address.cityName() })
}

/* fakeData:
[
  { key: '0bc9a57c-7fd1-449a-8d98-6396f722535a', name: 'Abilene' },
  { key: '2ac57365-bc80-45a1-8033-9efd33de4a52', name: 'Aloha' },
  { key: 'a7d64eaa-0202-4c18-ade1-f43b0853c29c', name: 'Johns Creek' },
  { key: '129a89a6-490a-48b1-9394-7d143926e7d0', name: 'Chicopee' },
  { key: '2d606536-7727-496d-bbee-9663b89f40b9', name: 'Covina' }
]
*/

// generate an object with reduce method
const object = fakeData.reduce((acc, { key, name }) => {
    return { ...acc, [key]: name }
  }, {})

/* object:
{
  '83e12032-7558-467e-b840-ead992754df4': 'Jackson',
  '4fe2ce86-b202-4891-8b2f-7fa154b4b448': 'Idaho Falls',
  'de1d95c0-3c25-4b8c-9e1d-a8bc20409d45': 'El Centro',
  'b54dd7d7-b021-4fc5-9de6-633ee4e240bf': 'Fort Pierce',
  'dbee592f-79a0-461a-b477-40ae53f0ff53': 'Palm Springs'
}
*/

If you run the code, everything will work very quickly. However, the potential problem here is that on every iteration of the reduce loop, the entire object is fully copied.

Let's add some code to simply measure the execution time of the function and increase the size of the array:

...
function funcSpread() {
  return fakeData.reduce((acc, { key, name }) => {
    return { ...acc, [key]: name }
  }, {})
}

console.time('execution time')
funcSpread()
console.timeEnd('execution time')

I have the following numbers:

For an array length of 5, the execution time was 0.05ms
For an array length of 1000, the execution time was 115ms
For an array length of 5000, the execution time was 2.4 seconds!

Such execution times are likely not acceptable for either frontend or backend applications. To speed up the code, we will need to abandon the principles of immutability and simply mutate the existing object, instead of copying it on each iteration.

function funcMutate() {
  return fakeData.reduce((acc, { key, name }) => {
    acc[key] = name
    return acc
  }, {})
}

This function will process an array of 5000 objects in just 2.5ms, which is 1000 times faster!

A slightly slower but still quite fast solution for this task would be to use the _.set method from the popular lodash library:

const _ = require('lodash')
function funcLodash() {
  return fakeData.reduce((acc, { key, name }) => {
    return _.set(acc, key, name)
  }, {})
}

The execution time was 4.6ms, which is also quite fast.

Let's consider other ways to solve this problem while still adhering to the principle of immutability.

Firstly, I tried using Ramda:

const R = require('ramda')
function funcRamda() {
  return fakeData.reduce((acc, { key, name }) => {
    return R.assoc(key, name, acc)
  }, {})
}

The execution time was 1.4 seconds, which is still slow, but faster than using the spread operator.

The next popular library is Immutable.js. This library works with its data structures, so here we will deviate even further from the purity of the experiment and will be creating a Map from Immutable.js instead of an object.

const { Map } = require('immutable')

function funcImmutable() {
  return fakeData.reduce((acc, { key, name }) => {
    return acc.set(key, name)
  }, Map({}))

The result was 13 ms, which is very close to our best result. The bottleneck of Immutable.js is considered to be the conversion of the obtained data into a regular object. However, in this case, it had very little impact on overall performance:

const mapData = funcImmutable()
const object = mapData.toObject()

The same result will be obtained here. Immutable data is very fast!

The last option will be Immer. First, let's try a straightforward approach:

const { produce } = require('immer')

function funcImmer() {
  return fakeData.reduce((acc, { key, name }) => {
    return produce(acc, draft => { draft[key] = name })
  }, {})
}

...and get a catastrophic 19 seconds! But if we wrap not each step, but the entire function in produce, we can achieve significant improvement:

function funcImmer2() {
  return produce({}, draft => {
    fakeData.forEach(({ key, name }) => {
      draft[key] = name
    })
  })
}

The result is 8.5 ms. This is still slower than funcMutate or funcLodash, but quite close.

Conclusions?

It is unlikely that any practical conclusions can be drawn from this mini-experiment. Yes, the spread operator works quite slowly and, in some cases, can be a bottleneck in the work of your application when dealing with large objects or arrays.

Significant performance improvements can be achieved by abandoning the principle of immutable data. If this option does not suit you, then Immer or Immutable can be a good solution.