DEV Community: Asadbek Karimov

I Got Tired of Setting Up JS Projects

Asadbek Karimov — Tue, 20 Jan 2026 17:55:39 +0000

Every time I start a new TypeScript library, I waste 15-20 minutes on the same setup. pnpm create vite is great but too basic — no type generation, no dual CJS/ESM exports, no test setup. GitHub template repos go the other way — too opinionated, too much stuff I end up deleting. So I made vite-typescript-scaffold.

What's in it

Dual module formats (CJS + ESM)
Type definitions via vite-plugin-dts
Vitest configured
One init script: ./init.sh <name> <author> <email>

What's not in it

Everything else. No framework. No linter wars. No folder structure opinions. Clone it, run init, start coding.

One Player to Rule Them All (MP4, HLS, Dash, YouTube, Vimeo)

Asadbek Karimov — Thu, 11 Dec 2025 19:24:29 +0000

DEMO

So, full disclosure: I’m kind of moving on to other things in life right now.

But while I was cleaning up some old folders, I found this player I wrote for a project a while back. I remember being super frustrated at the time because I needed a way to play everything HLS, Dash, MP4, YouTube, Vimeo without having to glue together three different libraries or write a bunch of conditional logic just to get a video on the screen.

I figured rather than letting the code rot on my hard drive, I’d package it up and share it. Maybe it saves you a headache or two.

It’s called react-all-player. It’s not trying to change the world, it just plays video files.

The "Why" (The Story)

Back when I was working on this specific project, we had media coming from everywhere. Some of it was static MP4s, some of it was HLS streams, and marketing insisted on embedding YouTube links.

I looked around for a solution that handled all of them with a single, consistent API, and I couldn't really find one that felt lightweight enough. So, I built this.

It’s designed to be simple. You throw a URL at it, and it figures out how to play it.

What it actually does

I tried to make it as "plug and play" as possible. Here are the features I managed to cram in:

Plays Everything: HTML Video/Audio, YouTube, Vimeo.
Streaming Ready: Built-in support for hls.js and dash.js.
Auto-detection: You paste a YouTube link, it knows it's YouTube. You paste a Vimeo link, it knows.
Accessibility: Full support for VTT captions and screen readers (this was a big requirement for me).
Customizable: You can rip out the controls and put your own in if you want.

How to use it

pnpm install react-all-player

Here is the most basic example. You can see I added support for quality switching and subtitles because, well, real apps usually need that.

import ReactAllPlayer from 'react-all-player';

<ReactAllPlayer
  sources={[
    {
      file: 'https://cdn.plyr.io/static/demo/View_From_A_Blue_Moon_Trailer-1080p.mp4',
      label: '1080p',
    },
    {
      file: 'https://cdn.plyr.io/static/demo/View_From_A_Blue_Moon_Trailer-720p.mp4',
      label: '720p',
    },
  ]}
  poster="https://path-to-your-poster.jpg"
/>

The YouTube/Vimeo Headache (Solved)

I hated dealing with the YouTube API iframe mess. With this, you just drop the link in.

// Using YouTube video ID
<ReactAllPlayer
  sources={[{ file: 'bTqVqk7FSmY', type: 'youtube' }]}
  className="w-full h-64"
/>

// Or using full YouTube URL
<ReactAllPlayer
  sources={[{ file: 'https://www.youtube.com/watch?v=bTqVqk7FSmY' }]}
  className="w-full h-64"
/>

// Using Vimeo video ID
<ReactAllPlayer
  sources={[{ file: '76979871', type: 'vimeo' }]}
  className="w-full h-64"
/>

// Or using full Vimeo URL
<ReactAllPlayer
  sources={[{ file: 'https://vimeo.com/76979871' }]}
  className="w-full h-64"
/>

It unifies the events, too. So onPause works the same way whether it's a raw MP4 or a YouTube embed.

For the Next.js folks

I know SSR breaks everything regarding window objects, so if you use Next.js, just lazy load it:

import dynamic from "next/dynamic";

const ReactAllPlayer = dynamic(() => import('react-all-player'), {
  ssr: false,
});

Wrapping up

Look, it’s open source. It’s got speed controls, picture-in-picture, keyboard shortcuts all the stuff you’d expect.

I’m sharing this because I think it’s a decent tool and it works well for the HLS/Dash/MP4 trifecta. If you find a bug, feel free to fork it or submit a PR, though as I said, I'm moving onto other things so I might not be super active immediately.

If this makes your dev process easier, then I’m happy.

Link to Repo
NPM

[Boost]

Asadbek Karimov — Sun, 21 Sep 2025 01:17:30 +0000

Asadbek Karimov

Sep 21 '25

I Nearly Lost All My Users to 30-Second Database Queries

