DEV Community: rahul patwa

How to Sync Design Tokens Between React and Flutter (Without Losing Your Mind)

rahul patwa — Mon, 06 Apr 2026 03:26:00 +0000

Style Dictionary's Flutter support has been broken for years. I built tokensync — a CLI that generates CSS and Flutter ThemeData from one tokens.json file, then verifies they match numerically.
Your designer just updated the brand color.

You open your CSS file. Update --color-brand-500. Then you open your Flutter file. Update AppTheme._lightColors.primary. Then you grep for anywhere else it might appear. Then you do the same for dark mode. Then you hope you got them all.

Three weeks later a designer screenshots both apps side by side. The web button is #5C6BC0. The mobile button is #5B6BC0.

Off by one digit. Nobody noticed. It shipped.

If you maintain both a React web app and a Flutter mobile app, this is a design token sync problem — and it costs teams 6–20 hours every time tokens change.

Why existing design token tools don't solve this

Style Dictionary is the industry standard for design token transformation. It's genuinely great for CSS. But its Flutter support produces flat key-value constants — not the ThemeData, ColorScheme, or TextTheme that Flutter apps actually need:

// What Style Dictionary gives you for Flutter:
static const double typographyDisplayFontSize = 48.0;
static const double typographyDisplayFontWeight = 700;
// That's it. You still write TextStyle yourself.

GitHub issues requesting proper Flutter support have been open since 2022 with no resolution. Most teams end up writing a custom script. It works until the first rebrand, then breaks.

The other pain point is letter-spacing conversion. CSS letter-spacing: -0.02em at font-size: 48px should become Flutter letterSpacing: -0.96. Every team figures this out independently. Every team gets it wrong at least once.

Introducing tokensync: one source of truth for React and Flutter design tokens

tokensync is an open-source CLI that reads a single tokens.json file in W3C DTCG format and generates:

tokens.css — CSS custom properties with :root (light) and [data-theme="dark"] (dark) selectors
app_theme.dart — complete Flutter ThemeData, ColorScheme, TextTheme, and TextStyle
tokens.ts — typed TypeScript constants for shared logic

Then it runs a parity check — numerically comparing every token value between the CSS and Dart outputs to catch drift before it ships.

npx tokensync init   # scaffold config + tokens.json
npx tokensync build  # generate all platform outputs
npx tokensync check  # verify React and Flutter values match

What the generated Flutter output looks like

Given this design token:

{
  "typography": {
    "display": {
      "$type": "typography",
      "$value": {
        "fontFamily": "Inter",
        "fontSize": "48px",
        "fontWeight": 700,
        "lineHeight": "1.1",
        "letterSpacing": "-0.02em"
      }
    }
  }
}

tokensync generates idiomatic Flutter ThemeData:

static const TextTheme _textTheme = TextTheme(
  displayLarge: TextStyle(
    fontFamily:    'Inter',
    fontSize:      48.0,
    fontWeight:    FontWeight.w700,
    height:        1.1,
    letterSpacing: -0.96,   // ← -0.02em × 48px, correctly converted
  ),
);

And the matching CSS:

:root {
  --typography-display-font-family: Inter;
  --typography-display-font-size: 48px;
  --typography-display-font-weight: 700;
  --typography-display-line-height: 1.1;
  --typography-display-letter-spacing: -0.02em;
}

The generated Dart file passes dart analyze with zero errors out of the box.

How the parity checker works

After building, tokensync compares every token value between platforms:

Parity: web vs flutter
11 tokens  ·  11 passed
✓ Parity check passed

It normalizes values before comparing: em to px, named font weights ("SemiBold" → 600), 0em and 0.0 both treated as zero. If anything diverges, it reports the exact token name and delta.

For CI, add this to your pipeline:

tokensync check --ci   # exits with code 1 if CSS and Dart diverge

Mismatches block merges. No more #5C6BC0 vs #5B6BC0 in production.

Dark mode with a single token definition

Define your semantic tokens with light and dark values:

{
  "semantic": {
    "$modes": {
      "light": { "color": { "primary": { "$value": "{color.brand.500}" } } },
      "dark":  { "color": { "primary": { "$value": "{color.brand.100}" } } }
    },
    "color": {
      "primary": { "$type": "color", "$value": "{color.brand.500}" }
    }
  }
}

tokensync generates both :root / [data-theme="dark"] blocks in CSS and both ThemeData.light() / ThemeData.dark() in Flutter — from the same source of truth.

Figma integration

If your design tokens live in Figma Variables (Professional plan):

FIGMA_ACCESS_TOKEN=your_token FIGMA_FILE_KEY=your_key tokensync pull

On the free Figma plan, use the Styles API instead:

tokensync pull --figma-api styles

Both write a tokens.json ready for tokensync build.

Tokens Studio exports are also supported via a built-in adapter.

How it compares to Style Dictionary

Feature	Style Dictionary	tokensync
CSS custom properties	✓	✓
Flutter `ColorScheme` (light + dark)	✗	✓
Flutter `TextTheme` with named slots	✗	✓
`TextStyle` with correct `letterSpacing`	✗	✓
em → px letter-spacing conversion	✗	✓
Named font weights (`"SemiBold"` → `FontWeight.w600`)	✗	✓
Cross-platform parity check	✗	✓
Figma Variables pull	✗	✓

Getting started

# Install globally
npm install -g tokensync

# Or run with npx
npx tokensync init && npx tokensync build

The init command scaffolds a tokensync.config.ts and a sample tokens.json with colors, spacing, and typography — including light/dark modes. Running build generates all three platform outputs and runs the parity check.

Requirements: Node.js 18+. Zero runtime dependencies. MIT license.

