Forem: Krish Carter

Peeking Under the Hood: How Cloudflare R2 Really Works (And Why Your Frontend Apps Will Thank You)🧑‍💻😍

Krish Carter — Thu, 26 Feb 2026 16:35:35 +0000

You've built the perfect React app slick UI, fast interactions, maybe even some fancy image uploads for user profiles or a Next.js blog with tons of media. Everything's humming along locally... until you deploy and the storage bills hit. AWS S3 egress fees eat your budget the moment users start downloading their own avatars. Sound familiar?

That's the pain Cloudflare R2 solves. No egress charges. S3-compatible API. Runs on Cloudflare's massive global network. But how does it actually pull this off without turning into a consistency nightmare or a latency slug?

In this post, you'll get a clear, no-fluff tour of R2's internal architecture. We'll go from high-level concepts to the clever tricks that make it feel magical for frontend work—complete with code you can steal for your next side project. By the end, you'll know exactly when (and how) to reach for R2 instead of S3, Backblaze, or even local storage hacks.

The Core Promise: Zero Egress, Global Scale
R2's High-Level Architecture Overview
Metadata Magic: Durable Objects Keep It Consistent
Reading Data: Tiered Cache + Global Distribution
Writing Data: Local Uploads and Background Replication
Practical Example: Uploading and Serving Images from a Next.js App
Advanced Tips and Gotchas for Frontend Devs
Common Mistakes That Burn You
Wrapping Up: Level Up Your Storage Game

The Core Promise: Zero Egress, Global Scale

Why care about internals? Because understanding why R2 behaves the way it does helps you design better systems.

Traditional object stores like S3 charge for data leaving their region. Cloudflare's edge network (330+ locations) changes the game: data is served from the nearest point-of-presence (PoP), often without ever hitting a "central" origin. No egress bill because the transfer happens on Cloudflare's backbone.
But global-anywhere reads + strong consistency sounds impossible. R2 achieves it by decoupling metadata from payload storage and leaning hard on Cloudflare primitives.

Always think "edge-first." If your app serves public assets (images, videos, user uploads), R2 + Cloudflare Images/Stream can slash costs and latency compared to centralized providers.

R2's High-Level Architecture Overview

R2 breaks into four key layers:

R2 Gateway — Edge Workers handling auth, routing, S3 API translation.
Metadata Service — Distributed Durable Objects for object keys, checksums, versions—ensuring strong consistency.
Tiered Read Cache — Multi-level caching leveraging Cloudflare's Tiered Cache.
Distributed Storage Infrastructure — Encrypted, erasure-coded persistent storage across regions.

Requests hit the nearest edge → gateway routes → metadata checked → data pulled from cache or backing store.

Metadata Magic: Durable Objects Keep It Consistent

Durable Objects are single-instance, stateful Workers. R2 uses them for metadata: each object key maps to a Durable Object that holds info like ETag, size, last-modified.

When you PUT an object:

Gateway routes to the DO responsible for that key.
DO updates metadata atomically.
Payload goes to storage.

Reads hit the DO first → fast metadata cache → then data fetch.

This avoids distributed locks or consensus hell. Durable Objects provide coordination without traditional databases.

For **custom **needs, bind R2 buckets directly in Workers for zero-latency metadata ops.

Tsx

// In a Cloudflare Worker
export default {
  async fetch(request, env) {
    const object = await env.MY_BUCKET.get('profile-pic.jpg');
    if (object === null) return new Response('Not found', { status: 404 });

    const data = await object.arrayBuffer();
    return new Response(data, {
      headers: { 'Content-Type': 'image/jpeg' },
    });
  }
};

Reading Data: Tiered Cache + Global Distribution

Reads shine here. Cloudflare Tiered Cache sits in front:

L1: PoP-level cache (super fast if hit).
L2: Regional.
Miss → Distributed Storage.

Because data is replicated/erasure-coded across locations, hot objects get cached globally.

No egress: delivery is from edge cache → client.

Accessibility Note
When serving images, always add alttext and consider loading="lazy" + responsive srcset. R2 pairs perfectly with <Image> components in Next.js.

Writing Data: Local Uploads and Background Replication

New in 2026: Local Uploads (beta). Enable it → client uploads to nearest PoP storage.

Metadata publishes immediately to bucket's "home" region DO. Background job replicates payload asynchronously with retries.
Result: ~75% lower write latency for global users no waiting for cross-region sync.

Without Local Uploads, writes route to bucket's location hint (or auto).

Practical Example: Uploading and Serving Images from a Next.js App

Let's build a simple user avatar uploader.

Create R2 bucket in dashboard.
Generate S3-compatible credentials (Access Key ID, Secret).
Use @aws-sdk/client-s3 with custom endpoint.

Tsx

// lib/r2.ts
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