#webdev #sideprojects #lessons #postgres

Comments 4

3 min read

I Nearly Lost All My Users to 30-Second Database Queries

Asadbek Karimov — Sun, 21 Sep 2025 00:35:53 +0000

asadk.dev

Built Mylinx as a solo dev -> grew to $750 MRR.

Mylinx started as my alternative to Linktree. Built in three months, it grew into something I'm proud of:

Full customization (layout, colors, themes, etc)
Music/video embeds for creators
QR codes for offline promotion
SEO control and 11+ support
Built-in URL shortener

For over a year, everything ran smoothly. Then the analytics started choking.

When "Simple" Analytics Becomes Not So Simple

Like most developers, I built analytics the straightforward way:two tables (HitPage and HitPageLink) storing every click and view as raw data. Classic "I'll optimize later" thinking.

12 months later:

150K+ new rows monthly
Queries timing out at 30+ seconds
Users are complaining about broken analytics
Database costs are climbing

The wake-up call came when users started asking for refunds because the analytics features were unusable. At $750/month in revenue, losing customers over fixable technical issues felt especially painful.

The Constraint That Shaped the Solution

I had two paths:

Enterprise approach: Rebuild with ClickHouse, TimescaleDB, and a separate analytics infrastructure
Bootstrap approach: Work within existing constraints and get creative

Learning From the Big Players (On a Small Budget)

I studied how Instagram and other platforms handle analytics data and adapted their tiered storage approach:

Hot Data (0–90 days): Keep in HitPage for real-time queries
Warm Data (3–12 months): Pre-aggregate into daily summaries
Cold Data (1+ years): Archive or delete

The key insight: most analytics queries don't need individual hit-level data. Daily aggregates work fine for historical trends.

The Schema That Made It Work

I added a HitPageDaily table for pre-calculated metrics:

model HitPageDaily {
  id             Int      @id @default(autoincrement())
  kyteId         String
  date           DateTime
  hitCount       Int
  uniqueVisitors Int
  countryStats   Json?
  deviceStats    Json?
  referrerStats  Json?
  createdAt      DateTime @default(now())
  updatedAt      DateTime @updatedAt

  @@unique([kyteId, date])
  @@index([kyteId])
  @@index([date])
}

This turns millions of individual hits into manageable daily rows. A year of data becomes 365 rows instead of millions.

The Aggregation Job

I built a serverless function that runs nightly, processing old data in batches:

const FETCH_BATCH_SIZE = 10000;
const BATCH_SIZE = 100;

const oldHitPageData = await prisma.hitPage.findMany({
  where: { timestamp: { lt: cutoffDate } },
  take: FETCH_BATCH_SIZE,
  skip
});

// aggregate into daily buckets
oldHitPageData.forEach(hit => {
  const key = `${hit.kyteId}-${format(hit.timestamp, 'yyyy-MM-dd')}`;
  if (!dailyAggregates.has(key)) {
    dailyAggregates.set(key, {
      kyteId: hit.kyteId,
      date: startOfDay(hit.timestamp),
      hitCount: 0,
      uniqueVisitors: new Set(),
    });
  }
  const aggregate = dailyAggregates.get(key)!;
  aggregate.hitCount++;
  aggregate.uniqueVisitors.add(`${hit.ip}-${hit.device}`);
});

// save results
await prisma.hitPageDaily.upsert({
  where: { kyteId_date: { kyteId: agg.kyteId, date: agg.date } },
  update: { hitCount: agg.hitCount, uniqueVisitors: agg.uniqueVisitors.size },
  create: { kyteId: agg.kyteId, date: agg.date, hitCount: agg.hitCount, uniqueVisitors: agg.uniqueVisitors.size }
});

The job processes data in chunks, aggregates by day, then cleans up the old raw data.

Hybrid Queries for Seamless Experience

The tricky part was making queries work across both recent raw data and historical aggregates:

const [hitPageData, dailyData] = await Promise.all([
  prisma.$queryRaw`
    SELECT TO_CHAR("timestamp", 'MM/DD') as date,
           COUNT(DISTINCT CONCAT("ip", '-', "device"))::int as views
    FROM "HitPage"
    WHERE "kyteId" = ${kyteId} AND "timestamp" >= ${daysAgo}
    GROUP BY 1
  `,
  prisma.$queryRaw`
    SELECT TO_CHAR("date", 'MM/DD') as date, "uniqueVisitors" as views
    FROM "HitPageDaily"
    WHERE "kyteId" = ${kyteId} AND "date" >= DATE(${daysAgo})
  `
]);

This gives users recent data with full granularity, plus historical context without the performance hit.

Testing and Deployment