GitHub: [https://github.com/rahulpatwa1303/tokensync]

Current status and what's next

This is v0.1.0. It handles the token types I've encountered in real projects: color, dimension, typography, shadow, number. The generated Dart is idiomatic and passes static analysis.

Planned for v0.2.0: React Native formatter, oklch color support, watch mode improvements.

Do you have this problem?

If you ship both React and Flutter, I'd genuinely like to know how you handle design token sync today. Manual copy-paste? A custom script? A SaaS tool? Something in your CI?

Drop a comment — trying to understand whether this pain is widespread or specific to how my team works.

Gemma 4 on Android: Complete Developer Guide to On-Device AI

rahul patwa — Sun, 05 Apr 2026 08:33:55 +0000

Google dropped Gemma 4 on April 2, 2026, under the Apache 2.0 license. The E2B variant 2.58 GB file, under 1.5 GB active memory, runs at 52.1 decode tokens per second on a Samsung S26 Ultra GPU. That's fast enough to stream responses faster than a user can read them, on hardware they already own, with no API key and no data leaving the device. (HuggingFace model cards, 2026)

This is the full integration guide: model selection, Kotlin setup for all three backends, real performance numbers, and the production gotchas I've found building with this stack.

TL;DR: Gemma 4 E2B runs on any Android device with 6 GB+ RAM at 52 tokens/sec on GPU. Add one Gradle dependency (com.google.ai.edge.litertlm:litertlm-android), download the 2.58 GB model file to filesDir, initialize the engine, and stream responses via a Kotlin Flow. Watch out: SamplerConfig takes Double, not Float, and sendMessageAsync emits cumulative text per emission, not deltas. (Google Developers Blog, 2026)

Why This Is Different From Every Other Mobile LLM Attempt

I've tried running quantized models on Android twice before Gemma 4. Both times I hit the same wall: memory pressure killed the process, or inference was too slow to ship. Gemma 4's E2B breaks those assumptions. Its mixed-bit quantization keeps active memory under 1.5 GB, and LiteRT-LM, Google's open-source runtime, released September 24, 2025 - abstracts CPU, GPU, and NPU execution behind a single Kotlin API. (Google Developers Blog, 2025)

The market signal backs the technical case. The on-device AI market hit $10.76 billion in 2025 and is projected to reach $75.5 billion by 2033 at a 27.8% CAGR. (Grand View Research, 2025) That growth is driven by the same forces pushing you to read this post: privacy requirements, latency demands, and the economics of zero marginal inference cost.

The privacy argument closes enterprise deals faster than performance specs do, in my experience. Legal teams understand "data never leaves the device" immediately. Explaining prefill tokens per second takes longer. And 64% of professionals told Cisco in 2025 they worry about inadvertently sharing sensitive data with cloud AI services, so there's a real user-level demand for what this stack offers. (Cisco, 2025)

E2B or E4B? Pick the Right Variant First

Gemma 4 ships two variants for on-device Android deployment. Picking the wrong one costs you either capability or hardware compatibility.

E2B is the right default for most apps. File size is 2.58 GB. Active memory sits under 1.5 GB, which fits any device with 6 GB RAM or more the majority of Android flagships and mid-rangers sold since 2024. Benchmark scores: MMLU Pro at 60.0%, LiveCodeBench v6 at 44.0%, GPQA Diamond at 43.4%. (HuggingFace, 2026) Those numbers are sufficient for summarization, Q&A, writing assistance, and classification.

E4B is for when reasoning quality is the product. File size is 3.65 GB, active memory around 2 GB. The capability jump is real: MMLU Pro rises to 69.4%, LiveCodeBench to 52.0%, and GPQA Diamond (graduate-level science reasoning) jumps from 43.4% to 58.6%. (HuggingFace, 2026) That 15-point GPQA gain matters if you're building legal document review, medical triage support, or code analysis. You'll need 8 GB+ RAM as your device minimum.

GPU decode speed on an S26 Ultra drops from 52.1 tokens/sec (E2B) to 22.1 tokens/sec (E4B). At 22 tokens/sec, streaming still feels natural users read prose at roughly 4-5 words per second. The trade-off is prefill time on long contexts.

Both variants support 140 languages and handle text, image, and audio inputs. (Google DeepMind, 2026) That multimodal capability in a package this small is genuinely surprising. Start with E2B. Only move to E4B if your use case actually demands stronger reasoning.

⚙️ Full Kotlin Integration: All 5 Steps

The full integration is five steps. Each is self-contained. You can have a working demo in under an hour.

Step 1 Add the Gradle Dependency

// app/build.gradle.kts
dependencies {
    implementation("com.google.ai.edge.litertlm:litertlm-android:latest.release")
}

Sync and you're done. No NDK wrangling, no JNI plumbing, no native toolchain configuration at this stage. GPU and NPU backends require additional AndroidManifest.xml entries - covered in the backend section below.

Step 2 Download the Model File

The model doesn't go in your APK. At 2.58 GB (E2B) or 3.65 GB (E4B), it blows past Play Store's 150 MB limit. Download on first launch, store in context.filesDir.

For development and local testing, pull the file directly with the HuggingFace CLI:

# Install the CLI
pip install huggingface_hub

# Download E2B (2.58 GB)
huggingface-cli download litert-community/gemma-4-E2B-it-litert-lm \
  gemma-4-E2B-it.litertlm --local-dir ./models

# Download E4B (3.65 GB), optional
huggingface-cli download litert-community/gemma-4-E4B-it-litert-lm \
  gemma-4-E4B-it.litertlm --local-dir ./models

For production, implement a WorkManager download job with DownloadManager. Build a proper progress screen with cancellation, resume-on-reconnect, and checksum verification. A 2.58 GB download on a mobile connection takes meaningful time - design accordingly.

Step 3 - Initialize the Engine

import com.google.ai.edge.litertlm.Backend
import com.google.ai.edge.litertlm.Engine
import com.google.ai.edge.litertlm.EngineConfig

val config = EngineConfig(
    modelPath = context.filesDir.absolutePath + "/gemma-4-E2B-it.litertlm",
    backend = Backend.GPU()
)
val engine = Engine(config).also { it.initialize() }

Critical: engine.initialize() is a blocking call. Run it on a background dispatcher (Dispatchers.IO) inside a coroutine. On slower devices with older storage, initialization takes 3-8 seconds. Call it on the main thread and you'll get an ANR before the user even types anything.

Hold the Engine instance in a singleton or a ViewModel. Re-initialization is expensive. Treat it like a database connection open once, reuse everywhere.

Step 4 Create a Conversation

import com.google.ai.edge.litertlm.Content
import com.google.ai.edge.litertlm.Contents
import com.google.ai.edge.litertlm.ConversationConfig
import com.google.ai.edge.litertlm.SamplerConfig

val conversation = engine.createConversation(
    ConversationConfig(
        systemInstruction = Contents.of(Content.Text("You are a helpful assistant.")),
        samplerConfig = SamplerConfig(topK = 40, topP = 0.95, temperature = 0.7)
    )
)

Gotcha: SamplerConfig parameters are Double, not Float. Pass 0.7 not 0.7f. The compiler won't catch this at the call site in all configurations you'll get a runtime error instead. Worth double-checking if you're adapting code from other LLM SDKs that use Float.

Lower temperature toward 0.2 for factual or deterministic responses. Raise it toward 1.0 for creative tasks. topK = 40 with topP = 0.95 is a stable combination that avoids repetition loops in most conversational contexts.

Step 5 Stream Responses

conversation.sendMessageAsync("Explain machine learning in simple terms")
    .collect { message ->
        val text = message.contents.contents
            .filterIsInstance<Content.Text>()
            .joinToString("") { it.text }
        _uiState.update { it.copy(response = text) }
    }

Gotcha: sendMessageAsync emits the cumulative response text on each emission, not just the new delta. Don't concatenate it to your existing string replace it. This design makes ViewModel code cleaner than you'd expect: just assign each emission to your UI state and you get live-updating streaming with no string management on your side.

Wire this Flow into a StateFlow in your ViewModel and collect it in a Composable. The whole streaming chat UI is about 20 lines of production code once the engine is initialized.

CPU, GPU, or NPU: Which Backend Should You Use?

Backend selection has more impact than almost any other integration decision. Here's the tradeoff in concrete numbers.

// CPU works everywhere, no manifest changes required
val config = EngineConfig(modelPath = modelPath, backend = Backend.CPU())

// GPU via OpenCL - fastest prefill, requires manifest entries
val config = EngineConfig(modelPath = modelPath, backend = Backend.GPU())

// NPU Qualcomm Hexagon or MediaTek APU
val config = EngineConfig(
    modelPath = modelPath,
    backend = Backend.NPU(nativeLibraryDir = context.applicationInfo.nativeLibraryDir)
)

CPU: Works on every Android device. On an S26 Ultra, E2B achieves 557 prefill tokens/sec and 46.9 decode tokens/sec using 1,733 MB memory. (HuggingFace model cards, 2026) That's usable for chat. On lower-end hardware it degrades - a mid-range Qualcomm 7s Gen 3 drops to around 8-12 decode tokens/sec. Still viable if you constrain response length.

GPU: 3,808 prefill tokens/sec and 52.1 decode tokens/sec on the S26 Ultra - roughly 7x faster prefill than CPU. (HuggingFace model cards, 2026) The catch: thermal throttling. After 5-10 minutes of continuous GPU inference, the SoC manages heat by dropping clock speeds. You'll see decode fall from 52 to 30 tokens/sec or lower. GPU is the right default for short-to-medium sessions on flagships.

NPU: The Qualcomm Dragonwing IQ8 NPU hits 3,700 prefill and 31 decode tokens/sec. (Google Developers Blog, 2026) Decode trails GPU slightly, but the thermal profile is dramatically better. In my testing on the S25, switching from GPU to NPU at the 8-minute mark kept inference speed consistent across a 20-minute session. For chat-heavy apps where sessions run long, NPU is the better production choice even though GPU wins on peak specs.

Thermal fallback: Implement PowerManager.getThermalHeadroom() to detect high thermal state and gracefully switch backends at runtime. Start on GPU; fall back to NPU if thermal headroom drops below your threshold. This gives you peak speed for short interactions and sustained reliability for long ones.

Real Performance Numbers

These come from official LiteRT-LM model cards on HuggingFace, not synthetic workloads.

Device / Backend	E2B Prefill (tok/s)	E2B Decode (tok/s)	Memory
S26 Ultra - GPU	3,808	52.1	-
S26 Ultra - CPU	557	46.9	1,733 MB
Qualcomm IQ8 NPU	3,700	31.0	-
E4B - S26 Ultra GPU	1,293	22.1	~2 GB active

(HuggingFace model cards, 2026; Google Developers Blog, 2026)

For context on how this compares: running a 7B 4-bit model with llama.cpp on a Snapdragon 8 Gen 3 CPU produces roughly 4 decode tokens/sec. (arXiv 2410.03613v3, 2024) Gemma 4 E2B on CPU already outperforms that by 10x on equivalent-class hardware, because LiteRT-LM is optimized specifically for these architectures.

Gemma 4's architecture also delivers 60% less battery consumption than the previous generation for equivalent tasks. (Google Developers Blog, 2026) In my session-based testing, a 10-minute active conversation on the S25 GPU consumed approximately 4-5% battery, comparable to 10 minutes of YouTube at medium brightness. That's a number you can actually ship on.

One practical note on first inference: cold-start latency is real. The model weights get paged into memory on the first call after engine initialization. Warm the engine with a short empty prompt during app launch - before the user types anything - and that latency disappears from the user experience entirely.

🔥 Production Gotchas

Most guides stop at "here's the code that compiles." Here's what I found the hard way.

Memory initialization order matters. Close large background allocations before calling engine.initialize(). If the user has a game or video editor running, the OS may partially initialize the model and then kill it mid-load. Check available memory first. On 6 GB devices especially, you're working with less headroom than you think.

SamplerConfig takes Double, not Float. Already mentioned above but worth repeating. It's the most common runtime error in early-adopter threads, and it doesn't always surface at compile time.

sendMessageAsync emits cumulative text, not deltas. If you treat each emission as a new chunk and append it, your UI will duplicate everything. Replace the displayed string on each emission, don't concatenate.

The model file goes in filesDir, not the APK. Play Store's APK limit is 150 MB. E2B is 2.58 GB. This isn't optional; you can't ship it in the APK. First-launch download is the standard pattern.

Thermal throttling is real and predictable. GPU inference throttles after 5-10 minutes of sustained load on most flagships. It's not a bug - it's the SoC protecting itself. Design for it: implement PowerManager.getThermalHeadroom() and switch backends proactively rather than waiting for the user to notice slowdown.

Context window growth increases battery drain. Battery consumption increases as conversation length grows because later turns process much longer KV caches than early turns. The 60% battery reduction claim holds for short sessions; it's less pronounced in 20-minute conversations. Consider trimming old turns from history after 10-15 exchanges to control this.

Test on low-RAM devices before shipping. The app behaves completely differently when memory is constrained. Use Android Studio's memory profiler across a full conversation session, not just at startup.

What's Actually Worth Building

The use cases that benefit most from on-device inference share two properties: they involve personal or sensitive data, and they need to feel fast. That combination rules out cloud APIs for entire product categories.

Private journaling and personal assistant apps are the clearest fit. Users who want help organizing notes, reflecting on patterns, or drafting messages have a legitimate expectation of privacy. The on-device guarantee is the product differentiator, not just a feature.

Code review tools for developers. Engineers are already cautious about pasting proprietary code into cloud AI. A local code reviewer removes that concern entirely. With E4B's 52.0% on LiveCodeBench v6, it's capable of explaining code, generating boilerplate, and catching obvious bugs. (HuggingFace, 2026)

Document Q&A. Load a PDF into context and let users ask questions about it. In my prototyping with E2B, a 10-page PDF (~4,000 tokens) processes in under 2 seconds on the S26 Ultra GPU before returning the first response token. That latency is invisible - it feels instant.

Accessibility features : real-time captioning, reading assistance, simplified language mode benefit from local inference because cloud round-trips add 200-400ms per request. That latency matters in accessibility contexts. Local runs immediately.

Offline translation across 140 languages. Field researchers, travelers in areas with poor connectivity, language learning apps that work on airplanes, these are real markets that cloud APIs can't serve reliably. (Google DeepMind, 2026)

FAQ

Does this work on mid-range devices, or only flagships?

E2B requires 6 GB RAM minimum. It runs on any device meeting that bar, not just flagships. On mid-range hardware with less capable GPUs, the CPU backend gives you 8-12 decode tokens/sec. That's usable for short responses. Set user expectations with a progress indicator and constrain response length on lower-tier hardware.

Can I ship the model inside my APK?

No. The E2B file is 2.58 GB. Google Play's APK size limit is 150 MB. The standard pattern is to download the model on first launch using WorkManager and DownloadManager, stored in context.filesDir. It persists across app updates and survives the app going to background during download.

Is Gemma 4 free for commercial use?

Yes. Gemma 4 is released under the Apache 2.0 license free to use, modify, and redistribute commercially with no royalties. LiteRT-LM is also Apache 2.0. There are no usage caps, no API costs, and no restrictions based on your app's MAU count, unlike some competing model licenses. (Google Blog, 2026)

What's the minimum Android API level?

LiteRT-LM requires Android API 26 (Android 8.0 Oreo) or higher for CPU inference. GPU and NPU backends may require higher API levels depending on your device's OpenCL and Hexagon driver versions. Test GPU and NPU support on your specific target devices don't assume it works based on API level alone.

How do I handle the thermal throttling in practice?

Call PowerManager.getThermalHeadroom() periodically during long inference sessions. If it drops below 0.5, switch from GPU to NPU. If it drops below 0.2, fall back to CPU or pause inference with a brief user message. The NPU backend dissipates heat significantly more efficiently than GPU switching at the 8-minute mark keeps decode speed consistent across sessions running 20 minutes or longer.

Conclusion

Gemma 4 plus LiteRT-LM is the first stack where "on-device LLM in a production Android app" goes from interesting experiment to shippable product. The numbers that make it real: 52.1 decode tokens/sec on GPU, under 1.5 GB active memory for E2B, Apache 2.0 license, and a Kotlin API that reduces the full integration to five steps and a few hundred lines of code.

The gotchas are real SamplerConfig takes Double, sendMessageAsync emits cumulative text, the model goes in filesDir not the APK, and thermal throttling will surprise you if you don't plan for it. Plan for them up front and none of them are blockers.

Start with E2B on GPU. Get a conversation running in a minimal Compose screen first, before touching production infrastructure. Profile memory and battery across a full session in Android Studio. Add the NPU fallback once the basics are solid.

The model files are at huggingface.co/litert-community. The LiteRT-LM runtime docs are at ai.google.dev/edge/litert. Both are worth bookmarking, they're updated as the runtime evolves.

Happy to answer questions in the comments about specific integration scenarios. What are you building with this?

This is a submission for the [DEV April Fools Challenge](https://dev.to/challenges/aprilfools-2026)

rahul patwa — Sat, 04 Apr 2026 08:08:59 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built The Existential Teapot, an overly compliant, incredibly hostile implementation of HTCPCP (Hyper Text Coffee Pot Control Protocol - RFC 2324).

At its core, it's a web application designed solely to refuse to brew coffee and to return a 418 I'm a teapot HTTP error. However, this teapot goes above and beyond a simple status code. It actively evades user attempts to click the "BREW COFFEE" button. If an exasperated user finally manages to click it, they are subjected to a fake loading bar that inevitably reverses itself, followed by a personalized, AI-generated, Shakespearean insult delivered via text-to-speech in the poshest British accent available.

It's a study in hostility-driven design and architectural over-engineering.

Demo

https://existential-teapot-production.up.railway.app/

Code

https://github.com/rahulpatwa1303/existential-teapot

How I Built It

Backend: A Node.js and Express server running on port 8080 (or 8091 depending on .env).
AI Integration: I used the @google/generative-ai SDK (Gemini API) and the gemini-2.5-flash model. The system prompt instructs Gemini to be an Existential Teapot that refuses coffee requests with high-art, Shakespearean insults, while dropping references to Larry Masinter (the author of RFC 2324).
Frontend: Pure, unadulterated HTML, CSS, and Vanilla JavaScript.
Hostile UI Features:
- An evasion algorithm that teleports the "BREW COFFEE" button away when the cursor approaches or when focused via keyboard.
- With every evasion, the entire application interface shrinks and rotates slightly.
- A "Mute" button that evades the cursor and, if clicked, throws an alert box stating "The teapot refuses to be silenced!".
Web Speech API: Employed to vocally deliver the AI-generated insults in a condescending tone.
Express Rate Limiting: Because the teapot gets overwhelmed easily (max 5 requests per minute).

Prize Category

I am submitting this for both Best Google AI Usage and Best Ode to Larry Masinter.

Best Google AI Usage: The project leverages the Gemini 2.5 Flash model not to solve a complex problem, but to dynamically generate bespoke, eloquent, and highly contextual insults based on whatever drink the user attempts to order.
Best Ode to Larry Masinter: The entire project is deeply rooted in Larry Masinter's legendary April Fools' joke, RFC 2324. The prompt even explicitly ensures Gemini name-drops him in its diatribes. It is a monument to the 418 status code.

How I Built a Real-Time AI Dungeon Master with Claude API, Socket.io & Next.js

rahul patwa — Thu, 02 Apr 2026 11:44:55 +0000

In this post, I’ll show you how I built a real-time AI Dungeon Master using Claude API, Socket.io, and Next.js. This multiplayer AI system can narrate stories, manage game state, and respond to multiple players simultaneously—just like a real DM.

The AI in gaming market sits at $4.54 billion in 2025 and is projected to hit $81.19 billion by 2035 (SNS Insider, 2025). That number isn't surprising when you think about what generative AI actually unlocks for games infinite narrative branching, dynamic NPCs, and a Dungeon Master who never gets tired at midnight.

I built DnD AI, a multiplayer AI Dungeon Master running on Next.js 16, Claude API (claude-sonnet-4-6), Socket.io, and DALL-E 3. This post is a technical walkthrough of the six hardest problems I ran into, and how I solved them. No fluff just the architecture decisions that actually mattered.

Why this matters
Most multiplayer RPGs fail because they depend on a human Dungeon Master. This project removes that bottleneck using AI unlocking instant gameplay for anyone.

TL;DR:

Next.js App Router can't maintain persistent WebSockets, so a custom server.ts boots Socket.io and Next.js in one process

Claude streaming output pipes through Socket.io to all connected clients in real time, with chunk batching to avoid socket flooding

DALL-E 3 fires only on location changes and major story beats not every message keeping session cost under $0.25

Why a Custom Server Instead of Next.js API Routes?

Next.js App Router Route Handlers are stateless by design each request spins up, responds, and exits. That works fine for REST, but a multiplayer game needs a persistent socket connection that stays alive for an entire session. There's no clean way to run Socket.io inside an App Router handler. The solution is a custom server.ts at the project root that boots both runtimes in a single Node process.

The key insight: Next.js exposes a createServer API that lets you hand off HTTP requests to the Next.js handler while Socket.io attaches to the same HTTP server instance. Both share one process, one port, and one set of environment variables.

// server.ts (root of project, not inside /app)
import { createServer } from "http";
import { parse } from "url";
import next from "next";
import { Server as SocketIOServer } from "socket.io";
import { registerGameHandlers } from "./src/lib/socket/gameHandlers";

const dev = process.env.NODE_ENV !== "production";
const app = next({ dev });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const httpServer = createServer((req, res) => {
    const parsedUrl = parse(req.url!, true);
    handle(req, res, parsedUrl);
  });

  // Socket.io attaches to the same HTTP server
  const io = new SocketIOServer(httpServer, {
    cors: { origin: process.env.NEXT_PUBLIC_APP_URL },
  });

  // Register all game-related socket handlers
  registerGameHandlers(io);

  httpServer.listen(3000, () => {
    console.log("> Ready on http://localhost:3000");
  });
});