const r2 = new S3Client({
  region: 'auto',
  endpoint: `https://${process.env.R2_ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: {
    accessKeyId: process.env.R2_ACCESS_KEY_ID!,
    secretAccessKey: process.env.R2_SECRET_ACCESS_KEY!,
  },
});

export async function uploadAvatar(file: File, userId: string) {
  const key = `avatars/${userId}.jpg`;
  await r2.send(new PutObjectCommand({
    Bucket: 'my-app-bucket',
    Key: key,
    Body: Buffer.from(await file.arrayBuffer()),
    ContentType: file.type,
  }));
  return `https://pub-<your-pub-hash>.r2.dev/${key}`;
}

In your component:

Tsx

// app/upload/page.tsx
'use client';

import { uploadAvatar } from '@/lib/r2';

export default function Upload() {
  const handleUpload = async (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (!file) return;
    const url = await uploadAvatar(file, 'krish123');
    console.log('Avatar URL:', url);
  };

  return <input type="file" onChange={handleUpload} />;
}

Common Mistakes That Burn You

Forgetting region=autoin SDK → weird errors.
Assuming eventual consistency → test read-after-write.
Public bucket without CORS → browser blocks fetches.
Ignoring Class B ops costs → listObjectsV2 can add up on large buckets.

Wrapping Up: Level Up Your Storage Game

R2 isn't just "cheap S3." Its edge-native design, Durable Objects metadata, tiered caching, and new Local Uploads make it a frontend superpower: fast, predictable costs, global performance without ops overhead.

Why Your React App Feels Slow (Even When It Looks Fine) And How React Doctor Fixes It in Seconds 🧑‍💻⌨️

Krish Carter — Tue, 24 Feb 2026 15:04:23 +0000

You've been there: your React app feels sluggish, re-renders are happening more than you'd like, and debugging sessions stretch into the night. You profile with React DevTools, chase down memoization misses, and still wonder — "Why is this component re-rendering on every keystroke?"

The culprit is often not one big mistake, but dozens of small anti-patterns that accumulate over time. Unnecessary useEffect hooks computing derived state. Prop drilling through five levels instead of composition. Missing key props that silently break list reconciliation. Accessibility oversights that hurt real users.

These issues don't scream during development they whisper performance regressions, bugs during refactors, and frustrated users. In large codebases, they compound until your app feels "heavy" for no obvious reason.

Enter React Doctor
A free, open-source CLI tool that acts like a code physician. Run one command, and it scans your entire React project (Next.js, Vite, Remix, whatever), detects framework setup, React version, and compiler config, then flags issues with file-by-file precision. It outputs a 0-100 health score and prioritizes fixes that deliver the biggest wins.

In this post, you'll learn exactly how to use React Doctor, why its warnings matter, and how to fix the most common issues it surfaces. By the end, you'll have a repeatable workflow to keep your React code lean, accessible, and maintainable.

What React Doctor Actually Does
Getting Started: One Command to Rule Them All
The Most Common Warnings (And Why They Hurt)
Fixing Unnecessary useEffect: The Silent Performance Killer
Beyond Hooks: Accessibility, Keys, and Architecture Smells
Advanced: Integrating React Doctor into Your Workflow
Common Gotchas When Interpreting Results
Wrapping Up: Make Code Health a Habi

What React Doctor Actually Does

React Doctor isn't a runtime profiler like React Scan — it's a static analyzer powered by fast Rust based tooling (Oxlint under the hood). It parses your code without running it, applies rules tuned for modern React (hooks, Server Components, server actions), and catches patterns that lead to bugs or slowness.

Getting Started: One Command to Rule Them All

Installation? None. Just npx it:

Bash

npx -y react-doctor@latest .

The . tells it to scan the current directory. In seconds (yes, even on big monorepos), you'll see output like:

Text

React Doctor vX.Y.Z
Scanning project...
Framework: Next.js 15
React: 19.0.0-rc
Compiler: Turbopack

Health Score: 82/100

Critical (1):
- src/app/actions/deleteUser.ts:18 Missing authentication check in server action

Warnings (42):
- src/components/UserProfile.tsx:45 Derived state in useEffect — compute in render
- src/features/TodoList.tsx:22 Using index as key in mapped list
...

Accessibility (8):
- src/components/AnimatedModal.tsx:67 Missing prefers-reduced-motion check

Gotcha!
If you're in a monorepo, cd into the app folder first or use --dir ./apps/web (check docs for flags).
Accessibility Note
Many warnings highlight a11y gaps, like missing reduced-motion handling that improve UX for users with vestibular disorders.

The Most Common Warnings (And Why They Hurt)

React Doctor surfaces patterns you've probably written without thinking:

Derived state in useEffect— recomputes on every render cycle instead of during render.
Uncleaned async in effects → race conditions on unmount.
Index as key → broken animations/reordering in lists.
Prop drilling → brittle components, hard refactors.
Server action security → missing auth checks → vulnerability.
No reduced-motion→ jarring experiences for sensitive users.

Fixing Unnecessary useEffect: The Silent Performance Kille

This is the #1 warning in most codebases. Classic anti-pattern:

tsx

function ExpensiveList({ items }) {
  const [sortedItems, setSortedItems] = useState([]);

  useEffect(() => {
    setSortedItems([...items].sort((a, b) => a.name.localeCompare(b.name)));
  }, [items]);

  return <ul>{sortedItems.map(item => <li key={item.id}>{item.name}</li>)}</ul>;
}

Why it's bad: Every time items changes → effect runs → state update → re-render → potential loop if parent re-renders often.

Fix —** compute during render:**

tsx

function ExpensiveList({ items }) {
  const sortedItems = useMemo(() => {
    return [...items].sort((a, b) => a.name.localeCompare(b.name));
  }, [items]);

  return <ul>{sortedItems.map(item => <li key={item.id}>{item.name}</li>)}</ul>;
}```



**Tip**
`useMemo `is your friend here, but don't overuse it, only when the sort is expensive. React Doctor helps you spot when you need it.

## Beyond Hooks: Accessibility, Keys, and Architecture Smells

For keys in lists:
Bad:

{items.map((item, index) => )}




Good:

{items.map(item => )}



React Doctor flags index-as-key because reordering items causes unnecessary DOM mutations and lost state.

For accessibility animations without reduced-motion checks:

tsx

// Add this wrapper
const prefersReducedMotion = useMediaQuery('(prefers-reduced-motion: reduce)');

if (prefersReducedMotion) {
// no animation
} else {
// animate
}



**Wrapping Up: Make Code Health a Habit**

Mastering tools like React Doctor shifts you from reactive firefighting to proactive quality. Your apps become faster, more accessible, and easier to maintain especially as teams grow.

Next steps:

Run `npx react-doctor@latest .` on your current project today.
Tackle the top 5 warnings.
Add it to CI for ongoing health checks.

Peeking Under the Hood: How Supabase Storage Really Works (And Why It Feels Like Magic)

Krish Carter — Wed, 18 Feb 2026 13:15:59 +0000

Table of Contents

The Big Picture: Storage as Postgres + Object Store Hybrid
Buckets, Objects, and the Metadata Layer
Uploads: From TUS Resumable to S3-Compatible Magic
Security Deep Dive: Row-Level Security Meets File Access
Serving Files: Signed URLs, Public Buckets, and Edge Delivery
Advanced Patterns: Image Transformations and Integrations
Common Pitfalls and Pro Tips
Wrapping Up: Level Up Your File Handling

The Big Picture: Storage as Postgres + Object Store Hybrid

Supabase Storage isn't just another blob store it's a clever marriage of PostgreSQL for metadata and access control, and an S3-compatible object store (primarily Amazon S3 under the hood, with support for others) for the actual heavy lifting of file bytes.

Why this hybrid?

Postgres gives you battle-tested relational power: fine-grained Row Level Security (RLS), transactions, and queries.
S3 gives you infinite scale, durability, and cheap storage for raw bytes.

The result? You get file permissions as expressive as your database policies, while the heavy files live where they belong on object storage.

Pro Tip:-
Think of Storage as "Postgres wearing an S3 hat." Every file operation starts in Postgres (auth, policy check), then proxies to S3.

Note:-
Don't assume Storage is purely serverless like Firebase—it's backed by real Postgres instances, so heavy metadata operations (listing thousands of files) can hit query limits if you're not careful.

Buckets, Objects, and the Metadata Layer

Everything starts with buckets. You create them in the dashboard or via API:

Javascript

const { data, error } = await supabase.storage.createBucket('avatars', {
  public: false,
});

Internally:

Buckets are rows in a Postgres table (storage.buckets).
Each bucket has config like public, allowed_mime_types, etc.

Files (objects) live in another table (storage.objects):

id, bucket_id, name(path), metadata(JSONB), owner(user UUID), etc.
The actual file path in S3 is something like bucket-name/user-id/random-uuid.ext, but you never see that—Supabase abstracts it.

This metadata layer lets you query files relationally:

SQL

-- Example: Find all avatars owned by a user
SELECT * FROM storage.objects
WHERE bucket_id = 'avatars'
AND owner = 'uuid-of-user';

Tip
Use metadataJSONB for custom tags (e.g., { "project_id": 123 })—query them efficiently with GIN indexes if needed.

Accessibility Note
When storing images, always add alt text metadata and enforce it in your frontend forms—Supabase won't do it for you.

Uploads: From TUS Resumable to S3-Compatible Magic

Tsx

// React example with progress
const uploadFile = async (file: File) => {
  const { data, error } = await supabase.storage
    .from('avatars')
    .upload(`public/${user.id}/${file.name}`, file, {
      upsert: true,
      contentType: file.type,
    });

  if (error) console.error(error);
};

Behind the scenes:

Client → Supabase Storage API (Node.js/Fastify service).
API checks auth + RLS policy for insert on storage.objects.
For large files, Supabase uses TUS protocol (resumable uploads) via libraries like Uppy.
Chunked data streams directly to S3 (multipart upload).
Once complete, metadata row is committed in Postgres transactionally.

Since late 2024/early 2025, Supabase Storage is fully S3 compatible can use AWS SDKs directly:

Javascript

// Using AWS SDK v3 with Supabase credentials
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

const s3 = new S3Client({
  region: 'auto', // Supabase uses 'auto'
  endpoint: 'https://<project-ref>.supabase.co/storage/v1/s3',
  credentials: {
    accessKeyId: 'your-supabase-access-key',
    secretAccessKey: 'your-supabase-secret-key',
  },
  forcePathStyle: true,
});

Security Deep Dive: Row-Level Security Meets File Access

This is where Supabase shines.
Policies live on storage.objects table, just like database tables.

Example policy: Users can only upload to their own folder:

SQL

CREATE POLICY "Users can upload own avatars"
ON storage.objects FOR INSERT
TO authenticated
WITH CHECK (
  bucket_id = 'avatars'
  AND (storage.foldername(name))[1] = auth.uid()::text
);

storage.foldername(name) extracts path segments.
auth.uid() pulls the JWT user ID.
Combine with public buckets for CDNs—public buckets bypass auth but still respect allowed_mime_types.

Serving Files: Signed URLs, Public Buckets, and Edge Delivery

Public bucket file: https://<project-ref>.supabase.co/storage/v1/object/public/avatars/user123/photo.jpg

Private: Use signed URLs (time-limited):
Javascript

const { data } = await supabase.storage
  .from('private-docs')
  .createSignedUrl('reports/q4.pdf', 60); // 60 seconds

Internally, signed URLs are JWTs verified by the Storage API, which proxies to S3 with presigned URLs.
Edge caching? Supabase leverages CDN providers for public assets-low-latency global delivery.

Advanced Patterns: Image Transformations and Integrations

Supabase Storage supports on-the-fly image transforms (via imgproxy integration):

Javascript

// Resize to 200x200
const { data } = supabase.storage
  .from('avatars')
  .getPublicUrl('user123/photo.jpg', {
    transform: { width: 200, height: 200, resize: 'cover' }
  });

Under the hood: Requests hit an edge worker that pulls from S3, transforms, caches.
Pair with Edge Functions for custom processing (watermarking, virus scanning).

Pro Tip

Cache transformed images aggressively use Cache-Control headers in metadata.

Common Pitfalls and Pro Tips

Pitfall: Listing huge buckets → Use pagination + search params.
Pitfall: Signed URLs expiring mid-session → Refresh on demand.
Pro Tip: Monitor usage via pg_stat_statements for metadata bottlenecks.
Pro Tip: For ultra-scale, consider direct S3 uploads with presigned URLs generated from Edge Functions.

Inside Supabase Edge Functions: How Serverless Magic Actually Works

Krish Carter — Tue, 17 Feb 2026 13:20:47 +0000

Discover the inner mechanics of Supabase's globally distributed serverless functions and how they power low-latency apps with Deno at their core.

Hey there! If you've ever built a web app and hit that frustrating wall where your server-side logic feels sluggish or overly complicated, you're not alone. Supabase Edge Functions are a game-changer for handling things like webhooks, API integrations, or even generating dynamic content right at the edge of the network closer to your users for that snappy performance.

In this guide, we'll peel back the layers of how these functions actually work underneath. You'll learn the architecture, runtime details, and deployment flow, all while building up from basics to advanced tweaks. By the end, you'll be equipped to integrate them into your own projects, solving real problems like reducing latency in global apps or securely orchestrating third-party services. Let's dive in it's going to be fun and practical.

Table of Contents

The Basics: What Are Supabase Edge Functions?
A Practical Example: Building Your First Function
Visual Intuition: Mapping the Architecture
Real-World Use Case: Handling a Stripe Webhook
Advanced Tips: Optimizing for Scale and Security
Wrapping It Up: Why This Matters for Your Apps

The Basics: What Are Supabase Edge Functions?

Let's start simple. At their core, Supabase Edge Functions are TypeScript-based serverless functions that run on a globally distributed network. Think of them as lightweight scripts that execute server side logic without you managing servers perfect for tasks that need to happen quickly, like processing payments or fetching data from APIs.

Why does this matter? Traditional serverless setups often run in a single region, leading to higher latency for users far away. Edge Functions flip that by deploying your code to edge nodes worldwide, so requests get handled closer to the source. Underneath, they're powered by Deno, a secure runtime that's TypeScript-native and supports things like WebAssembly (WASM) for extra flexibility.

You'll write these as single file handlers. Here's a bare-bones example to get the idea:

Typescript

Deno.serve(async (req) => {
  return new Response("Hello from the edge!");
});

This exports a handler that responds to incoming requests. Deno takes care of the rest, making it feel more like writing client-side code but with server powers.

Tip: for Beginners
Deno isn't Node.js don't try importing Node modules directly. Stick to Deno compatible libraries, and remember that environment variables are accessed via Deno.env.get('KEY'). This keeps things secure and avoids common compatibility headaches.

A Practical Example: Building Your First Function

Now that you've got the basics, let's put it into action. Suppose you want a function that echoes back whatever JSON you send it great for testing or simple APIs.

First, you'll use the Supabase CLI to set up locally. Install it if you haven't (npm install -g supabase), then run supabase init in your project folder. Create a new function with supabase functions new echo.

In your echo/index.ts file, drop this in:

Typescript

Deno.serve(async (req) => {
  if (req.method === 'POST') {
    const body = await req.json();
    return new Response(JSON.stringify({ echoed: body }), {
      headers: { 'Content-Type': 'application/json' },
      status: 200,
    });
  }
  return new Response('Only POST allowed', { status: 405 });
});

To test locally: supabase functions serve echo. Hit it with a tool like curl: curl -X POST http://localhost:54321/functions/v1/echo -H "Content-Type: application/json" -d '{"message": "Hello!"}'.

You'll see the response instantly. Deploy it globally with supabase functions deploy echo, and boom it's live on the edge network.

Tip: Gotcha for Beginners
Local serving mimics production, but watch for environment variables. Set them in your .env file and load with supabase secrets set, or you'll chase "undefined" errors when deploying.

Visual Intuition: Mapping the Architecture

Explanations are great, but visuals make things click. Imagine a flow where a user's request hits an edge gateway first think of it as a smart bouncer that checks auth, applies rules, and routes to the nearest runtime node.

Tip : Gotcha for Beginners
Don't assume the gateway handles everything automatically. You still need to verify auth in your code if sensitivity demands it, or risk exposing data on public endpoints.

Real-World Use Case: Handling a Stripe Webhook

Let's level up to something you'd actually ship. Say you're building an e-commerce app and need to process Stripe payments securely. Edge Functions shine here because webhooks require low-latency responses to avoid timeouts.

You'll create a function that listens for Stripe's checkout.session.completed event, then updates your Supabase database.

First, import the Supabase client:

Typescript

import { createClient } from '@supabase/supabase-js';
import Stripe from 'https://esm.sh/stripe@8.174.0?deno-std=0.63.0';

const supabase = createClient(
  Deno.env.get('SUPABASE_URL')!,
  Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
);

const stripe = Stripe(Deno.env.get('STRIPE_SECRET_KEY')!);

Deno.serve(async (req) => {
  if (req.method === 'POST') {
    const signature = req.headers.get('stripe-signature');
    let event;
    try {
      const body = await req.text();
      event = stripe.webhooks.constructEvent(
        body,
        signature!,
        Deno.env.get('STRIPE_WEBHOOK_SECRET')!
      );
    } catch (err) {
      return new Response(`Webhook Error: ${err.message}`, { status: 400 });
    }

    if (event.type === 'checkout.session.completed') {
      const session = event.data.object;
      // Update database
      const { error } = await supabase
        .from('orders')
        .update({ status: 'paid' })
        .eq('id', session.metadata.order_id);

      if (error) return new Response('DB Error', { status: 500 });
    }

    return new Response('Success', { status: 200 });
  }
  return new Response('Method Not Allowed', { status: 405 });
});

Deploy this, configure your Stripe webhook to point to the function URL, and you're set. This handles real payments with edge speed.

Why this works underneath: The gateway routes the request efficiently, Deno runs it securely, and Supabase integrations keep data in sync.

Tip: Gotcha for Beginners
Webhooks can replay events make your handlers idempotent (e.g., check if the order is already paid) to avoid duplicate updates.

Advanced Tips: Optimizing for Scale and Security

You've got the foundations now let's tweak for production. Edge Functions integrate deeply with Supabase's ecosystem, like using the service role key for admin access to Postgres or Storage.

For secrets: Store API keys via supabase secrets set STRIPE_KEY=sk_test_... and access with Deno.env.get().

Scaling tip: Avoid long-running tasks, offload to background workers. For concurrency, design functions to be stateless.

Advanced example: Generating OG images on-the-fly from Storage:

Typescript

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  Deno.env.get('SUPABASE_URL')!,
  Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
);

Deno.serve(async (req) => {
  const { data, error } = await supabase.storage
    .from('images')
    .download('template.png');

  if (error) return new Response('Error', { status: 500 });

  // Imagine processing with a library like Sharp (Deno-compatible)
  // For simplicity, return the raw image
  return new Response(data, {
    headers: { 'Content-Type': 'image/png' },
  });
});

This pulls from Storage and serves dynamicallygreat for social previews.

Security tip: Always validate JWTs manually if needed, even with gateway help.

Wrapping It Up: Why This Matters for Your Apps

We've covered a lot: From the Deno powered basics and simple setups to architectural flows, real Stripe integrations, optimization tricks, and pitfalls to dodge. At its heart, Supabase Edge Functions let you build scalable, low-latency backends without the infrastructure hassle empowering you to focus on features that delight users.

Next, experiment with your own function. Deploy something small, like a weather API wrapper, and see the speed difference. If you're hooked, explore deeper integrations or even self-hosting the runtime.
Feel free to tweak these examples and share what you build I'd love to hear how it goes!

An Interactive Guide to Firebase Cloud Messaging⌨️🧑‍💻

Krish Carter — Mon, 16 Feb 2026 14:30:30 +0000

Unlock the power of real-time push notifications and discover how FCM keeps your users engaged without draining your resources.

Hey there! If you've ever built a mobile or web app that needs to ping users with updates like a new message in a chat app or a breaking news alert you know how tricky notifications can be. They're essential for keeping users coming back, but handling them across platforms? That's where things get messy. Enter Firebase Cloud Messaging (FCM), Google's free, cross-platform service that makes sending notifications feel almost effortless.

In this guide, we'll dive deep into how FCM actually works under the hood. You'll learn the core concepts, walk through a practical setup, visualize the flow with diagrams, and even tackle advanced tricks. By the end, you'll be equipped to add reliable push notifications to your own projects, solving that nagging problem of user retention in a world full of distractions. Let's get started, I'll explain everything step by step, just like we're chatting over coffee.

Table of Contents

What is Firebase Cloud Messaging?
Setting Up FCM in Your App
Visualizing the Message Flow
A Real-World Use Case: Chat App Notifications
Advanced Tips for FCM
Common Mistakes and How to Avoid Them
Wrapping It Up

What is Firebase Cloud Messaging?

Let's start at the beginning. Firebase Cloud Messaging, or FCM, is essentially a messaging service from Google that lets you send notifications or data payloads to devices running your app. It's cross-platform, so whether your users are on Android, iOS, or even a web browser, FCM handles the delivery for you—at no cost.

Why does this matter? In real projects, notifications aren't just bells and whistles; they're the glue that keeps users engaged. Think about how apps like Twitter or WhatsApp pull you back in with timely alerts. FCM abstracts away the platform-specific headaches, like dealing with Apple's APNs or Android's Google Play Services, so you can focus on what your app does best.

At its core, FCM works by routing messages from your server (or a trusted environment like Cloud Functions) through Google's backend to the target devices. There are two main types of messages: notification messages, which the system automatically displays to the user, and data messages, which your app handles silently for custom logic.
Here's a quick example of what a basic notification message looks like in JSON format, as you'd send it from your server:

JSON

{
  "message": {
    "token": "DEVICE_TOKEN_HERE",
    "notification": {
      "title": "Hello from FCM!",
      "body": "This is your first push notification."
    }
  }
}

This payload gets sent via the FCM API, and poof the user's device shows a notification.

Tip: A common gotcha for beginners is confusing notification vs. data messages. If you send a notification message but want custom handling (like updating a chat UI without showing a banner), switch to data messages instead. It'll give you full control in your app's code.

Setting Up FCM in Your App

Now that you know what FCM is, let's get hands-on. We'll focus on integrating it into a web app, since that's a common starting point for many developers (and it plays nicely with JavaScript frameworks like React). The process is similar for mobile, but we'll keep it web-focused here for brevity.

First, why set this up? In a real project, this enables features like real-time updates without constant polling, saving battery and data. You'll need a Firebase project—head to the Firebase console, create one if you haven't, and grab your config object.

Start by including the Firebase SDK in your web app. Add this to your index.html:
HTML

<script src="https://www.gstatic.com/firebasejs/10.7.1/firebase-app.js"></script>
<script src="https://www.gstatic.com/firebasejs/10.7.1/firebase-messaging.js"></script>

Then, initialize Firebase and request the registration token (a unique ID for the device):

JavaScript

import { initializeApp } from 'firebase/app';
import { getMessaging, getToken, onMessage } from 'firebase/messaging';

const firebaseConfig = {
  // Your config from Firebase console
  apiKey: "YOUR_API_KEY",
  authDomain: "your-project.firebaseapp.com",
  projectId: "your-project",
  storageBucket: "your-project.appspot.com",
  messagingSenderId: "YOUR_SENDER_ID",
  appId: "YOUR_APP_ID",
  measurementId: "YOUR_MEASUREMENT_ID"
};

const app = initializeApp(firebaseConfig);
const messaging = getMessaging(app);

// Request permission and get token
Notification.requestPermission().then(permission => {
  if (permission === 'granted') {
    getToken(messaging, { vapidKey: 'YOUR_VAPID_KEY' }).then(token => {
      console.log('Registration token:', token);
      // Send this token to your server to store it
    }).catch(err => console.error('Error getting token:', err));
  }
});

// Handle incoming messages in the foreground
onMessage(messaging, payload => {
  console.log('Message received:', payload);
  // Display a custom notification or update UI
});

You'll also need a service worker for background messages. Create a firebase-messaging-sw.js file:

JavaScript

importScripts('https://www.gstatic.com/firebasejs/10.7.1/firebase-app.js');
importScripts('https://www.gstatic.com/firebasejs/10.7.1/firebase-messaging.js');

// Initialize with your config
firebase.initializeApp({ /* same config */ });

const messaging = firebase.messaging();

messaging.onBackgroundMessage(payload => {
  console.log('Background message:', payload);
  const notificationTitle = payload.notification.title;
  const notificationOptions = { body: payload.notification.body };
  self.registration.showNotification(notificationTitle, notificationOptions);
});

Gotcha: Don't forget to generate VAPID keys in the Firebase console under Cloud Messaging settings. Without them, web push won't work it's a security requirement for browser notifications.

For accessibility, ensure your notifications include alt text for icons and support screen readers by using semantic titles and bodies.

Visualizing the Message Flow

Explanations are great, but nothing beats a visual to make things click. Let's build some intuition around how a message travels from your server to a user's device.

Here's a simplified diagram in chart form:

You can see how FCM acts as the middleman, handling retries and platform quirks so you don't have to.

Tip: If you're debugging, use the Firebase console's Notifications Composer to test flows without server code. It's a lifesaver for visualizing delivery issues early.

A Real-World Use Case: Chat App Notifications

Theory and setup are fine, but let's apply this to something tangible. Suppose you're building a chat app like Slack or Discord. Users expect instant notifications for new messages, even when the app is closed.

Here's how FCM fits in: When a user sends a message, your backend (say, a Node.js server) detects it and sends a data message to the recipient's device token. The app then updates the chat UI or shows a custom notification.

Example server code using the Firebase Admin SDK:
JavaScript

const admin = require('firebase-admin');
admin.initializeApp({ /* credentials */ });

function sendChatNotification(toToken, sender, message) {
  const payload = {
    token: toToken,
    data: {
      type: 'chat',
      sender: sender,
      content: message
    }
  };
  admin.messaging().send(payload)
    .then(response => console.log('Notification sent:', response))
    .catch(error => console.error('Error:', error));
}

In your client app (web example), handle it:

onMessage(messaging, payload => {
  if (payload.data.type === 'chat') {
    // Update chat UI
    addMessageToUI(payload.data.sender, payload.data.content);
    // Optionally show a notification
    new Notification(`New message from ${payload.data.sender}`, { body: payload.data.content });
  }
});

This keeps conversations flowing in real time, boosting engagement. In a production app, you'd store tokens in a database and use topics for group chats.

Gotcha: For chat apps, always handle token refreshes—devices can get new tokens if the app is reinstalled. Miss this, and notifications stop working silently.

Advanced Tips for FCM
Once you're comfortable with basics, let's level up. FCM has features for scaling and customization that can make your notifications smarter.

First, use topics for broadcast-style messaging. Instead of sending to individual tokens, have devices subscribe to 'news' or 'promos':

JavaScript

// Client-side subscribe
getMessaging().subscribeToTopic('news');

Then send from server:

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "Something exciting happened!"
    }
  }
}

Common Mistakes and How to Avoid Them

Even pros trip up on FCM. One biggie: Treating tokens like eternal IDs. Tokens can expire or change, so always implement onNewToken handlers to update your server.

Another: Ignoring platform differences. Android handles background data messages seamlessly, but iOS requires special setup for silent pushes configure your APNs key properly.

Security slip-ups are common too. Never expose your server key in client code; use the Admin SDK only in trusted environments.

Finally, over-sending notifications. Users hate spam—use data messages for non-urgent updates to avoid notification fatigue.

Gotcha: If messages aren't delivering, check quotas. FCM limits multicasts to 500 devices per send; batch or use topics for larger groups.

For UX, make notifications dismissible and respect Do Not Disturb modes.

Demystifying Redux Toolkit: A Peek Under the Hood with Plain JavaScript

Krish Carter — Wed, 11 Feb 2026 12:32:35 +0000

A hands-on exploration of how Redux Toolkit simplifies state management while building on core JavaScript and Redux principles.

Hey there! If you've ever wrestled with Redux in a real-world app, you know it can feel like a beast boilerplate code everywhere, actions flying left and right, and reducers that grow like weeds. That's where Redux Toolkit swoops in like a friendly sidekick, cutting the cruft and letting you focus on what matters: building features.

In this guide, we'll pull back the curtain on how Redux Toolkit actually works underneath, all rooted in vanilla JavaScript and Redux fundamentals. You'll learn why it's not magic, but smart abstractions that make your code cleaner and more maintainable. By the end, you'll be able to spot the JavaScript patterns powering it, troubleshoot issues with confidence, and even roll your own simplifications if needed. Whether you're a Redux newbie or a seasoned pro, this will level up your mental model. Let's dive in!

Table of Contents

The Basics: What Redux Toolkit Is (and Isn't)
Practical Example: Building a Simple Slice
Visual Intuition: Data Flow Under the Covers
Real-World Use Case: Managing Async Data
Advanced Tips: Customizing and Extending
Common Mistakes: Pitfalls to Avoid
Wrapping It Up

The Basics: What Redux Toolkit Is (and Isn't)

Let's start simple. Redux Toolkit isn't a complete rewrite of Redux it's a set of utilities built right on top of it, designed to reduce boilerplate and enforce best practices. At its heart, it's all JavaScript: functions, objects, and immutable updates.
Why does this matter? In vanilla Redux, you'd manually create action types as strings, write action creators as functions, and build reducers with switch statements. It's error-prone and verbose. Redux Toolkit wraps these in higher-level APIs like createSlice, which generates all that for you under the hood.
For instance, createSlicetakes an object with your initial state, reducers, and a name. It returns a slice object with actions and a reducer. But underneath? It's using plain JS to create action types (like ${sliceName}/reducerName), action creators (functions that return { type, payload }), and a reducer function that uses Immer for immutable updates without you mutating state directly.

Here's a bare bones peek at what createSlice might look like if we simplified it in JS (this is conceptual, not the actual source):

Javascript

function createSlice({ name, initialState, reducers }) {
  const actions = {};
  const reducerCases = {};

  for (const [reducerName, reducerFn] of Object.entries(reducers)) {
    const type = `${name}/${reducerName}`;
    actions[reducerName] = (payload) => ({ type, payload });
    reducerCases[type] = reducerFn;
  }

  const reducer = (state = initialState, action) => {
    const handler = reducerCases[action.type];
    return handler ? handler(state, action) : state;
  };

  return { reducer, actions };
}

See? No sorcery just object iteration, string templates, and a reducer switch equivalent.

Tips: A common gotcha for beginners is thinking Redux Toolkit "mutates" state. It doesn't! It uses Immer.js to let you write mutable-looking code in reducers, but it produces immutable updates.

Always remember: under the hood, it's enforcing Redux's immutability rule to prevent bugs.

Practical Example: Building a Simple Slice

Alright, you've got the theory let's apply it. Imagine you're building a todo app. In vanilla Redux, you'd need separate files for actions and reducers, plus a bunch of constants. With Toolkit, it's one createSlice call.

First, install it (assuming you're in a React project): npm install @reduxjs/toolkit.
Now, create a slice for todos:

Javascript

import { createSlice } from '@reduxjs/toolkit';

const todosSlice = createSlice({
  name: 'todos',
  initialState: [],
  reducers: {
    addTodo: (state, action) => {
      state.push(action.payload); // Looks mutable, but Immer handles it!
    },
    toggleTodo: (state, action) => {
      const todo = state.find(t => t.id === action.payload);
      if (todo) todo.completed = !todo.completed;
    },
  },
});

export const { addTodo, toggleTodo } = todosSlice.actions;
export default todosSlice.reducer;

Underneath, configureStoreis just a wrapper around Redux's createStore, but it adds middleware like Redux Thunk by default and enables DevTools. In JS terms, it's combining reducers with combineReducersand applying enhancers.

To use it in a component:

JSX

import { useSelector, useDispatch } from 'react-redux';
import { addTodo } from './todosSlice';

function TodoList() {
  const todos = useSelector(state => state.todos);
  const dispatch = useDispatch();

  return (
    <ul>
      {todos.map(todo => <li key={todo.id}>{todo.text}</li>)}
      <button onClick={() => dispatch(addTodo({ id: Date.now(), text: 'New todo' }))}>
        Add Todo
      </button>
    </ul>
  );
}

This works because dispatching addTodosends an action like { type: 'todos/addTodo', payload: { ... } }, which the reducer handles immutably.

Don't forget to export both actions and the reducer! Beginners often miss this, leading to "undefined action" errors. Also, if you're coming from vanilla Redux, resist the urge to write switch statements Toolkit discourages it for good reason.

let's visualize the flow next.

Visual Intuition: Data Flow Under the Covers

Pictures help, right? Let's build some mental imagery for how data moves in Redux Toolkit, all powered by JS patterns.

At the core is unidirectional data flow: Components dispatch actions → Store updates via reducers → Components re-render with new state.

Underneath, when you call dispatch(addTodo(payload)), it's a plain function call. The action creator returns an object, the middleware (like Thunk) processes it if async, then the root reducer delegates to your slice reducer.
Think of it like a JS event bus: The store is an object with dispatch, subscribe, and getStatemethods. configureStoresets this up with enhancers for debugging.

For visual intuition, imagine a flowchart:

Action dispatched → Middleware chain (array of functions, each calling next).
Reducer called → Uses JS Object.assign or spread for immutability (via Immer).
Subscribers notified → React-Redux's useSelector hooks trigger re-renders.

Here's a simplified JS mimic of the store's dispatch loop:

Javascript

function createSimpleStore(reducer, initialState) {
  let state = initialState;
  const listeners = [];

  function dispatch(action) {
    state = reducer(state, action); // Immutable update here
    listeners.forEach(listener => listener());
  }

  function subscribe(listener) {
    listeners.push(listener);
    return () => listeners.splice(listeners.indexOf(listener), 1);
  }

  function getState() {
    return state;
  }

  return { dispatch, subscribe, getState };
}

Toolkit adds layers like auto-batching updates for performance.
Tip Box: For accessibility, ensure your app's state changes don't break keyboard navigation use ARIA live regions if toasts or modals rely on Redux state. It's a small UX win that Toolkit doesn't handle automatically.

Mastering Smooth Page Transitions with the View Transitions API in 2026

Krish Carter — Tue, 10 Feb 2026 13:15:56 +0000

You've built a beautiful React app. The data flows, the components are crisp, but every page change feels... abrupt. A flash of white, a jarring jump, maybe some custom Framer Motion wizardry that adds 50kb and still stutters on mobile. Sound familiar?

In 2026, users expect native-app polish on the web. The View Transitions API — now widely supported across major browsers changes the game. It lets the browser handle smooth, hardware-accelerated transitions between DOM states or even full page navigations, with minimal code.

By the end of this post, you'll know exactly how to add buttery smooth transitions to your SPA (or MPA!), understand why it outperforms custom solutions, and avoid the gotchas that trip up most developers.

Table of Contents

Why View Transitions Matter in Real Apps
The Basic Concept: How the Browser Takes Over
Implementing Same-Document Transitions in React
Cross-Document Magic: MPAs Without Frameworks
Customizing with view-transition-name
Advanced Patterns and Performance Wins
Common Mistakes and Gotchas
Wrapping Up: Level Up Your App's Feel

Why View Transitions Matter in Real Apps

Modern users switch between apps that feel alive: iOS/Android apps slide, morph, and fade with zero perceived latency. Web apps? Often still feel like... documents.
The View Transitions API bridges that gap. It captures snapshots of old + new states, animates them natively, and updates the DOM in between all while keeping focus, accessibility, and performance intact.

In real projects (dashboards, e-commerce, admin panels), this reduces cognitive load and makes your app feel 10x more premium. Best part? It's a browser feature — no React-specific hacks needed.

The Basic Concept: How the Browser Takes Over
The magic happens in two steps:

The browser snapshots the current DOM (old view).
You update the DOM.
The browser snapshots the new DOM and animates between them.

Default behavior: a smooth cross-fade.

Javascript

// Vanilla JS trigger
document.startViewTransition(() => {
  // Update your DOM here — React can do this too!
  updateMyUI(newState);
});

Under the hood, it creates pseudo-elements like ::view-transition-old(root) and ::view-transition-new(root) for CSS animation control.

Implementing Same-Document Transitions in React

In React SPAs (React Router, custom navigation), wrap route changes in startViewTransition.
Here's a practical hook:

jsx

import { useTransition } from 'react';

function useViewTransition() {
  const navigateWithTransition = (callback) => {
    if (!document.startViewTransition) {
      callback();
      return;
    }

    document.startViewTransition(() => {
      // React 18+ handles this suspendable
      callback();
    });
  };

  return navigateWithTransition;
}

Usage in a component:
Jsx

const navigate = useViewTransition();

<button
  onClick={() => navigate(() => setPage('details'))}
>
  Go to Details
</button>

Accessibility Note:
The API preserves focus and doesn't disrupt screen readers — huge win over custom animations!

Pro Tip:
Combine with React's useTransition for pending states during data fetches.

Cross-Document Magic: MPAs Without Frameworks

For static sites, Astro, or plain HTML add this CSS to both pages:

CSS

@view-transition {
  navigation: auto;
}

That's it. Page navigations now fade smoothly. No JS required!
For React + Next.js App Router, it's automatic in recent versions, but you can customize.

Customizing with view-transition-name

The real power: name elements to animate specifically (morphing cards, expanding images).

CSS

.product-card {
  view-transition-name: product-1;
  contain: paint; /* Important for isolation */
}

.product-detail img {
  view-transition-name: product-1;
}

The browser auto-animates position, size, opacity no keyframes needed.

Pro Tip:
Use dynamic names in React: view-transition-name: product-${id};

Advanced Patterns and Performance Wins

Group animations with view-transition-class
Custom keyframes on ::view-transition-old(...)
Types for conditional transitions: @view-transition { types: slide; }

Performance: Native → GPU-accelerated, tiny overhead vs. libraries like GSAP.
In benchmarks, apps with View Transitions feel 2–3x snappier on low-end devices.

Common Mistakes and Gotchas

Forgetting fallbacks — always check support.
Mutating DOM outside the callback → broken snapshots.
Using with heavy SSR mismatches → hydration errors.
Ignoring contain: paint/layout → animation glitches.
Over-customizing defaults — the built-in crossfade is often best.

Accessibility Note:
Test with reduced motion (prefers-reduced-motion) — disable or simplify transitions.

🧩 Further Reading:

MDN View Transitions API
Chrome for Developers: Smooth transitions with the View Transitions API
Personal takeaway: Sometimes the best DX comes from leaning on the platform — the web is getting pretty magical again. 🚀

Why Solid.js Might Be the Most Underrated Frontend Superpower in 2026 (And How to Start Using It Today)

Krish Carter — Tue, 20 Jan 2026 12:16:33 +0000

Hey fellow frontend devs, let's be real for a second.

You're building yet another dashboard or e-commerce app. You fire up React (or Next.js because SSR is non-negotiable in 2026), write some components, throw in useState/useEffect everywhere, and suddenly your bundle is ballooning, re-renders are happening like fireworks, and your Lighthouse score is crying in the corner.
Sound familiar?

In 2026, the conversation has shifted. While React remains the king of ecosystems and job listings, and Svelte keeps winning hearts with its "write less, do more" compiler magic, there's a quiet powerhouse that's been stealing benchmarks and developer minds: Solid.js.

It's like React's reactivity model but without the virtual DOM tax, delivering React like ergonomics with Svelte-level performance. If you've been sleeping on Solid.js, 2026 is the year to wake up.
In this post, I'll break down why Solid.js feels like the perfect "future proof" choice right now, how its fine-grained reactivity works under the hood, and give you a practical starter guide with real code examples.

The Pain Point: React's Hidden Cost in 2026

React's virtual DOM diffing was revolutionary in 2013. But in 2026, with massive apps, concurrent features, and Server Components, we still pay a price:

Unnecessary re-renders cascade through component trees
Bundle sizes creep up with client-side hydration
Profiling tools become your best friend (and worst enemy)

Alternatives like Svelte compile away the framework entirely, and Qwik resumable architecture skips hydration drama. But many of us love React's mental model hooks, JSX, unidirectional data flow.

Enter Solid.js: It gives you the best of both worlds.

Solid.js uses fine-grained reactivity with signals (inspired by libraries like MobX or Preact Signals, but baked in). Instead of re-rendering entire components, Solid updates only the DOM nodes that actually changed.

Think of it like this analogy:

React is like repainting an entire room every time someone moves a chair.
Solid.js is like having smart paint that only refreshes the exact spot where the chair moved.
Result? Blazing-fast updates, tiny runtime (~7-10KB gzipped), and no VDOM overhead.

How Solid.js Reactivity Actually Works (No Magic, Just Signals)

At its core, Solid uses primitives like createSignal, createEffect, and createMemo.
Here's a simple counter example:
tsx

import { createSignal, createEffect } from 'solid-js';

function Counter() {
  const [count, setCount] = createSignal(0);

  // This effect runs only when count changes
  createEffect(() => {
    console.log(`Count is now: ${count()}`);
  });

  return (
    <div>
      <p>Count: {count()}</p>
      <button onClick={() => setCount(count() + 1)}>
        Increment
      </button>
    </div>
  );
}

Notice something missing? No useState+ useEffect dependency array hell.

count() is a getter that tracks dependencies automatically
Updates are surgical — only the text node inside {count()} re-renders
No component re-execution unless signals force it

For derived state, use createMemo:
tsx

const [firstName, setFirstName] = createSignal('Krish');
const [lastName, setLastName] = createSignal('Dev');

const fullName = createMemo(() => `${firstName()} ${lastName()}`);

fullName() recomputes only when firstName or lastName changes no wasteful recalculations.

Tailwind + Solid.js = Developer Joy in 2026

Pair it with** Tailwind CSS v4 (now even faster with native Oxide engine) and you get utility classes that feel native in Solid's JSX.
Add **Vite + solid-js/vite plugin, and your dev server is instant. No more waiting for HMR in large React apps.

Pros in 2026:

Unmatched runtime performance (often beats Svelte in fine-grained updates)
React-like syntax (easy transition for React devs)
Tiny runtime, zero VDOM
Growing ecosystem: SolidStart (full-stack like Next.js), stores, primitives, etc.
TypeScript first-class

Cons:

Smaller community than React (but growing fast in 2026)
Fewer ready-made component libraries (but Headless UI + Tailwind works great)

In 2026, frontend isn't about picking "the one true framework" anymore. It's about choosing the right tool for the job. If performance, clean reactivity, and modern DX matter to you (and they should), give Solid.js a weekend. You might just find your new favorite.

React Server Components + TanStack Query: The 2026 Data-Fetching Power Duo You Can't Ignore🧑‍💻⌨️

Krish Carter — Mon, 19 Jan 2026 16:29:46 +0000

Introduction: The Eternal Data-Fetching Struggle Is (Almost) Over
If you've been building React apps for any amount of time, you know the pain: fetch data on the client → show loading spinner → handle errors → cache it somehow → refetch on focus → pray the UI doesn't flicker. In 2024, we threw TanStack Query (formerly React Query) at the problem and it worked wonders. But in 2026, React Server Components (RSC) arrived like a plot twist nobody saw coming suddenly, data can live on the server, zero client JS for static parts, and streaming renders that feel magical.

The real game-changer? Combining React Server Components with TanStack Query. This duo gives you the best of both worlds: lightning fast initial loads from the server + smart, optimistic client-side caching, mutations, and background refetches. It's not either/or anymore it's the hybrid architecture that's powering the fastest, most maintainable React apps today.

Why This Combo Wins in 2026

Frontend performance in 2026 isn't optional Google's Core Web Vitals are stricter, users bounce if LCP > 2.5s, and SEO demands fast Time to First Byte.

React Server Components fetch data on the server, render HTML/streamed UI, and send zero JS for those parts. Perfect for staticish content like product lists or dashboards.
TanStack Query handles client-side needs: infinite scrolling, mutations with optimistic UI, stale while revalidate, deduping requests, and background sync.

Together, they eliminate waterfalls, reduce bundle size, and give you fine grained control.
Real-world impact? Teams report 40-70% faster initial loads and dramatically lower TTI when migrating legacy React apps to this pattern.

Pattern 1: Server Components for Initial Data + TanStack Query for Interactivity

This is the most common 2026 pattern in Next.js 15+ apps.
Imagine a dashboard showing user stats:

Server fetches core data → renders static UI.
Client uses TanStack Query for live updates, filters, or mutations.

tsx

// app/dashboard/page.tsx (Server Component)
import { getUserStats } from '@/lib/api';

export default async function Dashboard() {
  const initialStats = await getUserStats(); // Runs on server, no client JS

  return (
    <div className="p-6">
      <h1 className="text-3xl font-bold">Your Dashboard</h1>
      <StaticStats initialStats={initialStats} />
      <InteractiveCharts /> {/* Client component */}
    </div>
  );
}

// components/StaticStats.tsx (Server Component - passed props)
function StaticStats({ initialStats }: { initialStats: UserStats }) {
  return (
    <div className="grid grid-cols-3 gap-4 mt-6">
      <StatCard title="Total Revenue" value={`$${initialStats.revenue}`} />
      {/* more cards */}
    </div>
  );
}

// components/InteractiveCharts.tsx (Client Component)
'use client';

import { useQuery } from '@tanstack/react-query';
import { fetchLiveStats } from '@/lib/api';

export function InteractiveCharts() {
  const { data, isLoading } = useQuery({
    queryKey: ['liveStats'],
    queryFn: fetchLiveStats,
    initialData: initialStats, // from server props (passed via context or prop drilling)
    staleTime: 30 * 1000, // 30s freshness
  });

  if (isLoading) return <div>Updating...</div>;

  return (
    // Chart with live data, optimistic updates on filters, etc.
  );
}

Why it rocks: Server delivers fully-rendered HTML instantly. TanStack Query kicks in for interactivity without duplicating fetches.

Pattern 2: Mutations & Optimistic Updates – The Killer Feature

Server Components can't mutate (they're async functions, not interactive). TanStack Query shines here.

Example: Like button on a post.
tsx

'use client';

import { useMutation, useQueryClient } from '@tanstack/react-query';

function LikeButton({ postId, initialLikes }: { postId: string; initialLikes: number }) {
  const queryClient = useQueryClient();

  const mutation = useMutation({
    mutationFn: () => likePost(postId),
    onMutate: async () => {
      // Optimistic update
      await queryClient.cancelQueries({ queryKey: ['post', postId] });
      const previous = queryClient.getQueryData(['post', postId]);
      queryClient.setQueryData(['post', postId], (old: any) => ({
        ...old,
        likes: old.likes + 1,
      }));
      return { previous };
    },
    onError: (err, vars, context) => {
      queryClient.setQueryData(['post', postId], context?.previous);
    },
    onSettled: () => {
      queryClient.invalidateQueries({ queryKey: ['post', postId] });
    },
  });

  return (
    <button
      onClick={() => mutation.mutate()}
      className="flex items-center gap-2"
      disabled={mutation.isPending}
    >
      ❤️ {initialLikes + (mutation.isPending ? 1 : 0)}
    </button>
  );
}

The server component provides initialLikes, TanStack Query handles the rest optimistic UI, rollback on error, and refetch.

When to Use What: Decision Guide

Pure Server Components (RSC only) — Landing pages, blogs, marketing sites. Zero JS, max speed.
TanStack Query only— Highly interactive SPAs (admin panels, real-time apps).
Hybrid (RSC + TanStack Query) — Most modern apps: dashboards, e-commerce, SaaS. Best DX and perf in 2025.

Pro tip: Use Next.js or TanStack Start for seamless integration. Both support RSC natively in 2026.

Actionable Takeaways & Next Steps

Start small:- Migrate one page to Server Components + pass initial data to client queries.
Adopt TanStack Query v5+ :- It has better RSC support and suspense integration.
Measure everything :- Use Vercel Analytics or Web Vitals to track LCP/TTI before/after.
Experiment :- Build a side project with Next.js 15 + TanStack Query. You'll feel the difference immediately.

The frontend world moved fast in 2026, but this combo feels like the "right" architecture for the next few years fast, scalable, and actually fun to build with.
What do you think are you all in on Server Components yet, or still team TanStack Query client-side? Drop your thoughts in the comments!

Happy coding! 🚀

The React Compiler Just Made Your Memoization Skills Obsolete, Here's What to Do Next

Krish Carter — Sat, 17 Jan 2026 03:47:40 +0000

Hey friend,
Remember that moment when your beautifully crafted React component starts re-rendering like it's auditioning for a fireworks show? You dig in, sprinkle useMemoand useCallbackeverywhere, wrap things in React.memo, and pray the performance gods smile upon you.
Then you ship it… and discover one rogue prop is still causing the whole subtree to explode.
Yeah. We've all been there.

In 2026, that entire song and dance routine is quietly becoming optional. Meta dropped React Compiler 1.0 late last year, and it's changing the game for anyone building serious React apps. No more manual memoization gymnastics in most cases the compiler does it for you at build time.

But here's the twist: this freedom comes with new responsibilities. You can't just flip the switch and forget everything you know about React's rendering model. In fact, understanding why the compiler works (and when it doesn't) has become one of the highest leverage skills for frontend engineers this year.

In this post, you'll learn:

What React Compiler actually does under the hood
How to adopt it progressively without breaking your app
The mental model shift from manual optimization → compiler-friendly code
Real patterns that still need your attention (because the compiler isn't magic)

Let's dive in.

The Old World: Why Memoization Used to Hurt
Meet React Compiler: Your New Silent Partner
How It Actually Works (Intuition + Visual)
Practical Migration: From Legacy to Compiler-Ready
Gotchas & Advanced Patterns That Still Matter
Real-World Wins: Where It's Saving Teams Time & Bundle Size
The New Mental Model: Write Simple, Let It Optimize
Summary & Next Steps

The Old World: Why Memoization Used to Hurt

Before the compiler, React performance was a discipline problem.
Every render could cascade down the tree. Props change → children re-render → grandchildren re-render → tears.
So we fought back with:

tsx

// Classic stabilization
const expensiveValue = useMemo(() => computeHeavyThing(data), [data]);

const handleClick = useCallback(() => {
  // do stuff
}, []); // empty deps? Careful!

const MemoChild = React.memo(ChildComponent);

This worked… until it didn't. Forget a dep? Infinite loop. Add too many? Over-optimization tax on readability.

Note:-Manual memoization is like defensive driving — useful, but exhausting when you do it for every mile.

Meet React Compiler: Your New Silent Partner

React Compiler (formerly "React Forget") is a Babel plugin + build-time optimizer. It analyzes your components statically and automatically inserts the useMemo/useCallback/React.memo wrappers you would have written… but smarter.

Key promises:

Fine-grained reactivity without manual effort
No runtime overhead (optimizations happen at build)
Works with hooks, components, and custom hooks

From the docs: it turns "naive" code into optimized code automatically.

tsx

// Before compiler: manual everything
function TodoList({ todos }) {
  const sortedTodos = useMemo(() => [...todos].sort(), [todos]);
  // ...
}

// After compiler: just write clean code
function TodoList({ todos }) {
  const sortedTodos = [...todos].sort(); // ← Compiler memos this!
}

The compiler figures out dependencies and memoizes where safe.
Accessibility Note: Cleaner code = fewer bugs = better a11y outcomes. Win-win.

How It Actually Works (Intuition + Visual)

Think of the compiler as a super-smart linter that rewrites your render function.
It tracks:

What values are "pure" (no side effects)
Which deps they depend on
Where mutations could break things

Then it injects memoization only where needed.

Practical Migration: From Legacy to Compiler-Ready

Don't enable it globally on day one that's a recipe for frustration.

Step-by-step:

Install & configure (Next.js, Vite, Expo all have first-class support in 2026)

Bash

npm install babel-plugin-react-compiler

Add to babel.config:
Javascript

plugins: [
  ['babel-plugin-react-compiler', { target: '19' }]
]

Use incremental adoption: 'use no memo' directive to opt-out of problematic files. tsx:

'use no memo'; // Compiler skips this component

function TrickyComponent() { ... }

Run ESLint with compiler plugin — it catches things that block optimization early.

Advanced Patterns That Still Matter

The compiler isn't perfect (yet). Watch for:

Side effects in render — console.log inside render? Compiler may bail.
Complex mutations — If you mutate props/objects directly, it can't guarantee safety.
Dynamic deps — Things like useMemo(() => fn(dep ? a : b), [dep]) can confuse it.

Common mistake:
tsx

// Compiler might not optimize this well
const value = expensiveCalc(props.data?.nested?.deep);

Better:

const data = props.data;
const value = expensiveCalc(data?.nested?.deep);

Also, Server Components + Compiler = rocket fuel. Use them together for insane perf.

Real-World Wins: Where It's Saving Teams Time & Bundle Size

Teams adopting it report:

20-40% reduction in manual memo code
Noticeably smoother UIs in large lists/dashboards
Faster onboarding: juniors write simple code, compiler handles perf

One case study saw homepage render time drop 35% with zero manual changes after cleanup.

The New Mental Model: Write Simple, Let It Optimize

Shift your focus:

Write straightforward, declarative code
Avoid unnecessary side effects in render
Lean on ESLint + compiler feedback
Optimize intentionally only when profiler says so

You're no longer the performance janitor you're the architect.

Summary

React Compiler isn't about replacing your skills; it's about elevating them. The tedious parts are automated, so you can focus on architecture, DX, and user experience.
Next steps:

Try it on a small feature branch today
Add the ESLint plugin — treat warnings as build errors
Pair it with Server Components for maximum impact
Profile before & after — numbers don't lie

This is the year React performance becomes boring (in a good way).

If this helped you level up, share it with a friend still drowning in useMemo. And stay tuned — next I'll dive into how Server Actions + Compiler are killing traditional state management.

Until then, keep shipping fast & smooth ✨

Mastering React Server Components: The 2026 Way to Build Blazing Fast Apps Without the Hydration Tax

Krish Carter — Fri, 16 Jan 2026 03:39:05 +0000

Imagine you're building a dashboard for an e-commerce admin panel. Hundreds of products, user analytics, real-time stats. You fetch everything on the client, throw in a few useEffectcalls, and suddenly your bundle balloons to 200KB+ of JavaScript. Users on slow connections wait... and wait... while the spinner spins.

We've all been there. The hydration tax hurts. In 2026, React Server Components (RSCs) change the game completely. They let you run components entirely on the server, send HTML to the client, and only "wake up" the interactive parts with minimal JS. The result? Faster initial loads, better SEO, and a mental model that feels refreshingly simple once it clicks.
In this post, you'll learn exactly how RSCs work, when to use them, practical patterns with Next.js App Router, and how to avoid the most common footguns. By the end, you'll be ready to refactor your next project for real performance wins.

Table of Contents

What Are React Server Components?
The Fundamental Shift: Server-First Mental Model
Practical Example: Building a Product Detail Page
Visual Intuition: How the Data Flows
Real-World Use Case: Dashboard with Streaming
Advanced Tips: Composing Server + Client Components
Common Mistakes & Gotchas
Summary & Next Steps

What Are React Server Components?

React Server Components are components that **never **run on the client. They execute only on the server, can access databases, file systems, or secrets directly, and render to static HTML (or RSC payload) that's streamed to the browser.
Key differences from classic "client" components:

No hooks like useState, useEffect(no interactivity by default)
Zero client-side JS for these parts
Can be async (await fetches right in the component)

Pro Tip
Server Components are the default in Next.js App Router. Just write your component — if you need client features, add "use client"; at the top.

This shift means most of your UI can be server-rendered, slashing bundle sizes and improving Core Web Vitals.

Practical Example: Building a Product Detail Page

tsx

// app/products/[id]/page.tsx
// This is a Server Component by default

import { getProduct } from '@/lib/api';
import AddToCartButton from './AddToCartButton'; // Client component

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id); // Runs on server, can be DB query

  return (
    <div className="max-w-4xl mx-auto p-6">
      <h1 className="text-3xl font-bold">{product.name}</h1>
      <p className="text-xl text-gray-600 mt-2">${product.price}</p>

      <img 
        src={product.image} 
        alt={product.name} 
        className="w-full h-96 object-cover rounded-lg mt-6"
      />

      <div className="mt-8">
        <h2 className="text-2xl font-semibold">Description</h2>
        <p className="mt-4">{product.description}</p>
      </div>

      {/* Only this part needs interactivity */}
      <AddToCartButton productId={product.id} />
    </div>
  );
}

tsx

// AddToCartButton.tsx
"use client";

import { useState } from 'react';

export default function AddToCartButton({ productId }: { productId: string }) {
  const [status, setStatus] = useState<'idle' | 'adding' | 'added'>('idle');

  const handleAdd = async () => {
    setStatus('adding');
    // Simulate API call
    await new Promise(r => setTimeout(r, 800));
    setStatus('added');
  };

  return (
    <button
      onClick={handleAdd}
      disabled={status === 'adding'}
      className="mt-6 px-8 py-4 bg-blue-600 text-white rounded-lg font-medium hover:bg-blue-700 disabled:opacity-50 transition"
    >
      {status === 'adding' ? 'Adding...' : status === 'added' ? 'Added! 🎉' : 'Add to Cart'}
    </button>
  );
}

See? 90% of the page is server-rendered, zero JS for the static content.

Gotcha!
You cannot pass functions or complex objects as props from Server to Client components only serializable data (strings, numbers, etc.).

Visual Intuition: How the Data Flows

The magic is streaming: users see the product title and image first, then description fills in as data arrives no full-page loading spinner.

Real-World Use Case: Dashboard with Streaming
In a real admin dashboard, you might have:

Header (server)
Sidebar with user data (server)
Main content: charts loading slowly (streamed)
Interactive filters (client island)

Use Suspenseboundaries to stream sections independently:

tsx

<Suspense fallback={<Skeleton />}>
  <SlowChart dataPromise={fetchAnalytics()} />
</Suspense>

This is huge for perceived performance.

Advanced Tips: Composing Server + Client Components

Nest Client inside Server: Fine!
Nest Server inside Client: Not allowed (importing server component in client throws error)
Use Server Actions for mutations (form actions that run on server)
Leverage async/await in components for clean data fetching

Pro Tip
Combine with React 19's useOptimistic for instant feedback on actions, then sync with server.

Common Mistakes & Gotchas

Trying to use hooks in Server Components — instant error. Solution: Move to client.
Passing non-serializable props — functions, Dates, etc. → stringify or convert.
Forgetting Suspense — no streaming, worse UX.
Overusing Client Components — ask: "Does this need state or effects?" If no, make it server.
State leakage — never use global stores in server code (e.g., Zustand pitfalls).

Summary
React Server Components represent the biggest architectural shift since Hooks. By defaulting to server rendering, streaming content, and minimizing client JS, you build apps that feel native fast even on 3G.

Further Reading:

React Server Components RFC (official docs)
Next.js App Router Patterns for Data Fetching
Personal takeaway: Once you experience streaming + minimal JS, going back to full-client feels like time travel to 2018.

Why Islands Architecture is the SSR Wake-Up Call Your React App Has Been Begging For🧑‍💻🚀

Krish Carter — Mon, 01 Dec 2025 14:14:26 +0000

Build lightning-fast, interactive UIs without the hydration headaches—discover how "islands" can slash your bundle sizes and boost user delight in real-world apps.

Table of Contents

What Are "Islands," and Why Should You Care?
The SSR Struggle: Why Full Hydration is Draining Your App
Building Your First Island: A Hands-On React Example
Visualizing the Magic: Islands in Action
Real-World Use Case: Turbocharging an E-Commerce Dashboard
Advanced Islands: Optimization and Edge Cases
Common Pitfalls and How to Dodge Them
Wrapping Up: Chart Your Course to Island Paradise

What Are "Islands," and Why Should You Care?

Before we dive into the "how," let's unpack the "why." Traditional SSR in frameworks like Next.js renders your entire page on the server, ships HTML to the browser, and then hydrates it all with JavaScript to make it interactive.

It's like watering your whole lawn to keep one flower alive efficient until it's not. Enter Islands Architecture: a pattern where most of your page stays static HTML (no JS overhead), but "islands" small, isolated components get selectively hydrated for interactivity. Think of it as planting sprinklers only where the grass actually grows.

This isn't some ivory tower theory. Pioneered by folks at frameworks like Astro and Qwik, islands solve real pains: massive JS payloads, hydration mismatches, and zombie states where static content fights dynamic updates. In practice, it means your app loads in under 100ms, SEO thrives on static shells, and users get instant feedback where it counts like a search bar or carousel, not the footer links.

Pro Tip:Islands shine in content-heavy sites (blogs, docs) or hybrid apps. If your page is 80% static, you're leaving performance on the table.

Accessibility note: Islands preserve semantic HTML for screen readers out of the box, since static parts don't rely on JS. Just ensure your hydrated islands emit ARIA compliant events.

The SSR Struggle: Why Full Hydration is Draining Your App

Full hydration sounds great on paper ship HTML, then "wake it up" with JS. But here's the rub: Your entire component tree re-runs on the client, even for non-interactive bits like a hero image or static nav. This leads to "hydration waterfalls": one slow component blocks the lot, inflating TTI (Time to Interactive) and frustrating users.
Consider a typical Next.js page: A blog post with a comment form. You hydrate everything—the post body, sidebar ads, even the copyright notice just to enable comments. Result? 1.5MB JS for a 10KB interaction. No wonder 53% of mobile users abandon sites taking over 3 seconds to load (Google stats, anyone?).

Islands fix this by defaulting to static rendering and opting in to hydration. It's declarative: Mark interactive zones explicitly, and the framework handles the rest. Why care? Faster loads = happier users = better metrics. In A/B tests I've run, island-ified pages saw 25% uplift in engagement. Your turn.

Building Your First Island: A Hands-On React Example

Enough theory let's build. We'll use Next.js 14+ with the experimental dynamic API to create an island for a simple search component. Assume you've got a fresh Next.js app (npx create-next-app@latest).
First, set up your page in app/page.tsx:

// app/page.tsx
import StaticContent from '@/components/StaticContent';
import SearchIsland from '@/components/SearchIsland';

export default function Home() {
  return (
    <main>
      <StaticContent />
      <SearchIsland />
    </main>
  );
}

Now, the static part (components/StaticContent.tsx): Pure HTML, no JS.

// components/StaticContent.tsx
export default function StaticContent() {
  return (
    <section>
      <h1>Welcome to Island Paradise</h1>
      <p>This static bliss loads instantly—no hydration needed.</p>
      <ul>
        <li>Fast first paint</li>
        <li>SEO-friendly</li>
        <li>Zero JS bloat</li>
      </ul>
    </section>
  );
}

Enter the island (components/SearchIsland.tsx): This gets hydrated client-side only.

// components/SearchIsland.tsx
'use client'; // Marks this as client-only island

import { useState } from 'react';

interface SearchIslandProps {
  initialResults: string[];
}

export default function SearchIsland({ initialResults }: SearchIslandProps) {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState(initialResults);

  const handleSearch = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = e.target.value;
    setQuery(value);
    // Simulate API call
    setResults(initialResults.filter(item => item.includes(value)));
  };

  return (
    <div role="search" aria-label="Site search">
      <input
        type="search"
        value={query}
        onChange={handleSearch}
        placeholder="Search islands..."
        aria-autocomplete="list"
      />
      <ul aria-live="polite">
        {results.map((result, idx) => (
          <li key={idx}>{result}</li>
        ))}
      </ul>
    </div>
  );
}

Pass static props from the server:

// In page.tsx, add:
<SearchIsland initialResults={['React Island', 'SSR Lagoon', 'Hydration Cove']} />

Run npm run dev watch the magic. The page paints instantly, then the search input "wakes up" without re-rendering the static content. Boom: Selective hydration achieved.

Note:- Forgetting 'use client' turns your island into a static rock. Always mark interactive components explicitly to avoid mismatches.

Visualizing the Magic: Islands in Action

Imagine your app as an archipelago. The ocean? Static HTML, calm and quick. Each island? A hydrated hotspot, buzzing with life. Tools like React DevTools show this: Static nodes are inert; islands light up with state.

Visually, it's like progressive enhancement on steroids. Users see content now, interact soon. Intuition: Hydration isn't a flood it's targeted rain. This mental model prevents over-engineering: Ask, "Does this need JS?" 90% of the time, no.

Real-World Use Case: Turbocharging an E-Commerce Dashboard

Let's scale it. You're building a dashboard for an online store product grids (mostly static), filters (interactive), and a cart widget (dynamic). Full SSR? Grid hydrates pointlessly, slowing everything.

Refactor: Make the grid an island for lazy-loaded images, filters a full island, cart another. In Next.js:

// app/dashboard/page.tsx
import ProductGrid from '@/components/ProductGrid'; // Static
import FiltersIsland from '@/components/FiltersIsland'; // Hydrated
import CartIsland from '@/components/CartIsland'; // Hydrated

export default async function Dashboard() {
  const products = await fetchProducts(); // Server fetch

  return (
    <div>
      <ProductGrid products={products} />
      <FiltersIsland initialFilters={defaultFilters} />
      <CartIsland />
    </div>
  );
}

ProductGrid.tsx stays static: Loop over props, render <ul> with images. Filters and Cart get 'use client' for state. Result? Dashboard loads in 800ms vs. 3s, with filters responding in 50ms. In my last project, this cut cart abandonment by 15% users felt the speed.

**Accessibility win: **Static grids work offline and with JS disabled, falling back gracefully.

Pro Tip: Use Suspense boundaries around islands for streaming: }>. It's like async loading your treasures.

Advanced Islands: Optimization and Edge Cases

You've got the basics now level up. For shared state across islands? Libraries like Zustand (lightweight) or signals in Qwik prevent prop-drilling hell. Bundle splitting? Webpack's magicModules auto chunks islands.
Edge case: Nested islands. Avoid deep nesting flatten for perf. In React, use dynamic imports:

import dynamic from 'next/dynamic';
const NestedWidget = dynamic(() => import('@/components/Widget'), { ssr: false });

Measure with Lighthouse: Aim for 90+ perf scores. Pro move: Pre-hydrate critical islands via <script> tags for sub-100ms interactivity.

Common Pitfalls and How to Dodge Them

1.Over-islanding: Not everything needs hydration keep islands <10% of your tree. Dodge: Audit with why did you render.
2.Hydration mismatches from timestamps/dates. Fix: Render dates server side with toISOString().
3.SEO woes if islands hold key content. Solution: Prerender dynamic props.

Don't turn your app into the Bermuda Triangle test islands in dev/prod to avoid vanishing interactions.