I set up a production-like dev environment with cloned real data to test the migration. After confirming everything worked as expected, I deployed during low-traffic hours with a rollback plan ready.

Results after deployment:

Analytics queries dropped from 30+ seconds to under 2 seconds
Database size reduced by ~60%
User complaints stopped
No data loss or accuracy issues

What I learned

"I'll optimize later" is expensive. What seemed like premature optimization would have saved weeks of stress and nearly losing customers.

Constraints breed creativity. Limited budget forced me to find a solution that big companies might overlook - sometimes simple aggregation beats complex infrastructure.

Solo dev advantages are real. I could test on real data, deploy quickly, and iterate without committees or approval processes.

Performance is a feature. Users don't care about your technical debt - they want things to work fast.

The Bottom Line is

This isn't how Google or Facebook would solve analytics scaling, but it doesn't need to be. For a solo developer with a $750/month side project, this pragmatic approach worked perfectly.

Two months later, the system handles 3x the original traffic with better performance than day one. Sometimes the best architecture is the one you can actually build, deploy, and maintain yourself.

Parsing Nightmares

Asadbek Karimov — Wed, 05 Mar 2025 01:24:30 +0000

Lately, I've been diving deep into the world of parser and tokenizers, attempting to rebuild Stata from scratch in JavaScript using Chevrotain. It's been an exciting yet incredibly frustrating journey, and I've hit a roadblock that has me questioning my life choices.

The Problem: Context-Sensitive Keywords.

In Stata, it’s perfectly acceptable for command names to double as variable names. Consider this simple example:

generate generate = 2

Here, the first generate is a command, while the second is simply a variable name. This kind of flexibility is intuitive for us humans, but it can turn into a real headache for a parser.

In my initial implementation, I ran into two major issues:

My token definitions were matching command keywords like generate indiscriminately, regardless of context.
The command tokens were checked before identifier tokens in my lexer's order of precedence.

This created a impossible situation where the parser couldn't distinguish between commands and identifiers with the same name.

I'm not Alone

After some digging through parsing forums and documentation, I discovered that this isn’t an isolated problem. Many language implementers have wrestled with context-sensitive keywords. The common solutions often involve elaborate workarounds ranging from context-tracking mechanisms to entirely separate parsing passes.

Some Suggested Solutions:

Token Precedence

Unfortunately, with my current Chevrotain setup, reordering token precedence isn’t feasible because Chevrotain is a parser generator library for JS that uses LL(k) parsing techniques.

LL(k) parsing techniques

top-down parser - starts with start symbol on stack, and repeatedly replace nonterminals until string is generated.
predictive parser - predict next rewrite rule
first L of LL means - read input string left to right
second L of LL means - produces leftmost derivation
k - number of lookahead symbols

It provides tools for building recursive-descent parser with full control over grammar definitions. This doesn’t mean it can’t handle token precedence it definitely can but it requires manual implementation, which involves considerable effort.

Contextual Parsing

Chevrotain has built in support for contextual tokens. We could define our keywords as contextual and enable them only in certain
parsing rules.

Post-Lexer Transformation

This is one is an interesting one post-lexing examines the token stream and reclassifies command tokens to identifiers based on their syntactic position.

Each of these methods has its merits and its tradeoffs. If anyone has tackled this issue from a different angle or has additional suggestions, I’d love to hear your thoughts.

UPDATE:

After careful consideration, I went with the post-lexing token transformation approach. This solution proved to be the most practical for several reasons:

Low overhead - it doesn't require modifying the core lexer or parser implementation
Easy to maintain - Solution is isolated in a single processing step before lexing and parsing
Minimal complexity - No need for complex state machines or multiple parsing passes
Predictable behavior - Context based token reclassification follows clear, documented rules

The key insight was that context sensitivity could be handled by examining token patterns after initial lexing. This approach effectively solves the "generate generate = 1" problem with remarkably little code.

Better Math in JavaScript?

Asadbek Karimov — Wed, 22 Jan 2025 18:29:46 +0000

As a web developer working on data visualization and scientific computing projects, I've often found JavaScript's native math capabilities lacking. The hunt for robust standard library led me to stdlib-js.

The promise of stdlib

The stdlib project caught my eye with its impressive set of features:

Comprehensive mathematical functions
Focus on numerical precision
Cross-platform consistency
Extended functionality beyond native Math

Benchmarking Reality

I ran benchmarks comparing stdlib against native JavaScript Math operations across 100,000 rows of data. The results were suprising:

Performance Comparison Table