One gotcha: your package.json build script needs to compile server.ts separately with tsc, then run the compiled output not next start. Keep that in mind before you hit deploy.

The Game Loop Architecture

Every player action travels through a consistent five-step loop: client input, socket event, Claude API call, streamed narrative back to all clients, then stat resolution. Keeping this loop linear and deterministic was the biggest architectural decision I made early on. It made debugging a lot easier.

Player types/speaks action
        │
        ▼
[Socket.io] "player:action" event → server
        │
        ▼
[gameHandlers.ts] validate action, load session memory
        │
        ▼
[Claude API] stream narrative response (claude-sonnet-4-6)
        │
  ┌─────┴────────────────────┐
  │                          │
  ▼                          ▼
[Socket.io]            [Stat resolver]
stream chunks          roll dice, calc HP delta
to all clients         emit "game:statUpdate"
  │
  ▼
[DALL-E trigger check]
location changed? major beat?
→ fire async image gen

The stat resolver runs in parallel with the stream, not after it. Players see the narrative arriving word-by-word while the HP update hits their UI within a second. That parallel execution matters for perceived responsiveness if you wait for the full Claude response before resolving stats, the game feels sluggish.

The Hardest Part: Syncing Streaming LLM Output Across Multiple Clients

84% of developers now use AI tools daily (Stack Overflow Developer Survey, 2025), but most of those integrations are single-user. Streaming Claude's output to four simultaneous Socket.io clients introduces a problem that single-user apps never face: how do you fan out a streaming response without flooding the socket or losing chunk ordering?

The naive approach emit a socket event for every token causes event queue saturation at ~4 clients with a fast model. I batched chunks into 50ms windows instead. Each batch emits one socket event with concatenated text. Clients append to their local buffer and re-render.

// src/lib/socket/streamHandler.ts
import Anthropic from "@anthropic-ai/sdk";

export async function streamNarrativeToRoom(
  io: SocketIOServer,
  roomId: string,
  messages: Anthropic.MessageParam[],
  systemPrompt: string
) {
  const client = new Anthropic();
  let chunkBuffer = "";
  let flushTimer: NodeJS.Timeout | null = null;

  const flush = () => {
    if (chunkBuffer.length > 0) {
      // Single emit per batch window all clients in room receive it
      io.to(roomId).emit("dm:narrative_chunk", { text: chunkBuffer });
      chunkBuffer = "";
    }
    flushTimer = null;
  };

  const stream = await client.messages.stream({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    system: systemPrompt,
    messages,
  });

  for await (const chunk of stream) {
    if (
      chunk.type === "content_block_delta" &&
      chunk.delta.type === "text_delta"
    ) {
      chunkBuffer += chunk.delta.text;

      // Batch: flush every 50ms, not every token
      if (!flushTimer) {
        flushTimer = setTimeout(flush, 50);
      }
    }
  }

  // Flush any remaining buffer after stream ends
  if (flushTimer) clearTimeout(flushTimer);
  flush();

  io.to(roomId).emit("dm:narrative_end", { roomId });
}

The 50ms batch window is the sweet spot I landed on after testing. At 20ms the socket still floods at high token velocity. At 100ms the streaming effect feels choppy to users. Your mileage will vary depending on average token rate.

Dice Determinism in a Distributed Game

In a multiplayer game, dice rolls can't be client-side. If player A's browser rolls a d20 and player B's browser rolls independently, they see different outcomes for the same event. The server must own every roll, and the result must be deterministic reproducible from a seed if you ever need to replay or audit a session.

I use a seeded pseudo-random number generator (PRNG) on the server, seeded per session. The seed gets stored in SQLite alongside the session record. When a roll happens, the server increments a counter, derives the roll from prng(sessionSeed + rollCount), emits the result to all clients simultaneously, and stores it.