Operation	Performance Difference	Precision (Max Diff)	Precision (Avg Diff)	Notes
exp	189.44% slower	0.000e+0	0.000e+0	Largest performance gap
log10	58.94% slower	4.441e-16	1.142e-17	Significant slowdown
ln/log	33.63% slower	0.000e+0	0.000e+0	Notable performance impact
tan	31.87% slower	0.000e+0	0.000e+0	Slower trig operation
acos	29.17% slower	4.441e-16	4.569e-17	Slower inverse trig
sin	24.54% slower	1.110e-16	3.101e-18	Basic trig affected
cos	23.00% slower	1.110e-16	3.039e-18	Basic trig affected
asin	22.74% slower	2.220e-16	1.219e-17	Inverse trig impact
atan2	17.02% slower	2.220e-16	6.958e-18	Moderate slowdown
atan	13.86% slower	1.110e-16	2.675e-18	Better performing inverse trig
ceil	2.84% slower	0.000e+0	0.000e+0	Minimal impact
abs	1.99% slower	0.000e+0	0.000e+0	Negligible difference
floor	2.22% faster	0.000e+0	0.000e+0	Slight improvement
round	1.44% faster	0.000e+0	0.000e+0	Minor gain
sqrt	2.68% faster	0.000e+0	0.000e+0	Better performance
hypot	1.18% faster	0.000e+0	0.000e+0	Slight improvement

The Good

Basic operations showed modest improvements:

sqrt: 6.23% faster
round: 3.02% faster
floor: 2.02% faster

The Not So Good

Complex operations took a significant hit:

exp: 189.85% slower
log10: 59.37% slower
trig functions: 25-33% slower

Precision Trade-off

The precision differences were minimal, with a maximum difference of 4.441e-16. Most operations whoed identical results between stdlib-js and native Math.

When to Use stdlib-js

Basic mathematical operations
Projects requiring guaranteed cross-platform behavior
Cases where consistent results matter more than raw speed

Looking Forward

There's potential for improvement - converting stdlib-js to WebAssembly could boost performance by running close to native speed, particularly for those complex operations currently showing significant slowdown. But until that happens, the choice between stdlin-js and native Math requires careful consideration of your specific needs.

Bottom Line

stdlib-js is a solid library taht delviers on its promise of consistency and extended functionality. However, the performance trade-offs mean it's not always the best choice. For my projects, I'll be using native approach and maybe in the future will try to compile stdlib-js to WASM to test if its really faster.

Have you tried stdlib in your projects? I'd be curious to hear about your experiences with mathematical computations in JavaScript.

Resources

Run live demo here
Benchmark repo
Asadbek Karimov

🚀 V8 Engine Secrets Slashed Memory Usage by 66% with TypedArrays

Asadbek Karimov — Sat, 16 Nov 2024 17:46:17 +0000

When optimizing our DTA (Stata file format) parser and writer, we discovered several key techniques that dramatically improved performance:

1. Avoiding DataView for High-Performance Binary Operations

original approach:

function writeValue(view: DataView, offset: number, value: number) {  
    view.setFloat64(offset, value, true);
    return offset + 8; 
}

optimized approach using Uint8Array:

// create shared buffer and views once, outside the function
const sharedBuffer = new ArrayBuffer(8);
const sharedFloat64 = new Float64Array(sharedBuffer);
const sharedUint8 = new Uint8Array(sharedBuffer);

function writeValueWithUint8Array(buffer: Uint8Array, offset: number, value: number): number {
    // write to shared Float64Array
    sharedFloat64[0] = value;

    // copy bytes to target buffer
    buffer.set(sharedUint8, offset);
    return offset + 8;
}

DataView operations are significantly slower due to bounds checking and endianness handling.

Uint8Array provides faster read/write operations than DataView due to direct memory access.

Here's a diagram that illustrates it.

2. Pre-computing Common Patterns

Rather than computing missing value patterns on demand, we pre-compute them once:

original approach:

const MISSING_VALUES = {
  ...
  BYTE_MISSING: 101,
  ...
};

function writeMissingValue(
  view: DataView,
  offset: number,
  type: ColumnType,
  littleEndian: boolean
): number {
  switch (type) {
    case ColumnType.BYTE:
      view.setInt8(offset, MISSING_VALUES.BYTE_MISSING);
      return offset + 1;
    case ...
  }
}

optimized approach:

const MISSING_PATTERNS = {
  BYTE: new Uint8Array([MISSING_VALUES.BYTE_MISSING]),
  FLOAT_NAN: (() => {
    const buf = new ArrayBuffer(4);
    new DataView(buf).setUint32(0, 0x7fc00000, true);
    return new Uint8Array(buf);
  })(),
  DOUBLE_NAN: (() => {
    const buf = new ArrayBuffer(8);
    const view = new DataView(buf);
    view.setUint32(0, 0, true);
    view.setUint32(4, 0x7ff80000, true);
    return new Uint8Array(buf);
  })(),
};

This optimization:

Eliminates repeated buffer allocations and bit manipulations in hot paths
Provides immediate access to commonly used patterns
Reduces cognitive load by centralizing binary pattern definitions

3. Loop Optimization for V8's JIT Compiler

Understanding V8's optimization patterns led us to prefer simple for-loops over higher-order array methods:

// before: creates closure and temporary arrays
const formats = Array(nvar)
  .fill(null)
  .map(() => ({
    type: ColumnType.DOUBLE,
    maxDecimals: 0,
  }));

// after: simple, predictable loop that V8 can optimize
const formats = new Array(nvar);
for (let i = 0; i < nvar; i++) {
  formats[i] = {
    type: ColumnType.DOUBLE,
    maxDecimals: 0,
  };
}

V8's JIT compiler can better optimize simple counting loops because:

The iteration pattern is predictable
No closure creation or function call overhead
Memory allocation pattern is more straightforward
Better instruction caching due to linear code execution

4. Shared Buffer Strategy for Maximum Efficiency

One of our most impactful optimizations was implementing a shared buffer strategy.
Instead of allocating new buffers for each operation, we maintain a single pre-allocated buffer for temporary operations:


// pre-allocate shared buffers at module level
const SHARED_BUFFER_SIZE = 1024 * 1024; // 1MB shared buffer
const sharedBuffer = new ArrayBuffer(SHARED_BUFFER_SIZE);
const sharedView = new DataView(sharedBuffer);
const sharedUint8 = new Uint8Array(sharedBuffer);

// different views for different numeric types
const tempBuffers = {
  float32: new Float32Array(sharedBuffer),
  float64: new Float64Array(sharedBuffer),
  uint8: new Uint8Array(sharedBuffer),
  dataView: new DataView(sharedBuffer),
};

This approach provides several key advantages:

Eliminates thousands of small buffer allocations that would trigger garbage collection
Improves CPU cache utilization by reusing the same memory locations
Reduce memory fragmentation in long-running processes
Provides specialized view for different numeric types without additional allocations

Key Improvements 📈

Large Files (Best Results)

⚡ ~43% faster conversion time (from 3939ms to 2231ms)
💾 34% reduction in peak heap usage (13189MB to 8682MB)
🔄 52% increase in rows/second processing (5935 to 9030 rows/sec)

Medium Files

⚡ ~41% faster conversion time (260ms to 154ms)
💾 33% reduction in peak memory usage (1000MB to 673MB)
🔄 46% boost in rows/second processing (7139 to 10453 rows/sec)

Small Files

⚡ ~44% faster conversion time (16.47ms to 9.14ms)
💾 28% reduction in peak heap usage (85MB to 60MB)
🔄 42% increase in rows/second processing (8351 to 11930 rows/sec)

Conclusion

The key learning was that understanding V8's optimization strategies and leveraging typed arrays with shared buffers can dramatically improve performance when processing binary data. While some optimizations made the code slightly more complex, the performance benefits justified the trade-offs for our high-throughput use case.

Remember: Reserve optimizations for data-heavy critical paths - everywhere else, favor clean, maintainable code.

🙌 Thank You, Contributors!

These optimizations were a team effort. Big shoutout to the awesome folks who helped level up our code:

🧑‍💻 Maintainer

• GitHub
• Website
• Twitter

📚 Further Reading

🚨 Made a LIVE 2024 election counter! Enjoy

Asadbek Karimov — Wed, 06 Nov 2024 01:55:25 +0000

Live2024

Built a quick live 2024 Trump vs. Harrison counter. Pulling data from CNN’s live tracker into a simple, clean card. Most live trackers I found were cluttered with unnecessary components and text, so I created a streamlined version in just 5-10 minutes. Feel free to grab the code!

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>2024 US Election Counter</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            height: 100vh;
            margin: 0;
            background-color: #f0f0f0;
        }
        .card {
            background-color: white;
            border-radius: 8px;
            box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
            padding: 20px;
            text-align: center;
            max-width: 400px;
            width: 100%;
        }
        h1 {
            color: #333;
            font-size: 24px;
            margin-bottom: 10px;
        }
        p {
            color: #666;
            font-size: 14px;
            margin-bottom: 20px;
        }
        .counter-container {
            display: flex;
            justify-content: space-around;
        }
        .counter {
            text-align: center;
        }
        .counter h2 {
            font-size: 18px;
            margin-bottom: 10px;
        }
        .count {
            font-size: 36px;
            font-weight: bold;
            transition: all 0.5s ease;
        }
        .democrats {
            color: #0015bc;
        }
        .republicans {
            color: #ff0000;
        }
        .loading, .error {
            text-align: center;
            font-size: 18px;
            color: #666;
        }
        .error {
            color: #ff0000;
        }
        .vote-info {
            font-size: 14px;
            color: #555;
        }
        @keyframes pulse {
            0% { transform: scale(1); }
            50% { transform: scale(1.05); }
            100% { transform: scale(1); }
        }

        .banner {
            position: fixed;
            left: 0;
            right: 0;
            bottom: 0;
            background-color: #f8f8f8;
            text-align: center;
            border-top: 1px solid #ddd;
            padding-top:6px;
            padding-bottom: 6px;
            font-size: x-large;
            font-weight: 500;
            color: #171717;
        }

        .banner a {
            text-decoration: underline;
        }
    </style>