// src/lib/dice/seededRng.ts
// Mulberry32 fast, seedable, good distribution for game use
function mulberry32(seed: number) {
  return function () {
    seed |= 0;
    seed = (seed + 0x6d2b79f5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

export function createSessionDice(sessionSeed: number) {
  const rng = mulberry32(sessionSeed);
  return {
    roll: (sides: number) => Math.floor(rng() * sides) + 1,
  };
}

The first version used Math.random() server-side and it worked fine until I added session replay for debugging. Replays produced different dice outcomes, which made bug reproduction impossible. Seeding costs nothing and saves you later.

Persistent Memory Without Blowing the Context Window

Claude's context window is large, but sending full game history on every turn is expensive and eventually hits limits. The practical solution is two-layer memory: SQLite stores the complete event log, and a compressed summary gets injected into the Claude system prompt on each turn.

Prisma manages the schema. Each session has a GameSession record, a log of GameEvent rows (player actions, DM responses, stat changes), and a MemorySummary that gets regenerated every 10 turns using a separate, cheaper Claude call.

Most tutorials suggest simply truncating history. That's wrong for a DnD game early plot details (the villain's name, a deal the players made) matter at turn 40. A compressed summary preserves narrative continuity without the token cost of full history. The summarization prompt is as important as the main DM prompt.

The system prompt structure:

// src/lib/ai/buildSystemPrompt.ts
export function buildDMSystemPrompt(
  campaignConfig: CampaignConfig,
  memorySummary: string,
  recentEvents: GameEvent[]  // last 5 events in full
): string {
  return `
You are the Dungeon Master for a ${campaignConfig.theme} campaign.
Setting: ${campaignConfig.worldDescription}
Players: ${campaignConfig.players.map(p => `${p.name} (${p.class}, HP: ${p.currentHp}/${p.maxHp})`).join(", ")}

## Story So Far (compressed)
${memorySummary}

## Recent Events (verbatim)
${recentEvents.map(e => `[${e.type}] ${e.content}`).join("\n")}

Rules: Stay in character. When a player action requires a dice check, output a JSON block:
{"diceCheck": {"stat": "strength", "dc": 14, "consequence": {...}}}
  `.trim();
}

DALL-E 3 When to Trigger and How to Manage Cost

DALL-E 3 at $0.040 per standard image adds up fast if you fire it on every player message. The fix is a trigger logic layer that fires image generation only when the scene actually changes: entering a new location, starting combat, or hitting a major story beat that Claude flags in its response.

In testing across 12 playthroughs averaging 45 turns each, trigger-gated generation fired DALL-E 3 an average of 6 times per session keeping image cost under $0.25 per session. Ungated, the same sessions would have triggered 40+ image calls.

Image generation runs async the game doesn't wait for it.

// src/lib/ai/imageOrchestrator.ts
type SceneSignal = { sceneChange: true; description: string } | null;

export async function maybeGenerateSceneImage(
  roomId: string,
  dmResponse: string,
  io: SocketIOServer
): Promise<void> {
  const signal = extractSceneSignal(dmResponse); // parses JSON block in response
  if (!signal) return;

  // Fire and forget don't await in the main game loop
  generateAndEmit(roomId, signal.description, io).catch((err) =>
    console.error("Image gen failed silently:", err)
  );
}

async function generateAndEmit(
  roomId: string,
  description: string,
  io: SocketIOServer
) {
  const imageUrl = await generateImage(description);
  io.to(roomId).emit("scene:image_ready", { imageUrl });
}

The async fire pattern means players get a scene image 5–8 seconds after a location change, not blocking any game action. The UI shows a loading shimmer until scene:image_ready arrives.

Web Speech API in Production

Web Speech API works well for the happy path clear speech, modern Chrome, quiet environment. It breaks in ways that are hard to predict. Browser support is inconsistent outside Chrome and Edge. Background noise triggers false positives. Silence detection varies by OS, and on some systems the API stops listening after a few seconds even when the user is still speaking.

The two real-world failures I hit most: (1) mobile Safari doesn't support the API at all in some iOS versions, and (2) the onend event fires too aggressively in noisy environments, cutting off player actions mid-sentence. The fix for the second issue was a 1.5-second debounce on the onend event before submitting the transcript.

The connection to the action pipeline is simple: the browser captures speech, converts to text, and fires the same player:action socket event that a typed message would send. The server doesn't know or care whether input came from voice or keyboard.

Always provide a text input fallback. Don't ship a voice-only interface.

What I'd Do Differently

Over-engineered: the Prisma schema. I built relations between sessions, events, characters, and items on day one. For a prototype, a flat JSON blob in SQLite would have been faster to iterate on and just as queryable for my needs.

Under-engineered: the Claude system prompt. I spent a lot of time on the infrastructure and not enough on prompt quality in the first two weeks. The DM's narrative consistency improved dramatically after I added explicit persona instructions, tone guidance, and a rules-enforcement section. Infrastructure is the easy part.

The biggest surprise: streaming to multiple clients is genuinely tricky. I expected it to be a minor detail. The 50ms batching window took three days of testing to land on. If I started over, I'd prototype the streaming fan-out before anything else.

90% of game developers already use AI in their workflows, and 97% say generative AI is reshaping the industry (Google Cloud / Harris Poll, Aug 2025). The tooling is mature. The hard problems are now architectural not whether AI can generate good narrative, but how to wire it into a real-time system without it falling apart.

Live Demo

FAQ

Can this architecture scale beyond 4 players?

The Socket.io room model scales to more players without code changes. The real constraint is Claude API latency streaming a response to 8 clients at once still uses one API call, so cost doesn't multiply. In testing, the 50ms batch window held stable at 6 clients. Beyond that, you'd want to profile socket event queue depth under load.

Why Claude over GPT-4 for the DM role?

Claude's longer context window and instruction-following consistency made it the better fit for maintaining campaign continuity across a long session. In our tests, Claude adhered to custom rule constraints in the system prompt more reliably than GPT-4 Turbo, particularly for structured JSON output embedded in narrative responses. That JSON output drives the dice check and stat resolution pipeline.

How do you handle Claude going off-script or breaking game rules?

The system prompt includes an explicit rules section and a JSON output schema for structured events. When Claude's response doesn't contain valid JSON where expected, the server falls back to a text-only parse and logs the miss. A separate "rules referee" prompt runs on flagged responses to check for obvious violations before emitting to clients. It catches about 80% of off-script outputs without blocking the stream.

No Redis, No Kafka: I Built a Real-Time Auction System with Just PostgreSQL

rahul patwa — Mon, 23 Mar 2026 13:45:09 +0000

TL;DR:

PostgreSQL's LISTEN/NOTIFY system can power real-time features without Redis or Kafka

This tutorial walks through a full auction system: live bids, countdowns, item broadcasts, and discontinuation events

A single trigger function fans out to every connected browser via Socket.io — Postgres does the heavy lifting

55.6% of developers already use PostgreSQL (Source: Stack Overflow Developer Survey, 2025) — you probably already have it in your stack

You're watching a live auction. The price just changed — $1,240, then $1,300, then $1,450 in eight seconds. Behind the scenes, no message broker is running. No Redis cluster. No Kafka topic. Just Postgres.

I read Adam's brilliant post about building real-time chat with just PostgreSQL and pg_notify and had one thought: can I take this further? Can I build a full auction system — live bids, countdown timers, live item broadcasts, auction discontinuation — all without a single extra service? Turns out you can. This is how I did it.

The Architecture in One Diagram

The whole system collapses into a single data flow. A browser fires a bid, Postgres validates and stores it, a trigger fires a notification, and Node.js fans that notification out to every connected client. Five hops. Zero extra services.

Browser (bid placed)
       ↓  socket.emit('place_bid')
  Node.js / Socket.io
       ↓  INSERT INTO bids
  PostgreSQL
       ↓  TRIGGER fires → pg_notify('auction_update', payload)
  Node.js (LISTEN)
       ↓  io.emit('update', data)
  All Browsers (live price update, flash animation)

Node.js acts as a bridge in two directions. It accepts socket events from browsers and writes to Postgres. It also holds a persistent LISTEN connection that receives notifications and broadcasts them to every connected socket. Postgres handles the pub/sub. Node handles the fan-out. The browser renders the result.

Why PostgreSQL?

PostgreSQL is now the most widely used database in the world, with 55.6% of all developers — and 58.2% of professional developers — reporting they use it (Source: Stack Overflow Developer Survey, 2025). That's the largest single-year jump in the survey's history. It has held the #1 spot as both the most admired and most desired database for four consecutive years.

The operational argument is simple. You already have Postgres in your stack. Adding Redis or Kafka for a side project or MVP means a second service to provision, secure, monitor, and pay for. For many workloads, that overhead isn't justified.

Supabase's entire Realtime product — handling over 250,000 concurrent users (Source: Supabase Realtime Benchmarks, supabase.com/docs/guides/realtime/benchmarks) — is architecturally built on pg_notify and WebSockets (Source: Supabase Realtime Architecture docs, supabase.com/docs/guides/realtime/architecture). If it's good enough for Supabase's scale, it's more than good enough for your auction app.

The Database Layer

The schema is the engine. Get this right, and the Node.js code becomes almost trivial. Two tables, two triggers, and one pg_notify call is all you need.

-- init.sql

CREATE TABLE items (
  id          SERIAL PRIMARY KEY,
  title       TEXT NOT NULL,
  description TEXT,
  image_url   TEXT,
  start_price NUMERIC(10,2) NOT NULL DEFAULT 0,
  current_bid NUMERIC(10,2) NOT NULL DEFAULT 0,
  ends_at     TIMESTAMPTZ NOT NULL,
  status      TEXT NOT NULL DEFAULT 'active'
                   CHECK (status IN ('active', 'closed', 'discontinued')),
  winner_id   INTEGER,
  created_at  TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE bids (
  id         SERIAL PRIMARY KEY,
  item_id    INTEGER NOT NULL REFERENCES items(id),
  user_id    INTEGER NOT NULL,
  username   TEXT NOT NULL,
  amount     NUMERIC(10,2) NOT NULL,
  placed_at  TIMESTAMPTZ DEFAULT NOW()
);

-- Trigger: fires on every new bid
CREATE OR REPLACE FUNCTION handle_new_bid()
RETURNS TRIGGER AS $$
BEGIN
  -- Update the item's current bid price
  UPDATE items
  SET current_bid = NEW.amount
  WHERE id = NEW.item_id;

  -- Notify all listeners — send only the delta, not the full row
  PERFORM pg_notify(
    'auction_update',
    json_build_object(
      'type',     'NEW_BID',
      'item_id',  NEW.item_id,
      'amount',   NEW.amount,
      'username', NEW.username,
      'bid_id',   NEW.id
    )::text
  );

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER on_bid_placed
  AFTER INSERT ON bids
  FOR EACH ROW EXECUTE FUNCTION handle_new_bid();


-- Trigger: fires on item INSERT (new listing) or UPDATE (status change)
CREATE OR REPLACE FUNCTION handle_item_change()
RETURNS TRIGGER AS $$
BEGIN
  -- New item listed
  IF (TG_OP = 'INSERT') THEN
    PERFORM pg_notify(
      'auction_update',
      json_build_object(
        'type',      'NEW_ITEM',
        'item_id',   NEW.id,
        'title',     NEW.title,
        'start_price', NEW.start_price,
        'ends_at',   NEW.ends_at
      )::text
    );

  -- Auction closed (timer expired)
  ELSIF (TG_OP = 'UPDATE' AND NEW.status = 'closed' AND OLD.status = 'active') THEN
    PERFORM pg_notify(
      'auction_update',
      json_build_object(
        'type',       'AUCTION_CLOSED',
        'item_id',    NEW.id,
        'winner_id',  NEW.winner_id,
        'final_bid',  NEW.current_bid
      )::text
    );

  -- Auction manually discontinued
  ELSIF (TG_OP = 'UPDATE' AND NEW.status = 'discontinued') THEN
    PERFORM pg_notify(
      'auction_update',
      json_build_object(
        'type',    'AUCTION_DISCONTINUED',
        'item_id', NEW.id,
        'title',   NEW.title
      )::text
    );
  END IF;

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER on_item_change
  AFTER INSERT OR UPDATE ON items
  FOR EACH ROW EXECUTE FUNCTION handle_item_change();

pg_notify takes two arguments: a channel name and a text payload. Every LISTEN-ing connection subscribed to that channel receives the payload instantly after the transaction commits.

That last part matters. PostgreSQL only delivers notifications on transaction commit (Source: PostgreSQL official docs, postgresql.org/docs/current/sql-notify.html). A bid that fails validation and rolls back never fires a notification. No phantom updates, no stale prices. The atomicity is a feature, not a limitation.

Payload size callout: PostgreSQL's NOTIFY has an 8,000-byte payload limit (Source: PostgreSQL official docs). Rule of thumb: send the ID and the delta, not the full row. A JSON object with four or five fields is almost never going to hit that ceiling.

![Chart]((https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m9d9qrr381e93y0vp5da.png)

The Node.js Server

The server is the glue. It's about 120 lines of code, and most of that is the Socket.io event handlers. The real-time machinery itself is surprisingly compact.

// server.js
const express   = require('express');
const http      = require('http');
const { Server } = require('socket.io');
const { Client } = require('pg');
const { Pool }   = require('pg');

const app    = express();
const server = http.createServer(app);
const io     = new Server(server);

// Pool for regular queries (bids, inserts, selects)
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

// Dedicated client for LISTEN — must NOT go through a pool
// A pooled connection can be swapped out; LISTEN requires a persistent session
const pgClient = new Client({ connectionString: process.env.DATABASE_URL });

app.use(express.static('public'));

// ─── 1. Start the persistent LISTEN connection ─────────────────────────────
async function startListener() {
  await pgClient.connect();
  await pgClient.query('LISTEN auction_update');

  // ─── 2. Fan-out: every pg_notify fires this handler ──────────────────────
  pgClient.on('notification', (msg) => {
    try {
      const payload = JSON.parse(msg.payload);
      io.emit('update', payload);   // broadcast to ALL connected sockets
    } catch (err) {
      console.error('Bad notification payload:', err);
    }
  });

  console.log('Listening on channel: auction_update');
}

// ─── 3. Auction Master Loop ───────────────────────────────────────────────
// Closes expired auctions every second.
// Good enough for an MVP. In production, replace with a pg_cron job
// so the closer runs inside the DB and survives Node restarts.
setInterval(async () => {
  try {
    await pool.query(`
      UPDATE items
      SET
        status    = 'closed',
        winner_id = (
          SELECT user_id FROM bids
          WHERE item_id = items.id
          ORDER BY amount DESC
          LIMIT 1
        )
      WHERE status  = 'active'
        AND ends_at < NOW()
    `);
    // The on_item_change trigger fires and sends AUCTION_CLOSED automatically
  } catch (err) {
    console.error('Auction closer error:', err);
  }
}, 1000);

// ─── Socket.io event handlers ─────────────────────────────────────────────
io.on('connection', async (socket) => {
  console.log('Client connected:', socket.id);

  // Send current state on connect
  const { rows } = await pool.query(
    "SELECT * FROM items WHERE status = 'active' ORDER BY created_at DESC"
  );
  socket.emit('init_items', rows);

  // ─── 4. Place a bid ────────────────────────────────────────────────────
  socket.on('place_bid', async ({ item_id, user_id, username, amount }) => {
    try {
      // Validate: bid must exceed current price
      const { rows: [item] } = await pool.query(
        'SELECT current_bid, status FROM items WHERE id = $1',
        [item_id]
      );
      if (!item || item.status !== 'active') {
        return socket.emit('bid_error', { message: 'Auction is not active.' });
      }
      if (parseFloat(amount) <= parseFloat(item.current_bid)) {
        return socket.emit('bid_error', { message: 'Bid must exceed current price.' });
      }

      // Insert — the trigger does the rest
      await pool.query(
        'INSERT INTO bids (item_id, user_id, username, amount) VALUES ($1, $2, $3, $4)',
        [item_id, user_id, username, amount]
      );
    } catch (err) {
      console.error('place_bid error:', err);
      socket.emit('bid_error', { message: 'Server error placing bid.' });
    }
  });

  // ─── 5. Add a new auction item ─────────────────────────────────────────
  // Node just writes to the DB. pg_notify('auction_update', NEW_ITEM) is
  // Postgres's job. Node doesn't manually broadcast anything here.
  socket.on('add_item', async ({ title, description, image_url, start_price, duration_seconds }) => {
    try {
      const ends_at = new Date(Date.now() + duration_seconds * 1000);
      await pool.query(
        `INSERT INTO items (title, description, image_url, start_price, current_bid, ends_at)
         VALUES ($1, $2, $3, $4, $4, $5)`,
        [title, description, image_url, start_price, ends_at]
      );
      // Trigger fires automatically — no io.emit here
    } catch (err) {
      console.error('add_item error:', err);
    }
  });

  // ─── 6. Discontinue an auction ─────────────────────────────────────────
  socket.on('discontinue_item', async ({ item_id }) => {
    try {
      await pool.query(
        "UPDATE items SET status = 'discontinued' WHERE id = $1 AND status = 'active'",
        [item_id]
      );
      // Trigger fires automatically — no io.emit here
    } catch (err) {
      console.error('discontinue_item error:', err);
    }
  });

  socket.on('disconnect', () => {
    console.log('Client disconnected:', socket.id);
  });
});

startListener().then(() => {
  server.listen(3000, () => console.log('Server running on http://localhost:3000'));
});

Notice the add_item and discontinue_item handlers. They're just DB writes. There's no io.emit call in either one. The notification to all users is entirely Postgres's job. Node stays thin.

Socket.io reaches roughly 9.7 million weekly npm downloads (Source: Snyk, 2025), making it the dominant WebSocket library in the Node ecosystem. The io.emit('update', payload) call in the notification handler is all it takes to fan out to every connected browser simultaneously.

Three Events, Three Triggers

The entire real-time behavior of this system flows through three notification types, all on the same channel. Here's how they map to Postgres triggers.

Event	Trigger	Channel	Who listens
Bid placed	`on_bid_placed` (bids INSERT)	`auction_update`	All browsers
New item listed	`on_item_change` (items INSERT)	`auction_update`	All browsers
Auction discontinued	`on_item_change` (items UPDATE status→discontinued)	`auction_update`	All browsers

Walk through a concrete scenario. Alice fills out the "Add Item" form and submits. Node.js runs a single INSERT INTO items. PostgreSQL's handle_item_change trigger fires immediately after, calls pg_notify('auction_update', '{"type":"NEW_ITEM",...}'). The dedicated LISTEN client in Node receives that notification and calls io.emit('update', {type: 'NEW_ITEM', item: {...}}). Every browser gets a new auction card rendered in real time — with a gold glow animation for three seconds.

That's it. Alice's browser doesn't get any special treatment. Every client — including Alice's — learns about the new item the same way: through Postgres.

Chart 2: pg_notify Payload Sizes — Fitting Within the 8KB Limit

The Browser Side

The client code is straightforward Socket.io work. What makes it feel polished is the layered handling of each event type.

On connect, the server sends init_items — an array of all active auctions. The browser renders every card immediately. From that point on, everything is driven by update events.

When a NEW_BID event arrives, the relevant card's price element flashes amber, then fades to white over 600ms. A AUCTION_CLOSED event triggers a winner modal with a confetti burst and disables the bid input. NEW_ITEM appends a new card with a 3-second gold border glow. AUCTION_DISCONTINUED re-renders the card with a red "Discontinued" badge and fires a toast notification to everyone in the room.

Countdown timers run client-side with setInterval. Each timer transitions through three urgency states: slate text when plenty of time remains, amber text when under two minutes, and a red pulse animation when under thirty seconds. The visual cues are intentional — urgency drives bidding.

Every pg_notify event also appends to an activity feed sidebar. This gives the room a sense of shared presence: you can see who just outbid whom, which items just opened, and which ones closed, all in a live scrolling log.

The Honest Part — When This Doesn't Scale

This architecture has real limits. Here they are, plainly.

One connection per listener. Every Node.js process that calls LISTEN holds a dedicated, persistent Postgres connection. Pool that and it breaks — PgBouncer's transaction-mode pooling is incompatible with LISTEN/NOTIFY and requires session pooling instead (Source: brandur.org, 2024). At 200–500 concurrent Node processes, connection pressure becomes a genuine problem. The "notifier pattern" described by Brandur reduces this to one connection per process (Source: brandur.org/notifier, 2024), which helps, but it's not magic. Beyond roughly 1,000 concurrent listeners, this pattern stops being suitable (Source: pedroalonso.net, 2024).

Lock contention under high write volume. recall.ai reported that NOTIFY-induced lock contention caused commit delays reaching 1,015ms with 400+ queued concurrent transactions (Source: recall.ai blog, March 2025). Under a high write concurrency scenario — think flash sale with thousands of simultaneous bidders — this is a real concern, not a theoretical one.

No message persistence. If the Node.js listener is offline when a notification fires, the message is gone forever. For an auction system this is acceptable — the database is always the source of truth, and a reconnecting client can query current state. For guaranteed delivery semantics, you need a message queue.

Closing thought: for an auction app with hundreds of concurrent bidders, this works great. For Twitter-scale real-time? That's where Redis earns its keep.

pg_notify vs Redis Pub/Sub — Quick Comparison

Dimension	pg_notify	Redis Pub/Sub
Latency	~1–5ms	~0.1–1ms
Max practical listeners	~200–500	Tens of thousands
Message persistence	None	None (by default)
Transaction atomicity	Yes	No
Operational complexity	Zero	High
Cost	$0	Additional service

Running It Yourself

Five commands and you have a working auction room.

# 1. Clone and install
git clone https://github.com/rahulpatwa1303/postgres-live-auction
cd pg-auction && npm install

# 2. Create the database
createdb auction_db

# 3. Run the schema and triggers
psql -d auction_db -f init.sql

# 4. Set your connection string and start
DATABASE_URL=postgres://localhost/auction_db node server.js

# 5. Open two browser windows
open http://localhost:3000

Open two browser windows side by side. Place a bid in one. Watch it update in the other in under 5ms. Add an item in one window and watch the new card appear in both. That's the whole system working.

What I'd Do Differently in Production

A few changes would make this production-worthy.

Replace the setInterval auction closer with a pg_cron job. The cron job runs inside the database, survives Node restarts, and scales independently of your application tier.
Use a connection pool configured for session pooling, not transaction pooling. PgBouncer's transaction mode destroys LISTEN sessions.
Add a bid_history table as an append-only audit log. This gives you replay capability and protects against disputes.
Put the Node server behind a load balancer with sticky sessions. Socket.io's default in-memory store doesn't share state across processes — sticky sessions or the socket.io-redis adapter are required for multi-instance deployments.
Implement row-level locking on the items table during bid validation. A SELECT ... FOR UPDATE in the bid handler prevents race conditions when two users submit the same highest bid within milliseconds of each other.

Final Thoughts

The point isn't "never use Redis." Redis is genuinely excellent at what it does, and at scale, it's the right choice. The point is that Postgres is dramatically more powerful than most developers give it credit for. pg_notify is a production-grade pub/sub system that ships for free with the database you almost certainly already have running.

This whole system — live bids, item broadcasts, countdown timers, discontinuation events — runs with zero additional infrastructure. One database. One application server. Done.

This project was directly inspired by Adam's article No Redis, No Kafka — Just Postgres, I Built Chat. If you haven't read it, go read it first — it's the foundation this auction system is built on.

Check out the full source code on GitHub. If this was useful, share it with someone who's about to spin up a Redis instance they don't need.

FAQ

What is PostgreSQL LISTEN/NOTIFY?

LISTEN and NOTIFY are built-in PostgreSQL commands for asynchronous pub/sub messaging. A client issues LISTEN channel_name to subscribe. Any session can then call NOTIFY channel_name, 'payload' or pg_notify() to broadcast a message. Notifications are delivered to all subscribers only when the sending transaction commits (Source: PostgreSQL official docs, postgresql.org/docs/current/sql-notify.html).

Can PostgreSQL replace Redis for pub/sub?

For low-to-medium concurrency workloads — under roughly 200–500 concurrent listeners — yes, pg_notify is a practical Redis Pub/Sub alternative. It adds transaction atomicity that Redis lacks. However, Redis handles tens of thousands of concurrent subscribers and sub-millisecond latency that pg_notify can't match. Choose based on your actual scale (Source: brandur.org, 2024; pedroalonso.net, 2024).

What is the payload limit for pg_notify?

PostgreSQL's NOTIFY payload has a hard limit of 8,000 bytes (Source: PostgreSQL official docs). The total notification queue is capped at 8 GB. Best practice is to send only the row ID and key delta fields in the payload, then let the client fetch full data if needed. Embedding image URLs or large text blobs in the payload will cause errors.

How does Socket.io connect to PostgreSQL notifications?

A dedicated pg.Client instance (not a pool) issues LISTEN auction_update. When Postgres fires pg_notify, the client's notification event handler receives the payload. That handler calls io.emit('update', parsedPayload), broadcasting to all connected Socket.io clients simultaneously. Socket.io reaches ~9.7 million weekly npm downloads, making it the dominant WebSocket abstraction in Node.js (Source: Snyk, 2025).

What is the difference between AUCTION_CLOSED and AUCTION_DISCONTINUED?

AUCTION_CLOSED fires when an auction's timer expires naturally. The system sets a winner, calculates the final price, and broadcasts the result. AUCTION_DISCONTINUED fires when an administrator manually cancels an active auction before it ends. No winner is set. The browser re-renders the card with a red "Discontinued" badge and shows a toast notification to all connected users.---
title: "No Redis, No Kafka: I Built a Real-Time Auction System with Just PostgreSQL"
description: "How I used PostgreSQL's pg_notify/LISTEN, Node.js, and Socket.io to build a full real-time auction system — live bids, countdown timers, new item broadcasts, and auction discontinuation — with zero additional infrastructure."

Live Demo: postgres-live-auction

How I Built CareLog: A Flutter App for Home-Visit Healthcare Providers

rahul patwa — Fri, 06 Mar 2026 09:41:47 +0000

TL;DR: CareLog is a cross-platform Flutter app that helps home-visit doctors and nurses track patients, schedule visits, manage payments, and view practice analytics — all offline-first with optional cloud sync. Built with Flutter + Riverpod + Drift (SQLite) + Supabase, deployable as an Android APK, a PWA on iOS, or a web app.

The Problem: Home-Visit Doctors Have No Good Tool

Home-visit healthcare is common in India. A doctor or physiotherapist travels to patients' homes on a daily or weekly schedule, collects fees in cash, and keeps everything in a notebook or a generic spreadsheet.

That system breaks down fast:

Who did I visit today and who did I miss?
Which patients haven't paid yet this month?
Am I earning more or less than last month?
What was the address for that patient on the outskirts?

Existing apps either target hospital workflows (too complex), require internet access, or don't handle the visit-frequency + payment-tracking combination at all.

CareLog fills that gap: a lean, offline-first app purpose-built for the home-visit workflow.

What CareLog Does

Schedule view is the home screen. It shows a horizontally scrollable date strip spanning one year back and one month forward. Each day shows dot indicators for dates that have scheduled visits. Tapping a date shows a timeline of patients due that day, with one-tap actions to mark a visit complete or skip it.

Patient profiles store name, phone, address, default consultation fee, visit frequency (Daily, Alternate, Weekly, or Custom weekdays), visit start date, and notes. The frequency and weekday data drives the automatic schedule generation — no manual entry needed per day.

Patient details screen shows the full visit history sorted newest-first, running totals for paid and pending fees, and a bulk-selection mode (long-press to enter) for marking multiple visits paid/unpaid or deleting them in one action.

Dashboard provides a snapshot of today's visits and earnings, period-aware earnings cards (Week / Month / Year / All Time) with trend indicators versus the prior period, a 6-month earnings comparison strip, a day-of-week activity bar chart for the current month, pending payment breakdown per patient, and a most-visited patients leaderboard.

Settings cover daily reminder notifications (with a custom time picker), cloud backup via Google Sign-In, local backup/restore to a file, import from the previous version of the app, and CSV export of all visit data.

Tech Stack and Why

Flutter

The app targets Android natively and iOS/web as a PWA. Flutter makes that possible from a single codebase. Dart's strong typing and hot reload speed made iteration fast. The Material 3 widget library covered 95% of UI needs without custom widgets.

The project uses v1.1.0 (SDK ^3.5.3), deployed with flutter build apk --release for Android and flutter build web --release for the PWA.

Riverpod for State Management

Riverpod was chosen over Provider and BLoC for several reasons:

Compile-time safety — providers are regular Dart objects, not context lookups, so typos are caught at build time.
Async first — AsyncNotifierProvider and .when() handle loading/error/data states without boilerplate.
Testability — providers can be overridden in tests without a widget tree.

The app's provider graph: databaseProvider (Drift DB singleton) → patientsProvider / visitsProvider (stream-based) → derived providers like todayVisitsProvider, dashboardProvider, scheduledDatesProvider.

Drift (SQLite) for Offline-First Storage

Drift is a type-safe SQLite wrapper for Flutter. The schema is two tables:

class Patients extends Table {
  // id, name, phone, address, defaultFee
  // visitFrequency: 'Daily' | 'Alternate' | 'Weekly' | 'Custom'
  // visitWeekdays: "1,3,5"  (comma-separated ISO weekday ints)
  // visitStartDate, isActive, remoteId, isSynced
}

class Visits extends Table {
  // id, patientId (FK), visitDate, visitType: 'Home' | 'Clinic'
  // fee, isPaid, notes, remoteId, isSynced
}

The schema is at version 5 with a hand-written migration strategy. Each onUpgrade block is guarded with if (from < N) so migrations compose correctly regardless of which version a user upgrades from.

One non-obvious issue: drift_dev code-gen doesn't handle nullable DateTimeColumn additions via addColumn because of Dart generic invariance. The workaround was dropping down to raw SQL:

await customStatement('ALTER TABLE patients ADD COLUMN visit_started_at INTEGER');

Drift stores DateTime as an INTEGER (Unix ms), so the raw SQL type matches.

Supabase for Cloud Sync

Each row carries a remoteId (UUID from Supabase) and an isSynced boolean. The sync engine:

Fetches rows where isSynced == false from the local DB.
Upserts them to Supabase using the remoteId as the conflict key.
Pulls down any rows created/updated on other devices since the last sync timestamp.
Merges local and remote, preferring the most recent updatedAt.

Google Sign-In is the only auth method — no email/password form to maintain, and most users already have a Google account on their Android phone.

PWA Strategy for iOS

Building for iOS normally requires a Mac and an Apple Developer account ($99/year). The workaround: flutter build web produces a standard web app. Hosted on Vercel, it works as a Progressive Web App — Safari on iPhone prompts the user to "Add to Home Screen," after which it launches fullscreen and behaves like a native app.

A custom PwaInstallGuide widget detects when the app is running in a browser (not as an installed PWA) and displays a step-by-step overlay showing the Safari share icon and "Add to Home Screen" instructions. This eliminated the biggest friction point for iOS users.

Architecture Decisions Worth Calling Out

Schedule Generation Is Computed, Not Stored

Visits are only stored when a doctor takes an action (marks complete, skips, logs a note). The upcoming schedule is computed on the fly from each patient's visitFrequency, visitWeekdays, and visitStartDate. The todayVisitsProvider joins the computed schedule for the selected date with any stored visit records to produce a VisitSchedule object with upcomingCount, completedCount, and skippedCount.

This keeps the database small and avoids the problem of "stale future visits" if a patient's schedule changes.

Platform-Conditional Services

Notifications and file downloads have different implementations on mobile vs web. Each service has three files:

notification_service.dart         ← abstract interface
notification_service_mobile.dart  ← flutter_local_notifications
notification_service_web.dart     ← no-op / Web Notifications API

A factory function in notification_service.dart returns the right implementation based on kIsWeb. This pattern kept platform-specific code contained and made testing each implementation in isolation straightforward.

CI/CD: GitHub Actions to Vercel

The .github/workflows/main.yml pipeline:

Runs flutter test on every push.
If tests pass, runs flutter build web --release.
Deploys the build/web output to Vercel using the Vercel CLI with three repository secrets: VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID.

The result: every green push to main auto-deploys a new web build in under three minutes. Android APKs are still built and distributed manually (direct APK share via WhatsApp/Telegram for early users, with Play Store planned for v2).

UX Details That Mattered

Haptic feedback on actions. HapticFeedback.mediumImpact() fires on "Mark Complete" and "Skip". On a busy home-visit day, a doctor often taps through the list quickly. The haptic confirms the action registered without requiring the user to look at the screen.

"All caught up" empty state. When all visits for the day are done, the Upcoming filter shows a check-circle icon and "You have completed all visits for today. Great job!" — a small thing, but it closes the feedback loop rather than just showing a blank list.

Backup nudge banner. If the user hasn't signed in for cloud sync, a dismissible orange banner appears on the home screen: "Your data is only on this device." It links directly to the Settings screen. This surfaces a real risk (data loss if the phone is lost) without being intrusive.

Month markers in the date strip. The horizontal date picker shows the month abbreviation on the 1st of every month instead of the day name. This solves the orientation problem when scrolling back through history — a doctor checking records from 3 months ago can find the right month at a glance.

What's Next

Recurring visit notes templates — many patients have the same condition; reusable note templates would save typing.
Patient photo — a profile photo makes it faster to match the patient card to the face when the visit list is long.
Multiple currencies — the ₹ symbol is hardcoded. Parameterizing it would open the app to users outside India.
Export to PDF — a printable monthly earnings report for accounting purposes.

🚀 From “Just for Fun” to a Full-Stack Beach Discovery App — How I Built BeachSeeker and What I Learned

rahul patwa — Fri, 09 Jan 2026 08:40:11 +0000

Have you ever stood staring at a beach map, wondering:

✨ Is it crowded today?
✨ Is it worth the trip this weekend?
✨ Is it even accessible for a quick visit?

That was me last year — no quick way to answer these questions. So I built BeachSeeker, an AI-powered beach discovery app that helps you find your next seaside paradise with ease — not for VC funding, but for the pure joy of building something useful and beautiful.

🧠 The Problem I Set Out to Solve

I wanted a tool that made exploring beaches fun, visual, and practical — something beyond a list of names.

So my goals were simple:

✔️ Learn full-stack development
✔️ Build with modern tools
✔️ Add something unique to the experience
✔️ Make it usable for real users

No fluff. Just product-led learning.

🏖️ What BeachSeeker Actually Does

BeachSeeker is a minimalist, AI-driven beach discovery experience with these core features:

🔎 Smart Beach Discovery

An AI “Vibe Check” that tells you:

Whether a beach feels chill, crowded, or adventure-ready
Practical beach info (accessibility, crowd levels, best season)

✨ Clean, Human-Focused UI

The interface was inspired by sleek modern design — easy to use and focused on what matters.

📌 Deep Insight Into Every Beach

You get:

Crowd estimates
Accessibility info
Best months to visit
Add to favorites (personal itineraries)

🛠️ The Tech Stack

Here’s what powers BeachSeeker under the hood:

Frontend: Next.js for performance and server-side rendering
Styling: Tailwind CSS + Radix UI
Backend: PostgreSQL + Drizzle ORM
AI: Google Generative AI (Gemini)
Deployment: Optimized for fast load and SEO 🎯

📈 What I Learned

Building BeachSeeker taught me more than any course ever did:

💡 1. Architecture Matters

Choosing the right stack helped with:
Scaling features
Performance
Maintainability

🤖 2. AI Is Not Just Gimmicks

Using AI for contextual descriptions made the app feel more “alive” and useful.

🎨 3. UX is Everything

Users don’t care about tech they can’t see — they care about how it feels.

🔮 What’s Next for BeachSeeker

This is only the beginning! Here’s what’s on the roadmap:

✨ User reviews & photos
✨ Advanced filters (water temperature, surf conditions)
✨ Trip planner with AI suggestions
✨ Mobile app experience

💬 I Want Your Feedback!

Your thoughts will help shape BeachSeeker’s future.

👉 What features should we build next?
👉 Which beaches should be added?
👉 How can Vibe Check be smarter?

Drop a comment or reach out — I read every message! 🙌

🔗 Try BeachSeeker Live

Check it out here 👉 Live App Link
— explore beaches in a new way and send me feedback!

🌟 Thank You!

If you found this helpful or inspiring:

❤️ Like & share

💬 Comment your thoughts

🔁 Share with fellow devs or travelers

I’ll keep improving this app — and I’d love for you to join the journey. 🚀

I Built a React Autocomplete Component (and Reduced it from 5MB to 35KB)

rahul patwa — Fri, 21 Nov 2025 07:51:28 +0000

TL;DR: I built a React component for mention-based autocompletion that supports nested objects and arrays. Then I optimized it from 5MB to just 35KB. Here's the story and why you might want to use it.

The Problem: Template Hell 😫

Have you ever built a feature where users need to compose messages with dynamic variables?

You know, like:

Email templates: "Hi {{user.name}}, your order {{order.id}} is ready!"
Notification systems: "{{product.name}} is now {{product.price}}"
Chat bots: "Welcome {{user.name}} from {{user.address.city}}!"

The typical solutions are either:

Manual typing - Error-prone, users don't know what's available
Dropdown menus - Clunky UI, breaks the flow
Custom builders - Weeks of development time

I needed something better for my project, so I built type-ahead-mention.

The Solution: Smart Autocomplete ✨

import { MentionInput } from 'type-ahead-mention';

function EmailEditor() {
  const [template, setTemplate] = useState("Hi {{user.name}}!");

  const data = {
    user: { name: "John", email: "john@example.com" },
    order: { id: "12345", total: 99.99 }
  };

  return <MentionInput value={template} onChange={setTemplate} suggestions={data} />;
}

Type double opening curly braces and boom - intelligent autocomplete powered by CodeMirror.

But here's where it gets interesting...

The Magic: It Handles NESTED Data 🎯

Most autocomplete libraries choke on nested objects. Not this one:

const suggestions = {
  user: {
    name: "Sarah Connor",
    address: {
      city: "Los Angeles",
      street: "2144 Ventura Blvd"
    },
    roles: ["admin", "editor", "viewer"]
  }
};

Now users can type:

{{user.name}} → "Sarah Connor"
{{user.address.city}} → "Los Angeles"
{{user.roles.0}} → "admin" (yes, it does arrays!)

The autocomplete guides them through the structure as they type. No docs needed.

The Plot Twist: From 5MB to 35KB 📦

After building v1, I published it to NPM. Package size? 5 MEGABYTES. 😱

My first reaction: "That can't be right..."

But it was. Source maps + bundled dependencies = bloat city.

The Optimization Journey

Step 1: Kill the source maps

// vite.config.ts
build: {
  sourcemap: false  // Goodbye 3.9MB of .map files
}

Step 2: Externalize dependencies

Instead of bundling CodeMirror and friends, I made them peer dependencies:

{
  "peerDependencies": {
    "@codemirror/autocomplete": "^6.0.0",
    "@codemirror/state": "^6.0.0",
    "@uiw/react-codemirror": "^4.0.0"
  }
}

The Results 📊

Metric	Before	After	Reduction
Compressed	1.3 MB	12 KB	99.1% ↓
Unpacked	5.0 MB	35 KB	99.3% ↓
ES Module	642 KB	13 KB	97.9% ↓

Yeah, you read that right. 99% smaller.

Cool Features You'll Actually Use 🎨

1. Theme It Your Way

<MentionInput
  style={{
    fontSize: '16px',
    backgroundColor: '#1e1e1e',
    color: '#e0e0e0',
    borderRadius: '8px'
  }}
/>

2. Single or Multi-line

// Single-line input
<MentionInput value={subject} onChange={setSubject} />

// Multi-line textarea
<MentionInput value={body} onChange={setBody} multiline />

3. Template Resolution Hook

const resolved = useMentionResolver(
  "Hello {{user.name}}!", 
  { user: { name: "Alice" } }
);
// Result: "Hello Alice!"

4. Full Keyboard Navigation

Arrow keys to navigate suggestions
Enter to select
Escape to dismiss
Tab to autocomplete

Real-World Use Cases 🌍

1. Email Marketing Platforms
Let users create personalized emails without learning your template syntax.

2. Notification Builders
Build Slack/Discord bot message composers with dynamic fields.

3. Document Generation
Create contract templates, invoices, or reports with variable data.

4. Chat Applications
Quick replies with user context, order details, or product info.

5. Form Builders
Dynamic form field values based on user data or previous answers.

Live Demo (Try It Now!) 🎮

I built an interactive demo where you can:

✅ Test 5 different themes
✅ Customize styles in real-time
✅ Edit the JSON data structure live
✅ See template resolution instantly

👉 Play with the demo

Getting Started (2 Minutes) ⚡

npm install type-ahead-mention

Install peer dependencies:

npm install @codemirror/autocomplete @codemirror/state @codemirror/view @uiw/react-codemirror

Basic usage:

import { MentionInput } from 'type-ahead-mention';
import { useState } from 'react';

export function App() {
  const [message, setMessage] = useState("Hi {{name}}!");
  const suggestions = { name: "World", count: 42 };

  return (
    <MentionInput 
      value={message} 
      onChange={setMessage} 
      suggestions={suggestions} 
    />
  );
}

What I Learned 📚

Bundle size matters - Users will notice (and complain about) bloated packages
Peer dependencies are your friend - Don't bundle what users likely already have
Source maps in production? - Almost never a good idea
CodeMirror is powerful - But you need to understand its extension system
Interactive demos sell - Show, don't just tell

The Tech Stack 🛠️

React 18+ - Modern hooks API
TypeScript - Full type safety
CodeMirror 6 - The editor that powers VS Code's find/replace
Popper.js - Smart suggestion positioning
Vite - Lightning-fast builds

Open Questions for You 🤔

I'd love your input on:

What other autocomplete patterns do you need?
- SQL-like syntax? Markdown helpers? Custom delimiters?
Should I add a visual builder?
- Click to insert variables vs. typing the double curly braces
What about autocomplete from API calls?
- Async suggestions, debouncing, caching?
Mobile support?
- Touch-friendly suggestion popup?

Drop your thoughts in the comments! 👇

Try It Yourself 🚀

📦 NPM: npm install type-ahead-mention
🎮 Demo: https://rahulpatwa1303.github.io/type-ahead-mention/
💻 GitHub: https://github.com/rahulpatwa1303/type-ahead-mention
📖 Docs: Full API reference in the README

The Numbers 📈

Since launching v2.0.1:

✅ 35KB unpacked (99% smaller than v1)
✅ Full TypeScript support
✅ Zero runtime dependencies (except peers)
✅ Works with React 18+
✅ MIT licensed

What's Next? 🔮

I'm considering:

Custom delimiters - Use [[var]] or $var instead of the double curly brace syntax
Formatting helpers - Date/number formatting filters
Multi-select - Pick multiple variables at once
Undo/redo - Built-in history management

What would YOU use most? Let me know!

Final Thoughts 💭

Building this package taught me that optimization isn't just about performance - it's about respect for your users' bandwidth, disk space, and patience.

Going from 5MB to 35KB wasn't just a technical achievement. It was a statement: "I care about your bundle size."

If you're building any kind of template system, notification builder, or dynamic message composer, give type-ahead-mention a shot. It might save you weeks of development.

And if you find bugs or have feature requests, the repo is open! PRs welcome. 🎉

Let's Connect! 🤝

Give it a ⭐ on GitHub
Share your use cases in the comments
Found a bug? Open an issue
Built something cool? I'd love to see it!

Question for you: What's the WORST template system you've had to work with? Share your horror stories below! 👻

P.S. - If you're wondering why the package is called "type-ahead-mention" instead of something catchier... well, naming things is hard. 😅 Got a better name? Comment below!

Last updated: November 19, 2025

My Spooky Halloween Landing Page

rahul patwa — Sun, 09 Nov 2025 18:54:41 +0000

This is a submission for Frontend Challenge - Halloween Edition, Perfect Landing

What I Built

For the Perfect Landing challenge, I created a spooky and engaging Halloween-themed landing page. The project, built with Next.js and styled with Tailwind CSS, is designed to be fully responsive, ensuring a great experience on any device.

The landing page captures the essence of Halloween with a dark, atmospheric color palette, thematic imagery like pumpkins and ghosts, and playful typography. The goal was to create a modern, fast, and visually appealing page that is both fun to explore and technically robust.

Demo

>> View the Live Demo Here <<

Journey

This challenge was a fantastic opportunity to sharpen my frontend skills, particularly with Next.js and Tailwind CSS. My process started with brainstorming a fun Halloween concept and sketching out a simple wireframe for the landing page layout.

I chose a minimalist yet spooky theme, focusing on clean design and subtle animations to bring the page to life. One of the main things I learned was how to efficiently set up a static export for a Next.js application for deployment on GitHub Pages. I'm especially proud of the component structure and the responsive design, which adapts smoothly from large desktops down to mobile phones.

In the future, I hope to add more interactive elements, like a ghost that follows the cursor or some fun CSS-based animations on the call-to-action buttons.

This project was created by rahulpatwa1303.

Interview Hero: Your AI Coach for Crushing Tech Interviews

rahul patwa — Sat, 31 May 2025 10:58:16 +0000

The Struggle is Real: Why Interview Prep Feels Broken
If you've ever prepped for a tech interview, you know that feeling.

You’ve got 20 browser tabs open—LeetCode, interview blogs, YouTube mock interviews—and yet somehow, you’re still unsure what to expect. You spend hours grinding problems, only to get stumped in a real interview when asked, “How would you scale this system?”

Or worse—your feedback is: “Good effort, but not quite there.”

No explanation. No tips. Just... confusion.

The truth? Most interview prep tools weren’t built for real people.

They're too generic. Too static. Too expensive. And they leave you more anxious than confident.

So, we built something better.

🎉 Introducing Interview Hero — Your Personal AI Interview Coach

Interview Hero is a new web application designed to rethink how software engineers and computer science students prepare for interviews.

Our mission is simple:

To make effective, affordable, and realistic technical interview preparation accessible to everyone—with the power of AI.

We’ve combined intelligent question generation, personalized feedback, and realistic simulations into one seamless experience. No more guesswork. No more fluff.

Just practice that works.

💡 Why Interview Hero Works (and Why You’ll Actually Use It)

Here’s what sets Interview Hero apart from every other prep tool out there:

✅ 1. AI-Generated, Personalized Questions

No more recycled question banks.

Interview Hero dynamically generates questions tailored to your chosen focus:

DSA (Data Structures & Algorithms)

System Design

Behavioral & Soft Skills

Unlike traditional platforms, these questions evolve based on your skill level and focus areas. It’s like having a private tutor who actually knows where you’re struggling—and adapts in real time.

🧠 2. Instant, Actionable AI Feedback

Ever finish a mock interview and think, “Okay... but how did I do?”

Interview Hero gives you:

Clear highlights of your strengths
Honest analysis of your weaknesses
Specific, actionable next steps

Think of it as your personal AI coach—encouraging but direct, and always focused on helping you grow.

🎯 3. Topic Specialization & Profile Customization

Want to master dynamic programming? Or prep for a behavioral round at your dream company?

You can:

Customize your learning path
Track your performance over time
Focus on the areas where you need the most help

More personalization = less wasted time.

🛠️ How It Works: Your Interview Hero Journey

Getting started is fast, simple, and—you guessed it—free.

Here’s what your path to interview mastery looks like:

Sign Up → Head over to (interview-hero)[https://interview-hero-e4hl.vercel.app] and create your free account.
Fill Out Your Profile → Tell us a bit about yourself: your experience level, preferred languages, job focus, and goals. This helps Interview Hero personalize your sessions and generate questions that actually match your needs.
Pick a Topic—or Let Us Pick One for You →
Have a specific topic in mind? Share it with us.
Unsure where to begin? No problem—our AI will choose a relevant focus area based on your profile.
Get a Question → Our AI generates a smart, relevant prompt based on your profile and chosen topic.
Answer Naturally → Type or speak your response just like you would in a real interview.
Receive Instant AI Feedback → Learn your strengths, spot weaknesses, and get tailored suggestions for improvement. Think of it as having a virtual coach with a keen eye.

🧑‍💻 Why We Built Interview Hero

We’re developers too.

We’ve been through the grind—nervously prepping for interviews at Big Tech, early-stage startups, and everywhere in between. We know how overwhelming it can be:

What should you study?
How do you know if your answers are good enough?
Can you afford those pricey coaching sessions?

Most platforms out there are either too expensive, too generic, or too complicated. We wanted something better—for ourselves and for the community.

So we built what we wished existed:

✅ A smart, supportive coach that gives honest, actionable feedback
✅ An experience that’s intuitive, fast, and easy to use
✅ A free tier so anyone, anywhere, can level up their interview game without breaking the bank

Interview Hero is for the engineer who wants to grow, not just cram. It’s built by people who’ve been in your shoes, and it’s here to help you get where you want to go—with confidence.

🚀 Start Practicing Smarter—Right Now

You're not just preparing for an interview. You're building a career.

Let Interview Hero guide you there—with the kind of personalized, intelligent support you can’t get from a static PDF or overpriced bootcamp.

👉 Try it free today at interview-hero-e4hl.vercel.app

🔁 Let’s Redefine Interview Prep—Together

We believe the best tools are built in collaboration with the people who use them.

So as you start using Interview Hero, we want your feedback. Tell us what works. What doesn’t. What you’d love to see next. We’re here to listen—and to help.

Because when you win that job offer, we want to be the first to high-five you (virtually, of course).

#career #interviewprep #softwareengineering #webdev #ai

Creating a Synchronized Vertical and Horizontal Scrolling Component for Web Apps

rahul patwa — Sun, 30 Jun 2024 11:56:30 +0000

Introduction

Microsoft Teams' mobile agenda page offers a sleek and intuitive interface with synchronized vertical and horizontal scrolling. This design allows users to scroll through dates horizontally and see the corresponding events in a vertical list. Inspired by this elegant solution, I decided to create a similar component using modern web technologies. While there are many libraries and blogs about synchronized scrolling, they typically handle scrolling in the same direction. This article will show you how to achieve synchronized scrolling in both vertical and horizontal directions.

You can also checkout the live demo

Prerequisites

Before diving in, you should have a basic understanding of React, JavaScript, and Tailwind CSS. Make sure you have Node.js and npm installed on your machine.

Setting Up the Project

First, create a new React project using Create React App or your preferred method.

npm create vite@latest my-sync-scroll-app -- --template react
cd my-sync-scroll-app 
npm install

Next, install Tailwind CSS (optional).

npm install -D tailwindcss npx tailwindcss init

Configure Tailwind CSS by adding the following content to your tailwind.config.js file:

module.exports = { 
    purge: ['./src/**/*.{js,jsx,ts,tsx}', './public/index.html'], 
    darkMode: false, 
    theme: { 
        extend: {}, 
    }, 
    variants: { 
        extend: {}, 
    }, 
    plugins: [], 
};

Add the Tailwind directives to your CSS file (src/index.css):

@tailwind base;
@tailwind components;
@tailwind utilities;

Utility Function for Date Generation

Let's create a utility function to generate a list of dates starting from a given date.

export const generateDates = (startDate, days) => {
  const dates = [];
  for (let i = 0; i < days; i++) {
    const date = new Date(startDate);
    date.setDate(startDate.getDate() + i);
    dates.push(date.toISOString().split("T")[0]); // Format date as YYYY-MM-DD
  }
  return dates;
};

Creating the Horizontal Scroll Component

Let's start by creating the HorizontalScroll component. This component will allow users to scroll through dates horizontally and select a date.

import React, { useEffect, useRef } from "react";

const HorizontalScroll = ({
  dates,
  selectedDate,
  setSelectedDate,
  setSelectFromHorizontal,
}) => {
  const containerRef = useRef();

  useEffect(() => {
    // Automatically scroll to the selected date and center it in the view
    const selectedElement = containerRef.current.querySelector(`.date-item.selected`);
    if (selectedElement) {
      const containerWidth = containerRef.current.offsetWidth;
      const elementWidth = selectedElement.offsetWidth;
      const elementOffsetLeft = selectedElement.offsetLeft;
      const scrollTo = elementOffsetLeft - containerWidth / 2 + elementWidth / 2;
      containerRef.current.scrollTo({
        left: scrollTo,
        behavior: "smooth",
      });
    }
  }, [selectedDate]);

  const handleDateSelection = (index) => {
    setSelectedDate(dates[index]);
    setSelectFromHorizontal(true);
  };

  const onWheel = (e) => {
    const element = containerRef.current;
    if (element) {
      if (e.deltaY === 0) return;
      element.scrollTo({
        left: element.scrollLeft + e.deltaY,
      });
    }
  };

  return (
    <div className="w-full flex flex-row-reverse items-center gap-2 bg-gray-500 rounded-md horizontal">
      <div
        className="horizontal-scroll flex overflow-x-auto whitespace-nowrap scroll-smooth rounded-md"
        ref={containerRef}
        onWheel={onWheel}
      >
        {dates.map((date, index) => {
          const day = new Date(date).toLocaleString([], { month: "short" });
          const d = new Date(date).toLocaleString([], { day: "2-digit" });
          return (
            <div
              key={date}
              className={`date-item ${selectedDate === date ? "selected" : ""} flex flex-col items-center p-4`}
              onClick={() => handleDateSelection(index)}
              style={{
                backgroundColor: selectedDate === date ? "#90cdf4" : "#f7fafc",
                borderRadius: selectedDate === date ? "4px" : "0px",
              }}
            >
              <p className={`text-sm ${selectedDate === date ? "text-blue-600" : "text-gray-500"} font-light`}>
                {day}
              </p>
              <p className={`text-base font-semibold ${selectedDate === date ? "text-blue-700" : "text-gray-700"}`}>
                {d}
              </p>
            </div>
          );
        })}
      </div>
    </div>
  );
};

export default HorizontalScroll;

Creating the Vertical Scroll Component

Next, create the VerticalScroll component to display the events for the selected date. This component will synchronize with the HorizontalScroll component to update the displayed events when a date is selected.

import React, { useEffect, useRef, useState } from "react";

const VerticalScroll = ({
  dates,
  onDateChange,
  selectedDate,
  selectFromHorizontal,
  setSelectFromHorizontal,
}) => {
  const containerRef = useRef();
  const [visibleDates, setVisibleDates] = useState([]);
  const [isProgrammaticScroll, setIsProgrammaticScroll] = useState(false);

  useEffect(() => {
    const container = containerRef.current;
    const handleScroll = () => {
      if (isProgrammaticScroll) {
        setIsProgrammaticScroll(false);
        return;
      }
      if (!selectFromHorizontal) {
        // Calculate the date at the top of the vertical scroll
        const topDateIndex = Math.floor(container.scrollTop / 100);
        const topDate = dates[topDateIndex];
        onDateChange(topDate);
      }
      // Calculate the visible dates based on the current scroll position
      const start = Math.floor(container.scrollTop / 100);
      const end = start + Math.ceil(container.clientHeight / 100);
      const visible = dates.slice(start, end);
      setVisibleDates(visible);
    };

    container.addEventListener("scroll", handleScroll);

    return () => container.removeEventListener("scroll", handleScroll);
  }, [dates, isProgrammaticScroll, onDateChange]);

  useEffect(() => {
    setTimeout(() => setSelectFromHorizontal(false), 1000);
  }, [selectedDate]);

  useEffect(() => {
    const selectedIndex = dates.indexOf(selectedDate);
    if (selectedIndex !== -1) {
      // Scroll to the selected date in the vertical scroll
      const scrollTo = selectedIndex * 100;
      setIsProgrammaticScroll(true);
      containerRef.current.scrollTo({
        top: scrollTo,
        behavior: "smooth",
      });
    }
  }, [selectedDate, dates]);

  return (
    <div className="h-full overflow-y-auto" ref={containerRef}>
      {dates.map((date) => (
        <div key={date} className="my-4 h-24">
          <div className="relative flex items-center mb-2">
            <div className="flex-grow border-t border-gray-300"></div>
            <span className="flex-shrink mx-4 text-gray-500">
              {new Date(date).toLocaleString([], { month: "short", day: "2-digit", weekday: "short" })}
            </span>
            <div className="flex-grow border-t border-gray-300"></div>
          </div>
          {visibleDates.includes(date) ? (
            <DateContent date={date} />
          ) : (
            <p>No events</p>
          )}
        </div>
      ))}
    </div>
  );
};

const DateContent = ({ date }) => {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      const selectDate = new Date(date);

      selectDate.setHours(6, 0, 0, 0);
      const epochStartTimestamp = Math.floor(selectDate.getTime() / 1000);

      selectDate.setDate(selectDate.getDate() + 3);
      selectDate.setHours(23, 59, 59, 999);
      const epochEndTimestamp = Math.floor(selectDate.getTime() / 1000);

      const queryParams = `?start_timestamp=${epochStartTimestamp}&end_timestamp=${epochEndTimestamp}`;

      try {
        const response = await fetch(`https://example.com/api/upcomingShifts${queryParams}`);
        if (response.status === 200) {
          const result = await response.json();
          setLoading(false);
          setData((prevData) => [...prevData, ...result.upcomingShifts]);
        }
      } catch (error) {
        console.error("Error fetching data:", error);
      }
    };

    fetchData();
  }, [date]);

  if (!data) return <p>Loading...</p>;

  return (
    <div>
      {loading ? (
        <div className="animate-pulse h-6 bg-gray-300 rounded"></div>
      ) : (
        data.map((d) => (
          <div key={d.id} className="my-2">
            <p>{d.id}</p>
          </div>
        ))
      )}
    </div>
  );
};

export default VerticalScroll;

Bringing It All Together

Now, let's integrate these components in the main App component.

import React, { useState } from "react";
import HorizontalScroll from "./components/HorizontalScroll";
import VerticalScroll from "./components/VerticalScroll";

const App = () => {
    const dates = generateDates(new Date(), 90);
    const [selectedDate, setSelectedDate] = useState(dates[0]);
    const [selectFromHorizontal, setSelectFromHorizontal] = useState(false);

  // Function to handle date changes from the vertical scroll component
  const handleDateChange = (date) => {
    if (!selectFromHorizontal) {
      setSelectedDate(date);
    }
  };

  return (
    <div className="flex flex-col h-screen p-4">
      <HorizontalScroll
        dates={dates}
        selectedDate={selectedDate}
        setSelectedDate={setSelectedDate}
        setSelectFromHorizontal={setSelectFromHorizontal}
      />
      <VerticalScroll
        dates={dates}
        selectedDate={selectedDate}
        onDateChange={handleDateChange}
        selectFromHorizontal={selectFromHorizontal}
        setSelectFromHorizontal={setSelectFromHorizontal}
      />
    </div>
  );
};

export default App;

Conclusion

By following this guide, you can create a synchronized vertical and horizontal scrolling component for your web application. This design pattern, inspired by Microsoft Teams' mobile agenda page, enhances the user experience by providing an intuitive and efficient way to navigate through dates and events. Experiment with the components, adjust the styles, and integrate them into your projects to meet your specific needs. Happy coding!

Live Demo

For a live demonstration of the synchronized vertical and horizontal scrolling component, you can explore the demo on CodeSandbox. This interactive sandbox allows you to see the code in action and experiment with the functionality described in this blog.

Glam Up My Markup: Beaches - Frontend Challenge v24.04.17

rahul patwa — Fri, 07 Jun 2024 05:30:54 +0000

This is a submission for [Frontend Challenge v24.04.17]((https://dev.to/challenges/frontend-2024-05-29), Glam Up My Markup: Beaches

What I Built

For this challenge, I developed an interactive UI that visualizes beaches around the world on a global map. Leveraging the power of D3.js, I created a dynamic map that plots each beach based on its geographical coordinates.

Key Features:

Interactive Map: Users can explore beaches plotted on a world map. Each beach is represented by a point that can be clicked for more information.
Detail Sidebar: Upon clicking a beach on the map, a sidebar slides in to display detailed information about the selected beach, including its name, location, and other relevant details.
Beach List: Alongside the map, there is a comprehensive list of all the beaches with their names. Users can click on any beach name from the list to view its details and locate it on the map.
User-Friendly Design: Inspired by Google Maps' intuitive interface and Snapchat's hotspot visualization, the UI aims to provide a seamless and engaging user experience.

My goal was to create an aesthetically pleasing and highly functional interface that allows users to easily discover and learn about various beaches around the world. By integrating familiar design elements from popular applications, I aimed to enhance usability and make the exploration process enjoyable.

Demo

Access my project on GitHub pages

You can checkout the github repo of the code on

Journey

Coming from a background with React and Next.js, I had limited experience working with vanilla JavaScript. This project provided an excellent opportunity to dive into the core fundamentals of JavaScript and DOM manipulation without relying on frameworks. Here are the key learnings and experiences from my journey:

Vanilla JavaScript:
-DOM Manipulation: Without the abstraction layers provided by React, I had to directly interact with the DOM, which gave me a deeper understanding of how web pages are constructed and updated.
-Event Handling: I learned to handle events purely with JavaScript, enhancing my ability to create interactive web elements.
D3.js:
-Data Binding and Visualization: I explored how to bind data to HTML elements and create dynamic visualizations. D3.js proved to be a powerful tool for rendering complex data-driven graphics.
-Geographical Mapping: Implementing the world map and plotting the beaches taught me how to work with geographical data and projections in D3.js.
-Interactive Features: Adding interactivity, such as clickable points and a responsive sidebar, helped me appreciate the versatility and power of D3.js for creating engaging user interfaces.

This project not only expanded my technical skills but also enhanced my appreciation for the intricacies of web development. It was a rewarding journey that pushed me out of my comfort zone and allowed me to grow as a developer.