</head>
<body>
    <div class="card">
        <h1>2024 US Election Counter</h1>
        <p>Live results updated every 10 seconds</p>
        <div id="content">
            <div class="loading">Loading...</div>
        </div>
    </div>


    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-W16Z0D8BJ7"></script>
    <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'G-W16Z0D8BJ7');
    </script>

    <script>
        const content = document.getElementById('content');

        function updateCounter(party, count, percentage, votes) {
            const countElement = document.getElementById(`${party}-count`);
            if (countElement) {
                countElement.textContent = count;
                document.getElementById(`${party}-percentage`).textContent = `${percentage}%`;
                document.getElementById(`${party}-votes`).textContent = `Votes: ${votes}`;
                countElement.style.animation = 'pulse 0.5s ease';
                setTimeout(() => {
                    countElement.style.animation = '';
                }, 500);
            }
        }

        function renderCounters(democratsCount, republicansCount, demPercentage, repPercentage, demVotes, repVotes) {
            content.innerHTML = `
                <div class="counter-container">
                    <div class="counter">
                        <h2 class="democrats">Democrats</h2>
                        <div id="democrats-count" class="count democrats">${democratsCount}</div>
                        <div id="democrats-percentage" class="vote-info">${demPercentage}%</div>
                        <div id="democrats-votes" class="vote-info">Votes: ${demVotes}</div>
                    </div>
                    <div class="counter">
                        <h2 class="republicans">Republicans</h2>
                        <div id="republicans-count" class="count republicans">${republicansCount}</div>
                        <div id="republicans-percentage" class="vote-info">${repPercentage}%</div>
                        <div id="republicans-votes" class="vote-info">Votes: ${repVotes}</div>
                    </div>
                </div>
            `;
        }

        async function fetchElectionData() {
            try {
                const response = await fetch('https://politics.api.cnn.io/results/bop/2024-PG-US.json', {
                    headers: {
                        'accept': '*/*',
                        'accept-language': 'en-US,en;q=0.9',
                        'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36',
                        'x-api-key': 'TtGlrrOrcdJNvE5U9t4XulVZuwk68Ecru3UIgtnr'
                    }
                });

                if (!response.ok) {
                    throw new Error('Failed to fetch election data');
                }

                const data = await response.json();

                // Extract the relevant counts, percentages, and vote numbers
                const democratsData = data.meta.candidates.DEM;
                const republicansData = data.meta.candidates.REP;

                const democratsCount = democratsData.count;
                const republicansCount = republicansData.count;
                const democratsPercentage = democratsData.votePercentStr;
                const republicansPercentage = republicansData.votePercentStr;
                const democratsVotes = democratsData.voteStr;
                const republicansVotes = republicansData.voteStr;

                // Render the counters or update them if they already exist
                if (content.querySelector('.counter-container')) {
                    updateCounter('democrats', democratsCount, democratsPercentage, democratsVotes);
                    updateCounter('republicans', republicansCount, republicansPercentage, republicansVotes);
                } else {
                    renderCounters(democratsCount, republicansCount, democratsPercentage, republicansPercentage, democratsVotes, republicansVotes);
                }
            } catch (error) {
                console.error('Error:', error);
                content.innerHTML = '<div class="error">Error fetching election data</div>';
            }
        }

        function startPolling() {
            fetchElectionData(); // Initial fetch on load
            setInterval(fetchElectionData, 10000); // Poll every 10 seconds
        }

        startPolling();
    </script>

    <div class="banner">
        Sponsored by <a href="https://mylinx.cc/" target="_blank">Mylinx</a>
    </div>
</body>
</html>

How to Implement Rate Limiting in Next.js Quickly and Easily

Asadbek Karimov — Thu, 12 Sep 2024 17:05:07 +0000

Rate limiting is important for any production app, but it’s not as complicated as it seems. In this post, we’ll show you how to easily set up API rate limiting using Upstash and Redis.

In this example, I'll show you how I added rate limiting to my production app, Mylinx.

Sign Up for a Free Upstash Account

Upstash is a managed service for Redis and Kafka with a serverless setup, offering a generous free tier. We'll use Upstash to implement rate limiting, as their rate limit package makes it easy to set up with any API.

Set Up Your Upstash Database

Copy the URL and Token to your .env

Adding Rate Limiting to Our API Endpoint

First, install the necessary packages:

npm install @upstash/redis @upstash/ratelimit request-ip

Next, choose the endpoint you want to protect and import the required modules:

import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
import requestIp from "request-ip";

Set Up Rate Limiter

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL as string,
  token: process.env.UPSTASH_REDIS_REST_TOKEN as string,
});

const rateLimiter = new Ratelimit({
  redis: redis,
  limiter: Ratelimit.slidingWindow(60, "1m"), // s: seconds m: minutes h: hours and d: days
});

Add Rate Limiting to API Handler

import { NextApiRequest, NextApiResponse } from 'next';
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
import requestIp from "request-ip";

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL as string,
  token: process.env.UPSTASH_REDIS_REST_TOKEN as string,
});

const rateLimiter = new Ratelimit({
  redis: redis,
  limiter: Ratelimit.slidingWindow(10, "1h"),
});

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'POST') {
    const clientIp = requestIp.getClientIp(req) || 'default-identifier';

    const { success } = await rateLimiter.limit(`${clientIp}-my-api-endpoint`);

    if (!success) {
      return res.status(429).json({ message: 'Rate limit exceeded, please try again later.' });
    }

    // Your API LOGIC HERE

    return res.status(200).json({ message: 'Request successful!' });
  } else {
    return res.status(405).json({ message: 'Method not allowed.' });
  }
}

This example provides a simple setup for rate limiting, allowing you to easily integrate it into your API endpoint.

Congratulations! You’ve successfully added rate limiting by IP to one of your endpoints.

I can't express enough how Upstash and its free tier have saved my app from collapse. With the free tier barely touched, Mylinx handles over 175K hits a month.

🌧️ Realistic Raindrop Effects in JavaScript

Asadbek Karimov — Tue, 10 Sep 2024 14:36:01 +0000

Web development often means heavy libraries for realistic animations. Many solutions fall short of true realism, but Mylinx’s new open-source live themes offer ultra-lightweight, lifelike effects that redefine what JavaScript can achieve.

The Challenge: Realistic Raindrop Simulation

I searched extensively for a realistic raindrop effect in JavaScript but found that most solutions looked fake or fell short. So, I decided to create my own, developing an animation that simulates raindrops with reflection and rain physics—all under 400KB. The result is a stunningly realistic effect that truly enhances web projects.

Meet the Live Themes

Our collection includes:

Rain Drop: Experience the most realistic raindrop simulation you've seen in JavaScript. Check out the live demo.

Cloudy Storm: A dynamic storm scene with cloudy effects that will enhance any weather-themed project. Explore the demo.

Light Speed: A high-speed animation that captures the essence of fast-moving light. View the demo.

Why This Matters

These themes are designed to be lightweight and easy to integrate, making them perfect for enhancing your projects without adding unnecessary bloat. Whether you're building a personal site or a professional portfolio, these themes provide a unique and engaging visual experience.

Feel free to use these themes in your upcoming projects or create your own website for free at Mylinx.

Mylinx | Launch your bio page in seconds

Free bio link tool for businesses and influencers. Advanced, Customizable Link-in-Bio Tool.

mylinx.cc

How I Built a Scalable, Free URL Shortener.

Asadbek Karimov — Sat, 24 Aug 2024 22:10:54 +0000

Introduction

URL shorteners are in high demand for their ability to manage and share links effectively. They simplify long URLs, provide tracking analytics, and support branding. However, many services come with high costs or limitations for advanced features.

The Problem

However, most services offer only a limited free tier—typically allowing just 2-5 short links—which is often inadequate for real use. Additionally, free URL shorteners often lack essential features and are frequently developed by amateurs. Many users find that free options, especially those as browser extensions, are not taken seriously unless they come with a paid version.

The Solution:

Building a URL shortener from scratch? Nah, you’re crazy! Instead, we grabbed a trusty open-source solution that’s already been battle-tested. By using this ready-made tool, we skipped the drama of starting from zero and cut our development time way down. This gave us more time to focus on making our app and management system even better—plus, it saved us from pulling out our hair!

Next step on building this system we will have to check the 3 pillars of Designing data intensive application which are

RELIABILITY

Redundancy: Run two instances of Shlink on separate VPS servers.
Monitoring and Alerts: Use a free status pinger for basic monitoring.
Preventing Misuse: To avoid Google flagging your domain for misuse, check URLs through GCP Web Risk before shortening. This helps identify and avoid malicious URLs.

Scalability

Cloud Hosting: Renting VPS servers and using Coolify for container management is cost-effective.
Load Balancing: Use NGINX for distributing traffic.
Caching: Utilize Redis Upstash for caching.

Maintainability

Rate Limiting: Implement rate limiting with Redis Upstash.
Bot Detection: Use Shlink’s built-in bot detection and consider adding reCAPTCHA to enhance security, especially for unauthenticated users.
Quota Management: Implement hard limits to ensure fair usage for all users.

Result

URL Shortener Mylinx: A free, scalable, and cost-effective URL shortener. With the current cost of just $20/month, it supports up to 10 million visits a month and can generate 10-20 million short URL links.

Conclusion

In conclusion, building and managing a URL shortener can be both challenging and rewarding. By leveraging existing open-source tools and implementing strategies for reliability, scalability, and maintainability, you can create a robust and cost-effective solution. As part of our ongoing efforts to provide value to the community, I plan to release a Docker file for the Mylinx URL shortener in the near future. This will make it easier for others to deploy and use the service. Stay tuned for updates if you're interested in this public release!

Another Linktree Clone?

Asadbek Karimov — Tue, 30 Jul 2024 20:50:19 +0000

Creating Mylinx: An Accessible and Affordable Bio Link Solution

When searching for a side SaaS project, I noticed a glaring issue in the bio link/micro website space: it was saturated with tools that either lacked essential features or placed them behind expensive paywalls. Many services offered limited customization, inadequate traffic analytics, and poor SEO control. These features were often locked behind subscription plans costing upwards of $10/month—an amount that many users, particularly in regions like India, Africa, and Southeast Asia, simply couldn't afford.

The Problem with Existing Tools

Most bio link services out there promise to help users create a simple, customizable landing page. However, they fall short in several areas:

Limited Features: Basic features like detailed traffic analytics, advanced SEO control, and deep customization options are often missing.
High Costs: Essential tools are locked behind expensive paywalls, making them inaccessible to many users around the world.
Lack of Localization: Many of these services don't offer multi-language support, limiting their usability for non-English speakers.

Ignoring Emerging Markets

None of the professional tools on the market seem to care about users in second and third-world countries where there's a huge potential for upcoming creators and influencers. These regions are brimming with talented individuals who need accessible and affordable tools to boost their online presence and grow their following. Yet, the high costs and limited feature sets of existing solutions make it incredibly difficult for them to thrive.

The Birth of Mylinx

Driven by this gap in the market, I decided to create Mylinx. Over the course of just three months, I built a platform that not only included core features similar to Linktree but also added significant enhancements:

Full Customization: Users can fully customize their pages, adjusting everything from the layout to the color.
Music/Video Link: Integration with popular music and video platforms to help content creators share their work more effectively.
QR Codes: Easy generation of QR codes for sharing links in the physical world.
SEO Control: Advanced SEO tools to help users improve their search engine rankings.
Localization: The app supports over 11 languages, making it accessible to a global audience: English, Español, हिन्दी, Deutsch, Русский, 日本語, اردو, Türkçe, Tiếng Việt, Melayu, عربي.
URL Shortener: A comprehensive solution to help make every point of connection between your content and your audience more powerful. Unlike other smart link services (cough cough, Bitly, TinyURL etc), Mylinx offers this feature without the exorbitant costs.

Technology Stack

Building Mylinx required a robust and scalable technology stack. Here's what I used:

Next.js: For server-side rendering and a seamless user experience.
Chakra UI: To create a beautiful, responsive, and accessible user interface.
Prisma: For database management and seamless interaction with PostgreSQL
Supabase: As the primary database for its reliability and scalability.
Vercel: To deploy the application and ensure fast performance.
Cloudflare: For added security and content delivery network (CDN) services.
Shlink: For smart link shortening.
Upstash: As the caching layer to enhance performance.

Ensuring Availability and Consistency

Availability means keeping the system running even during failures, typically measured as uptime. Consistency ensures all clients see the same data simultaneously. To achieve this, I use open-source tools like Supabase, Shlink, and Next.js in a self-dockerized setup. This ensures Mylinx remains highly available and consistent. If an upstream provider goes down, I can quickly redirect traffic through a backup, maintaining uninterrupted service.

The Impact

In just a short time, Mylinx has gained traction. We now have over 1,000 pages and have recorded 750,000 page hits. The feedback has been overwhelmingly positive, particularly from content creators in emerging markets who appreciate the accessibility and affordability of the platform.

Join Us

I invite you to check Mylinx.cc and see for yourself how it can help you or your network. We're always open to suggestions, and my goal is to keep improving the platform to better serve content creators worldwide. Together, we can help boost their following and earnings without breaking the bank.

Cheers to making the web more accessible and affordable for everyone!