DEV Community: Tanzim Hossain

The Precompute Pattern: How to Stop One Cookie from Wrecking Your Entire Next.js App

Tanzim Hossain — Sun, 12 Apr 2026 18:20:00 +0000

A deep dive into the pattern that keeps pages static when your app needs to know who's logged in

You build a product page in Next.js. Statically generated. Served from the CDN. Fast.

Then someone says: "The header should show the user's name when they're logged in."

You add a cookies() call to the root layout. You push to production. And suddenly — every single page in your app is dynamically rendered. Your CDN cache is useless. Your TTFB tanks. And you're staring at the terminal wondering what just happened.

This is one of the most common performance traps in Next.js. And the Precompute Pattern is one of the cleverest ways people have worked around it.

The problem: one dynamic call poisons the whole tree

Here's the thing about Next.js rendering. When a component calls a dynamic API — cookies(), headers(), searchParams — it opts that component into dynamic rendering. That's expected.

What catches people off guard is the cascade. When the call happens in the root layout, every page nested under it becomes dynamic too. The whole route tree falls over.

A typical e-commerce root layout looks like this:

// app/layout.tsx
export default async function RootLayout({ children }: { children: React.ReactNode }) {
  const isLoggedIn = await isAuthenticated(); // reads cookies()

  return (
    <html>
      <body>
        <Header isLoggedIn={isLoggedIn} />
        <main>{children}</main>
      </body>
    </html>
  );
}

That one isAuthenticated() call — which reads cookies internally — drags the product listing, the category pages, the marketing homepage, everything into dynamic rendering. The only user-specific part might be a login button in the header. But the entire site pays the price.

The Precompute Pattern: encode it, don't read it

The idea is simple: instead of reading dynamic data inside your components, resolve it once in middleware (now called the proxy in Next.js), encode it into the URL, and let the page read it from params.

Here's the flow:

A request hits the proxy
The proxy reads cookies() and figures out the user's state (logged in or not)
It encodes that state as a base64url string
It prepends that string to the URL as a hidden path segment
Next.js routes to something like /eyJsb2dnZWRJbiI6dHJ1ZX0/products
The page reads the encoded data from params — no cookies() call needed

The browser still sees /products. The encoded segment is invisible to the user. But the server treats each combination as a distinct, cacheable URL.

Because the page never calls cookies() or headers() directly, Next.js can statically generate it. And because the URL is unique per user state, you can pre-build every known variant at deploy time.

How to build it

Let's walk through the actual code. This is based on a real commerce demo, simplified for clarity.

Step 1: Define your context shape

First, decide what data you want to encode. Start small — auth state is the classic example. You can always add more later (locale, user type, feature flags).

// utils/request-context.ts
export interface RequestContextData {
  loggedIn: boolean;
  // Other things you might add later:
  // locale?: string;       // 'en', 'no', 'sv'
  // currency?: string;     // 'USD', 'EUR', 'NOK'
  // userType?: 'b2c' | 'b2b';
}

// Turn context into a short URL-safe string
export function encodeRequestContext(data: RequestContextData): string {
  const json = JSON.stringify(data);
  return Buffer.from(json).toString('base64url');
}

// Decode it back, with a safe fallback if something goes wrong
export function decodeRequestContext(encoded: string): RequestContextData {
  try {
    const json = Buffer.from(encoded, 'base64url').toString();
    const data = JSON.parse(json);
    return {
      loggedIn: typeof data.loggedIn === 'boolean' ? data.loggedIn : false,
    };
  } catch {
    return { loggedIn: false };
  }
}

// Convenient wrapper for use inside components
export function getRequestContext(params: { requestContext: string }): RequestContextData {
  return decodeRequestContext(params.requestContext);
}

The encoding produces short strings like eyJsb2dnZWRJbiI6dHJ1ZX0. Not pretty, but URL-safe and fast to decode.

Step 2: Encode in the proxy

The proxy runs on every request. It reads the cookie, encodes the context, and rewrites the URL.

// proxy.ts
import { NextResponse } from 'next/server';
import { encodeRequestContext } from '@/utils/request-context';
import type { NextRequest } from 'next/server';

function isUserAuthenticated(request: NextRequest): boolean {
  return !!request.cookies.get('selectedAccountId')?.value;
}

export function proxy(request: NextRequest) {
  const encodedContext = encodeRequestContext({
    loggedIn: isUserAuthenticated(request),
  });

  // Prepend the encoded context as the first URL segment
  const nextUrl = new URL(
    `/${encodedContext}${request.nextUrl.pathname}${request.nextUrl.search}`,
    request.url
  );

  // Internal rewrite — the browser URL stays unchanged
  return NextResponse.rewrite(nextUrl, { request });
}

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|favicon.ico|.*\\..*).*)'],
};

The key here is NextResponse.rewrite. It changes what the server serves, but the browser URL stays as /products. The user sees nothing different.

Step 3: Read context in components

Components that previously called cookies() now read from the decoded params instead.

import { getRequestContext } from '@/utils/request-context';

export default async function UserProfile({
  params,
}: {
  params: Promise<{ requestContext: string }>;
}) {
  const { requestContext } = await params;
  const { loggedIn } = getRequestContext({ requestContext });

  if (!loggedIn) {
    return <LoginButton />;
  }

  return <ProfileMenu />;
}

No cookies() call. No dynamic rendering. The component just reads from params and renders accordingly.

The layout itself becomes simple — it just passes children through without needing to resolve any auth state:

// app/[requestContext]/layout.tsx
export default function RequestContextLayout({ children }: LayoutProps) {
  return (
    <>
      <Header rightContent={<UserProfile />} />
      <main>{children}</main>
    </>
  );
}

Step 4: Pre-generate variants with generateStaticParams

This is where the pattern pays off. With just auth state, you have two variants: logged in and logged out. You can pre-generate both at build time.

// app/[requestContext]/products/page.tsx
import { encodeRequestContext } from '@/utils/request-context';

export async function generateStaticParams() {
  return [
    { requestContext: encodeRequestContext({ loggedIn: false }) },
    { requestContext: encodeRequestContext({ loggedIn: true }) },
  ];
}

Any combination not pre-generated falls back to ISR — more on why that matters in a moment.

Vercel's Flags SDK formalizes this exact pattern

This isn't something someone invented from scratch. Vercel's Flags SDK formalizes it under the name "precompute" — and it's the same concept, just with tooling on top.

The SDK encrypts flag values into a URL segment. The proxy reads flags from a feature flag provider, encodes the result, and rewrites the request. Pages read the encoded hash from params and use it to look up flag values.

// middleware.ts (Flags SDK version)
import { precompute } from 'flags/next';
import { marketingFlags } from './flags';

export async function proxy(request: NextRequest) {
  const code = await precompute(marketingFlags);

  const nextUrl = new URL(
    `/${code}${request.nextUrl.pathname}${request.nextUrl.search}`,
    request.url
  );

  return NextResponse.rewrite(nextUrl, { request });
}

The pattern is identical to what we built manually. The SDK adds: encryption of flag values, integrations with providers like LaunchDarkly and Statsig, and a helper for generating all flag permutations.

The Flags SDK documentation also recommends a discipline worth paying attention to: use multiple, scoped flag groups rather than one giant global group. This matters more than it seems, which is why.

The trap: variant count explodes fast

Here's where teams get into trouble. Look at your file system with the Precompute Pattern:

app/
└── [requestContext]/
    ├── page.tsx              # home
    ├── all/page.tsx          # product listing
    ├── product/[id]/page.tsx # product detail (thousands of products)
    ├── cart/page.tsx
    └── about/page.tsx

With just auth state: 2 variants per page. Fine.

Add 3 locales: 6 variants. Still manageable.

Add 4 currencies: 24 variants. Getting bigger.

Add 2 A/B test flags: 96 variants per page.

Now multiply 96 by 10,000 product pages: 960,000 page variants to build or cache.

ISR was designed for regeneration of existing pages, not progressive generation of new ones. When a request hits a variant that hasn't been built yet, the user waits for a full synchronous render before seeing anything. No fallback shell. No streaming. Just a cold start.

And every deploy blows out the ISR cache — a CSS change can affect every page, leading to a flood of writes relative to reads when the cache warms back up.

The teams that handle this well are selective. Auth state and locale go in because they have low cardinality and affect large chunks of the page. Feature flags with many possible values stay out, or get scoped to specific pages. The Flags SDK recommendation to use multiple scoped flag groups isn't just ergonomics — it's how you avoid making this problem worse.

Does 'use cache' in Next.js 16 make this unnecessary?

Short answer: for the auth-in-layout problem specifically, yes. For the broader use case, not entirely.

Next.js 16 introduced cacheComponents — a way to annotate individual components with 'use cache' so they cache independently from the rest of the page. Combined with Partial Prerendering, this changes the trade-off completely.

Instead of encoding auth state into the URL, you pass the auth check as a promise through a provider, without awaiting it in the layout:

// app/layout.tsx
export default async function RootLayout({ children }: LayoutProps) {
  const loggedIn = getIsAuthenticated(); // no await — returns a promise

  return (
    <html lang="en">
      <body>
        <AuthProvider loggedIn={loggedIn}>
          <Header />
          <main>{children}</main>
        </AuthProvider>
      </body>
    </html>
  );
}

The layout doesn't block. The promise flows into components that need it. Server components resolve it directly. Client components unwrap it with React's use():

export const useLoggedIn = () => {
  const { loggedIn } = useAuth();
  return use(loggedIn);
};

Static components cache themselves independently:

// features/product/components/FeaturedProducts.tsx
export default async function FeaturedProducts() {
  'use cache';
  cacheTag('featured-product');

  const products = await getFeaturedProducts(4);
  return (
    <div>
      {products.map(product => (
        <ProductCard key={product.id} {...product} />
      ))}
    </div>
  );
}

The cookies() call in UserProfile makes only that component dynamic. FeaturedProducts, Hero, FeaturedCategories — everything marked with 'use cache' — becomes part of the static shell that ships immediately. The dynamic user profile streams in behind it.

That said, 'use cache' solves the auth-in-layout case. It doesn't solve everything.

If your cached components need to vary by locale, currency, user type, or feature flags — if those values affect what the cached component itself renders — then you can't just suspend them as dynamic. For those cases, the Precompute Pattern (or the Flags SDK) remains the right tool, even alongside 'use cache'.

The missing piece: rootParams

One of the roughest edges of the Precompute Pattern is prop drilling. The requestContext param needs to flow from the root segment down to every component that reads it. In a deep component tree, that gets tedious fast.

An upcoming Next.js feature called rootParams addresses this directly. Instead of threading values through the tree, components can import root parameters directly:

import { locale } from 'next/root-params';

async function CachedComponent() {
  'use cache';
  const currentLocale = await locale();
  // ...
}

The value automatically becomes a cache key for 'use cache' — so cached components can vary by locale or any other root parameter without manual prop passing.

For the Precompute Pattern specifically, rootParams would mean the encoded hash can be accessed anywhere in the tree without drilling it through props. Teams using precomputed feature flags wouldn't need placeholder generateStaticParams on every page just to satisfy the build.

It's not shipped yet, but it's the piece that makes the ergonomics of this pattern genuinely pleasant.

When to use this pattern

Use the Precompute Pattern when:

You have low-cardinality dynamic data that affects large portions of the page (auth state, locale, user type)
You want full static generation with CDN-level caching for pages that are otherwise identical across requests
You're working with feature flags on marketing pages where the variants can be pre-built at deploy time

Think twice before using it when:

Your context has many possible values — variant count multiplies fast
You're relying on ISR for on-demand generation — cold starts hurt on every new variant
You're on Next.js 16 with cacheComponents available — 'use cache' likely solves your specific problem more cleanly

The honest summary

The Precompute Pattern is a genuine piece of production engineering. It's not something you'll use on every project — but when you have a high-traffic site where CDN cache hit rate directly translates to cost and user experience, understanding this pattern matters.

The Vercel Flags SDK formalizes it. E-commerce teams at scale live by it. And even as 'use cache' in Next.js 16 makes it unnecessary for many common cases, the pattern remains the right answer for feature flags, A/B testing, and multi-dimensional personalization where content needs to be statically distinct per combination.

The cardinality problem is real, and it requires discipline. Start with the lowest-cardinality dimensions. Scope flags to the pages that need them. Pre-generate only the most common combinations. Let ISR handle the rest — but know that every cold start costs you.

And keep an eye on rootParams. When it ships, the last rough edge of this pattern disappears.

Auth.js v5 + Google OAuth: How to Create Users With the Correct Role (The Right Way)

Tanzim Hossain — Wed, 17 Dec 2025 15:14:56 +0000

If you are using Auth.js v5 (NextAuth) with Google OAuth and role-based onboarding, you will likely hit this issue:

No matter what role the user selects,
new users created via Google login always get the same role.

This article explains why this happens and shows a clean, reliable, production-safe solution that actually works.

No hacks. No guessing. No fragile behavior.

The Real Problem

In many applications, users choose a role during signup, for example:

Student
Teacher

Then they click Continue with Google.

But after Google login:

The selected role is gone
Google does not send role data
Frontend state is lost
Backend has no idea what role was chosen

As a result, developers hardcode a default role — which breaks onboarding.

Why This Happens (OAuth Reality)

OAuth is redirect-based.

The flow looks like this:

User clicks “Continue with Google”
Browser leaves your app
Google handles authentication
Browser returns to your app

Anything stored in:

React state
Props
Local variables
In-memory values

❌ does not survive this redirect

Google only returns identity, not application roles.

So unless you persist the role before OAuth starts, the backend will never see it.

The Correct Mental Model

OAuth handles identity
Your backend handles roles
Redirects destroy frontend state

To solve this, you need something that:

Survives redirects
Is available on the server
Is short-lived
Does not grant authority

That thing is a secure, temporary cookie.

The Solution: Secure Short-Lived Cookie

We store the user’s role choice in a cookie before starting Google OAuth.

Cookies automatically survive redirects and are available on the server.

This is a common pattern in real production systems.

Step 1: Store Role in a Secure Cookie (Client)

Before calling signIn():

function setOAuthRole(role: "student" | "teacher") {
  document.cookie = [
    `oauth_role=${role}`, // The data we need
    "Path=/", // Available across the app
    "Max-Age=300",   // 5 minutes
    "SameSite=Lax",
    "Secure",        // HTTPS only
  ].join("; ");
}

Then start OAuth:

setOAuthRole(role);
await signIn("google");

At this point:

The role is safely stored
Redirects won’t erase it

Step 2: Read the Cookie on the Server

Inside your Auth.js configuration:

import { cookies } from "next/headers";

function resolveOAuthRole(): "STUDENT" | "TEACHER" {
 const cookieStore = await cookies();
  const role = cookieStore.get("oauth_role")?.value;

  return role === "teacher" ? "TEACHER" : "STUDENT";
}

This function:

Validates input
Applies a safe default
Prevents invalid roles

Step 3: Create the User With the Correct Role

Inside callbacks.signIn:

async signIn({ user, account }) {
  if (account?.provider === "google") {

    const role = await resolveOAuthRole();

    let authUser = await prisma.authUser.findUnique({
      where: { email: user.email! },
    });

    if (!authUser) {
      authUser = await prisma.authUser.create({
        data: {
          email: user.email!,
          role,
          provider: "google",
          providerId: user.id,
        },
      });
    }

    user.id = authUser.id;
    (user as any).role = authUser.role;
  }

  return true;
}

Now:

New users get the correct role
Existing users keep their role
JWT and session reflect the database

Step 4: Delete the Cookie After Use (Important)

Always clean up after user creation:

cookies().delete("oauth_role");

This prevents accidental role reuse on future logins.

Security Considerations

This approach is safe because:

Cookie is short-lived
Role is validated server-side
Database is the source of truth
Cookie does not grant permissions
Authorization still relies on RBAC

The cookie only represents temporary intent, not authority.

Why This Works Reliably

Cookies survive OAuth redirects
Auth.js v5 always exposes cookies on the server
No dependency on provider behavior
No fragile assumptions
No undocumented internals

This is why this solution works consistently in real applications.

Final Takeaway

If you are using Auth.js v5 with:

Google OAuth
App Router
Role-based onboarding

👉 Store role intent in a secure, short-lived cookie before OAuth

It is simple, predictable, and production-ready.

Remember This

OAuth gives you who the user is
Your system decides what the user can do

Once you separate those concerns, OAuth stops being confusing.

If you want follow-up articles:

Role upgrade flow (student → teacher)
Teacher approval workflow
Multi-tenant roles per organization
Auth.js v5 RBAC architecture

Just tell me — happy to help 🚀

How to Fix the Copilot Sidebar in Microsoft Edge on Linux

Tanzim Hossain — Tue, 04 Nov 2025 04:29:49 +0000

A simple, two-command fix to get the AI assistant working on Ubuntu and other distros.

You’ve installed Microsoft Edge on your Linux machine, ready to take advantage of its features. You click the familiar Copilot icon in the top-right corner, expecting the AI-powered sidebar to appear... and nothing happens.

If you’ve experienced this, you’re not alone. It’s a common frustration for Edge users on Ubuntu and other Linux distributions. While the browser works perfectly, this one key feature seems broken. The good news is that the fix is incredibly simple.

The problem comes down to a single missing configuration file called HubApps that is present in the Windows version but absent in the Linux installation. By manually adding this file, you can get the Copilot sidebar working in under a minute.

Here’s how to do it.

Step 0: A Quick Prerequisite Check

This fix uses a command-line tool called wget to download the missing file. Most systems, including Ubuntu, have it pre-installed. Let's quickly check.

Open your terminal and type:

which wget

If the command returns a path (like /usr/bin/wget), you’re all set. If it returns nothing, just run the following command to install it:

sudo apt update && sudo apt install wget

Now that we're ready, let's get to the fix.

The Fix: Choose Your Installation Path

The location of Edge's configuration files depends on how you installed it. Find the option below that matches your setup.

Option A: For Flatpak Installations

If you installed Microsoft Edge from the Software Center or using the flatpak command, its configuration is sandboxed in a specific folder.

1. Navigate to the Directory
Open your terminal and run this command to move into the correct folder:

cd ~/.var/app/com.microsoft.Edge/config/microsoft-edge/Default

2. Download the Missing File
Now, run this command to download the HubApps file directly into the folder:

wget https://raw.githubusercontent.com/RPDJF/dotfiles/refs/heads/master/.myconfig/ressources/HubApps

Option B: For Standard .deb/APT Installations

If you downloaded the .deb file from the Microsoft website and installed it using apt or dpkg, your configuration files are in a different location.

1. Navigate to the Directory
Open your terminal and use this command instead:

cd ~/.config/microsoft-edge/Default

2. Download the Missing File
Next, run the same wget command to download the file:

wget https://raw.githubusercontent.com/RPDJF/dotfiles/refs/heads/master/.myconfig/ressources/HubApps

Final Step: Restart and Enjoy

That’s all there is to it. The final, crucial step is to completely close all Microsoft Edge windows and restart the browser.

Now, click the Copilot icon. The sidebar will spring to life, fully functional, just as it does on Windows.

It’s a strange oversight that this file isn’t included by default, but thankfully, the Linux community found a quick and easy workaround. Hopefully, this simple guide saved you some time and frustration.

If this guide helped you, feel free to give it a clap or two! Happy browsing.

Understanding the Leaky Bucket Algorithm for System Design

Tanzim Hossain — Sun, 28 Sep 2025 02:52:44 +0000

Rate limiting is a lifesaver in distributed systems. Without it, APIs, message queues, or servers can choke under sudden traffic spikes, leading to slowdowns or crashes. The Leaky Bucket algorithm is a go-to solution for keeping request rates steady and predictable. Unlike other methods that might allow bursts, this algorithm enforces a smooth flow, which is perfect for systems that can’t handle surprises.

I’ve always found the Leaky Bucket’s simplicity elegant. It’s not just about capping requests—it’s about ensuring your system behaves predictably under pressure. Let’s break down how it works, why it’s useful, and how to implement it effectively.

Why the Leaky Bucket Matters

The Leaky Bucket algorithm comes from network traffic shaping, originally used in routers to manage data packet flow. Today, it’s a staple in API rate limiting, message queues, and IoT systems. Its strength lies in smoothing out traffic spikes, ensuring your system processes requests at a consistent rate.

Think of it like a barista at a busy coffee shop. They can only make so many lattes per minute, no matter how many orders pile up. The Leaky Bucket ensures the line doesn’t get out of control, keeping both the barista and the customers happy.

How the Leaky Bucket Works

Imagine a bucket with a small hole at the bottom. Requests pour in, but the bucket leaks at a fixed rate, representing your system’s processing capacity. If too many requests arrive and the bucket fills up, extras are rejected or delayed. This setup guarantees a steady output, no matter how chaotic the input.

Here’s the core logic:

Bucket Capacity (C): The maximum number of requests the bucket can hold.
Leak Rate (R): How many requests leak out (are processed) per second.
Queue Size (Q): The current number of requests in the bucket.

The queue size updates over time with this formula:

Q = max(0, Q + incomingRequests - R * timeElapsed)

If Q exceeds C, new requests get rejected. It’s that simple, but it’s powerful for preventing overload.

A Real-World Example

Let’s say your API has a bucket with a capacity of 10 requests and a leak rate of 1 request per second. Here’s what happens:

The bucket starts empty. Five requests arrive at once. All are accepted, so the queue size is now 5.
After one second, one request leaks out (processed), dropping the queue to 4.
Suddenly, 12 requests hit. The bucket can only take 6 more (to hit capacity of 10), so 6 are rejected.

This smoothing effect protects your system from being overwhelmed, ensuring consistent performance.

Implementing the Leaky Bucket

Here’s a JavaScript implementation to make the concept concrete:

class LeakyBucket {
  constructor(capacity, leakRate) {
    this.capacity = capacity;
    this.leakRate = leakRate;
    this.queue = 0;
    this.lastCheck = Date.now();
  }

  leak() {
    const now = Date.now();
    const elapsed = (now - this.lastCheck) / 1000;
    this.queue = Math.max(0, this.queue - Math.floor(elapsed * this.leakRate));
    this.lastCheck = now;
  }

  allowRequest() {
    this.leak();
    if (this.queue < this.capacity) {
      this.queue += 1;
      return true;
    }
    return false;
  }
}

// Usage
const bucket = new LeakyBucket(10, 1);
setInterval(() => {
  console.log(`Request allowed? ${bucket.allowRequest()}`);
}, 200);

This code tracks the queue size, leaks requests over time, and checks if new requests can be accepted. It’s lightweight and works for single-server setups.

For distributed systems, things get trickier. You’d store the bucket state in Redis or a database, using atomic operations to avoid race conditions. Sharding buckets by user ID or API key can help scale horizontally.

Where the Leaky Bucket Shines

The Leaky Bucket is a great fit for systems that need strict control over request rates. Some examples:

APIs with tight SLAs: Payment processors or authentication services that can’t afford hiccups.
Network routers: Managing packet flow to prevent congestion.
Message queues: Ensuring consumers aren’t overwhelmed by sudden spikes.
IoT systems: Controlling data from thousands of edge devices.

I’ve seen it used in payment APIs to prevent fraud detection systems from choking during holiday sales. It’s a reliable way to keep things steady.

Leaky Bucket vs. Token Bucket

The Leaky Bucket isn’t the only rate-limiting algorithm out there. The Token Bucket, for example, allows short bursts of traffic as long as tokens are available. If your system can handle occasional spikes, Token Bucket might be better. But if you need rock-steady throughput, Leaky Bucket is your friend.

The choice depends on your use case. I lean toward Leaky Bucket when stability trumps flexibility, like in critical infrastructure.

Performance Tips

The Leaky Bucket is efficient but not free. Here’s how to keep it lean:

Memory: Only store queue counters, not individual requests. This keeps memory usage constant (O(1) per bucket).
CPU: Leaking and refilling are simple math operations, so CPU cost is minimal.
Latency: In distributed setups, network calls to Redis or a database can add latency. Optimize by batching updates or caching locally.

If you’re handling millions of users, group them into shared buckets to reduce overhead. Just be careful not to overcomplicate things—I’ve seen teams get lost in premature optimization here.

Conclusion

The Leaky Bucket algorithm is a straightforward, battle-tested way to manage traffic in distributed systems. Its predictable behavior makes it easy to reason about, and its simplicity means you can implement it without pulling your hair out. For me, the real beauty is how it forces you to think about your system’s limits upfront, which is half the battle in system design.

Next time you’re building an API or queue that needs to stay rock-solid under load, give Leaky Bucket a try. It’s not flashy, but it gets the job done.

Token Bucket Algorithm Explained

Tanzim Hossain — Sat, 27 Sep 2025 16:57:56 +0000

why rate limiting matters

every API or system has limits. without some control, a single user could flood your server with requests and take it down. rate limiting solves this by controlling how many requests pass through over time.

there are many algorithms for this—fixed window, sliding window, leaky bucket, and token bucket. among them, token bucket is one of the most popular because it balances steady traffic control with short bursts of requests.

what is the token bucket algorithm?

imagine a bucket that holds tokens:

tokens are added at a fixed rate (e.g. 5 per second).
each request must “spend” one token to pass.
if tokens are available → request is allowed.
if the bucket is empty → request is rejected (or delayed).
the bucket has a maximum size, so tokens don’t grow forever.

this allows short bursts (if tokens have been saved up) while still enforcing an average rate over time.

diagram of token bucket

here’s a simple flow of how it works:

and a refill view:

the math behind it

let’s define:

C = bucket capacity
R = refill rate (tokens per second)
T = elapsed time since last refill

then the number of tokens at any moment is:

tokens = min(C, tokens + R * T)

when a request comes in:

if tokens > 0 → allow and tokens -= 1
else → reject

example run

capacity = 10
refill rate = 1 token/sec

timeline:

time 0s → bucket full (10 tokens)
user sends 5 requests instantly → 5 tokens left
time 5s later → 5 tokens refilled, bucket = 10 again
user sends 15 requests → only 10 succeed, 5 rejected

this shows how token bucket allows bursts up to capacity, but keeps the long-term rate limited.

pros and cons

pros

allows bursts but enforces average rate
smooth traffic shaping
widely used in networking & APIs

cons

slightly more complex than fixed window counter
needs careful sync in distributed systems

code example (javascript)

class TokenBucket {
  constructor(capacity, refillRate) {
    this.capacity = capacity;       // max tokens
    this.tokens = capacity;         // current tokens
    this.refillRate = refillRate;   // tokens per second
    this.lastRefill = Date.now();
  }

  refill() {
    const now = Date.now();
    const elapsed = (now - this.lastRefill) / 1000;
    const added = Math.floor(elapsed * this.refillRate);
    if (added > 0) {
      this.tokens = Math.min(this.capacity, this.tokens + added);
      this.lastRefill = now;
    }
  }

  allowRequest() {
    this.refill();
    if (this.tokens > 0) {
      this.tokens -= 1;
      return true;
    }
    return false;
  }
}

// usage
const bucket = new TokenBucket(10, 1); // 10 tokens, refill 1/sec

setInterval(() => {
  console.log("request allowed?", bucket.allowRequest());
}, 200);

real-world use cases

API gateways (AWS, Nginx, Envoy use variations of this)
network routers (token bucket for traffic shaping)
message queues (ensuring consumers don’t get overloaded)

comparing with other methods

Fixed Window Counter → simpler, but can allow unfair bursts at the edges.
Leaky Bucket → enforces a steady rate, but less flexible with bursts.
Token Bucket → combines steady rate with short bursts → best balance for APIs.

conclusion

the token bucket algorithm is one of the most practical ways to implement rate limiting. it’s simple enough to code, supports burst traffic, and ensures fair usage over time.

if you’re building an API or distributed system, token bucket should be one of your go-to options.

Mastering React HOCs: A Clear Guide to Reusable Code 🚀

Tanzim Hossain — Mon, 21 Apr 2025 05:16:45 +0000

I’ve been diving deep into React patterns, organizing my thoughts in Notion, and Higher-Order Components (HOCs) have truly been a game-changer! 🌟 They help you reuse code and keep your app clean and organized. In this post, I’ll break down what HOCs are, share simple examples, and explore real-world use cases—all in an easy-to-follow way. Whether you’re new to React or leveling up your skills, you’ll see why HOCs are worth learning. Let’s dive in! 🎉

What’s an HOC in React? 🤔

A Higher-Order Component (HOC) is a function that takes a component and returns a new one with extra features. Think of it as upgrading a plain bike to an electric one—it’s still a bike, but now it does more! 🚴‍♂️⚡

Here’s the basic idea:

Start with a component, like a button or form. 🔘
The HOC wraps it, adding features like data fetching or user authentication. 🔄
You get a new component that’s more powerful without modifying the original. 💪

Why Use HOCs?

Save Time: Avoid repeating code across components. 🔄
Stay Clean: Keep your components focused and tidy. 🧼
Share Logic: Reuse the same logic across your app. 🔗

Let’s see an HOC in action with some practical examples. 👀

Example 1: Debugging Props with an HOC 🐞

When I started with React, I struggled to track props, often wasting time on typos. So, I built an HOC to log props to the console—a simple way to debug without cluttering my components! 🛠️

Code: `checkProps.js`

// HOC to log props for debugging
export const checkProps = (Component) => {
  // Returns a new component
  return (props) => {
    // Show props in console
    console.log("Props received:", props);
    // Pass all props to the original component
    return <Component {...props} />;
  };
};

Usage: `App.js`

import { checkProps } from "./checkProps"; // Import HOC
import { UserInfo } from "./UserInfo"; // Import component

// Wrap UserInfo with HOC
const UserInfoWrapper = checkProps(UserInfo);

function App() {
  return (
    <div>
      {/* Use wrapped component with props */}
      <UserInfoWrapper name="John" age={23} />
    </div>
  );
}

export default App;

Component: `UserInfo.js`

// Simple component to show user info
export const UserInfo = ({ name, age }) => (
  <div>
    <h2>{name}</h2>
    <p>Age: {age}</p>
  </div>
);

How It Works

checkProps takes a component (like UserInfo).
It returns a new component that:
- Logs the props (e.g., { name: "John", age: 23 }) to the console.
- Passes all props to UserInfo using {...props}.
In App.js, we use UserInfoWrapper instead of UserInfo.
Open your console, and you’ll see the props printed!

Why It’s Useful

No more adding console.log everywhere! This HOC lets you debug props for any component, keeping your code clean. 🧹 I used to typo prop names all the time—this HOC helped me spot mistakes fast. Try it for quick debugging! ⏱️

Example 2: Fetching Data with an HOC 📡

HOCs are awesome for handling data, like fetching user info from a server. This example shows an HOC that pulls user details and lets you edit them in a form—practical and reusable! 🔄

Code: `includeUpdatableUser.js`

import { useEffect, useState } from "react";
import axios from "axios"; // For server requests

// HOC to fetch and edit user data
export const includeUpdatableUser = (Component, userId) => {
  return (props) => {
    // Store original user data
    const [user, setUser] = useState(null);
    // Store editable user data
    const [updatableUser, setUpdatableUser] = useState(null);

    // Fetch data when component loads
    useEffect(() => {
      (async () => {
        const response = await axios.get(`/users/${userId}`);
        setUser(response.data); // Save original
        setUpdatableUser(response.data); // Save editable
      })();
    }, []); // Run once

    // Update data when user types
    const userChangeHandler = (updates) => {
      setUpdatableUser({ ...updatableUser, ...updates });
    };

    // Save changes to server
    const userPostHandler = async () => {
      const response = await axios.post(`/users/${userId}`, {
        user: updatableUser,
      });
      setUser(response.data); // Update original
      setUpdatableUser(response.data); // Update editable
    };

    // Reset to original data
    const resetUserHandler = () => {
      setUpdatableUser(user);
    };

    // Pass data and functions to component
    return (
      <Component
        {...props}
        updatableUser={updatableUser}
        changeHandler={userChangeHandler}
        userPostHandler={userPostHandler}
        resetUserHandler={resetUserHandler}
      />
    );
  };
};

Usage: `UserInfoForm.js`

import { includeUpdatableUser } from "./includeUpdatableUser";

// Wrap form with HOC
export const UserInfoForm = includeUpdatableUser(
  ({ updatableUser, changeHandler, userPostHandler, resetUserHandler }) => {
    // Get name and age, or empty if null
    const { name, age } = updatableUser || {};

    // Show form or loading
    return updatableUser ? (
      <div>
        <label>
          Name:
          <input
            value={name}
            onChange={(e) => changeHandler({ name: e.target.value })}
          />
        </label>
        <br />
        <label>
          Age:
          <input
            value={age}
            onChange={(e) => changeHandler({ age: Number(e.target.value) })}
          />
        </label>
        <br />
        <button onClick={resetUserHandler}>Reset</button>
        <button onClick={userPostHandler}>Save</button>
      </div>
    ) : (
      <h3>Loading...</h3>
    );
  },
  "3" // User ID
);

function App() {
  return <UserInfoForm />;
}

export default App;

How It Works

includeUpdatableUser takes a component and userId.
It fetches data (e.g., { name: "John", age: 23 }) from /users/${userId}.
It uses two states:
- user: Original data.
- updatableUser: Editable copy.
It passes four props to the component:
- updatableUser: Data to display.
- changeHandler: Updates data on input.
- userPostHandler: Saves changes to the server.
- resetUserHandler: Restores the original data.
UserInfoForm renders a form to edit the user’s name and age, with buttons to save or reset.

Why It’s Useful

This HOC handles all data tasks—fetching, editing, saving—so your form stays focused on the UI. You can reuse it for any user by swapping the userId. My app crashed once without a loading state, but adding <h3>Loading...</h3> fixed it. Always cover loading cases! ⏳

Example 3: A Reusable HOC for Any Resource 🔄

The user HOC was cool, but I wanted something more flexible—for products, posts, or any data. This generic HOC cuts down on repetitive code and works for any resource! ✂️

Code: `includeUpdatableResource.js`

import { useEffect, useState } from "react";
import axios from "axios";

// Capitalize names (e.g., "product" -> "Product")
const toCapital = (str) => str.charAt(0).toUpperCase() + str.slice(1);

// HOC for any resource
export const includeUpdatableResource = (Component, resourceUrl, resourceName) => {
  return (props) => {
    // Original data
    const [data, setData] = useState(null);
    // Editable data
    const [updatableData, setUpdatableData] = useState(null);

    // Fetch data on load
    useEffect(() => {
      (async () => {
        const response = await axios.get(resourceUrl);
        setData(response.data);
        setUpdatableData(response.data);
      })();
    }, []); // Run once

    // Update editable data
    const changeHandler = (updates) => {
      setUpdatableData({ ...updatableData, ...updates });
    };

    // Save to server
    const dataPostHandler = async () => {
      const response = await axios.post(resourceUrl, {
        [resourceName]: updatableData,
      });
      setData(response.data);
      setUpdatableData(response.data);
    };

    // Reset to original
    const resetHandler = () => {
      setUpdatableData(data);
    };

    // Dynamic props (e.g., product, onChangeProduct)
    const resourceProps = {
      [resourceName]: updatableData,
      [`onChange${toCapital(resourceName)}`]: changeHandler,
      [`onSave${toCapital(resourceName)}`]: dataPostHandler,
      [`onReset${toCapital(resourceName)}`]: resetHandler,
    };

    // Pass props to component
    return <Component {...props} {...resourceProps} />;
  };
};

Usage: `ProductForm.js`

import { includeUpdatableResource } from "./includeUpdatableResource";

// Wrap product form with HOC
export const ProductForm = includeUpdatableResource(
  ({ product, onChangeProduct, onSaveProduct, onResetProduct }) => {
    const { name, price } = product || {};

    return product ? (
      <div>
        <label>
          Product Name:
          <input
            value={name}
            onChange={(e) => onChangeProduct({ name: e.target.value })}
          />
        </label>
        <br />
        <label>
          Price:
          <input
            value={price}
            onChange={(e) => onChangeProduct({ price: Number(e.target.value) })}
          />
        </label>
        <br />
        <button onClick={onResetProduct}>Reset</button>
        <button onClick={onSaveProduct}>Save</button>
      </div>
    ) : (
      <h3>Loading...</h3>
    );
  },
  "/products/1", // Product URL
  "product" // Resource name
);

function App() {
  return <ProductForm />;
}

export default App;

How It Works

includeUpdatableResource takes:
- Component: The component to wrap.
- resourceUrl: Data source (e.g., /products/1).
- resourceName: Name like "product".
It fetches data and stores it in data (original) and updatableData (editable).
It creates dynamic props like product, onChangeProduct, onSaveProduct, and onResetProduct.
ProductForm uses these props to edit a product’s name and price.

Why It’s Useful

This HOC works for any data—users, products, posts, you name it! Just change the URL and resource name. It’s a one-size-fits-all tool for fetching and editing. 🛠️ The dynamic props with toCapital make it feel polished. Test it with different resources to see its power! 💪

Real-World HOC Use Cases 🌍

HOCs aren’t just for fetching data—they solve all kinds of real-world problems. Here are three common use cases with examples to inspire you! 💡

1. Securing Pages with Authentication 🔒

Want to restrict a page to logged-in users or admins? An HOC can handle that for you.

Code: `withAuth.js`

import { useAuth } from "./useAuth"; // Get user info
import Redirect from "./Redirect"; // Redirect component
import AccessDenied from "./AccessDenied"; // Error component

// HOC to check login and role
export const withAuth = (requiredRole) => (Component) => (props) => {
  const { user } = useAuth();

  // No user? Go to login
  if (!user) {
    return <Redirect to="/login" />;
  }

  // Wrong role? Show error
  if (requiredRole && user.role !== requiredRole) {
    return <AccessDenied />;
  }

  // All clear? Show component
  return <Component {...props} user={user} />;
};

Usage

import { withAuth } from "./withAuth";

// Admin-only dashboard
const AdminDashboard = withAuth("admin")(({ user }) => (
  <div>
    <h2>Welcome, {user.name}!</h2>
    <p>Admin Dashboard</p>
  </div>
));

function App() {
  return <AdminDashboard />;
}

export default App;

Why It’s Useful

This HOC protects pages without cluttering your components with login checks. Reuse it for any restricted page!

2. Tracking Page Visits 📈

Need to track when users visit a page? An HOC can log it automatically.

Code: `withTracking.js`

import { useEffect } from "react";
import analytics from "./analytics"; // Fake analytics tool

// HOC to track page views
export const withTracking = (eventName) => (Component) => (props) => {
  // Track load/unload
  useEffect(() => {
    analytics.trackPageView(eventName); // Log visit
    return () => {
      analytics.trackPageExit(eventName); // Log exit
    };
  }, []); // Run once

  // Show component
  return <Component {...props} />;
};

Usage

import { withTracking } from "./withTracking";

// Track checkout page
const TrackedCheckout = withTracking("checkout_page")(() => (
  <div>
    <h2>Checkout</h2>
    <input placeholder="Card number" />
    <button>Pay</button>
  </div>
));

function App() {
  return <TrackedCheckout />;
}

export default App;

Why It’s Useful

This HOC adds tracking without touching your component’s code. It’s perfect for understanding user behavior!

3. Adding Themes to Components 🎨

Want to add light or dark mode to your app? An HOC can pass theme styles to components.

Code: `withTheme.js`

import { useTheme } from "./useTheme"; // Get theme info

// HOC to add theme
export const withTheme = (Component) => (props) => {
  const theme = useTheme(); // E.g., { color: "black" }

  // Pass theme to component
  return <Component {...props} theme={theme} />;
};

Usage

import { withTheme } from "./withTheme";

// Themed button
const ThemedButton = withTheme(({ theme }) => (
  <button style={{ background: theme.color, color: "white" }}>
    Click Me
  </button>
));

function App() {
  return <ThemedButton />;
}

export default App;

Why It’s Useful

This HOC keeps components styled consistently. Use it for buttons, cards, or anything that needs a theme!

Why Use HOCs? 🤔

HOCs solve real problems and make coding easier. Here’s why I love them:

Separation of Concerns: Keep logic (like fetching) separate from UI (like forms). 🧩
Code Reuse: Write logic once, use it in many components. 🔄
Testability: Test HOC logic alone, not mixed with UI. 🧪
Clean Components: Avoid stuffing components with hooks or side effects. 🧼

HOCs made my code feel organized, like sorting my desk—they’re worth the effort! 🗂️

When to Use HOCs vs. Other Patterns? 🤔

HOCs aren’t always the answer. Here’s a quick guide to pick the right tool:

Reuse logic across many components: Use an HOC or custom hook. 🔄
Need lifecycle logic + rendering: HOC is the way to go. 🔄
Small logic reuse (state, effect): Use a custom hook. 🔄
Full control inside JSX: Avoid HOCs here. 🚫

Modern React often leans toward custom hooks for simple cases, but HOCs shine for wrapping behavior—like logging, auth, analytics, or conditional rendering. I tried hooks for everything at first, but HOCs were better for big logic like auth. Know both to choose wisely! 🧠

Final Tip: Make HOCs Composable 🧩

HOCs are like building blocks—you can stack them to add more features! 🏗️

Example

import { withAuth } from "./withAuth";
import { withTracking } from "./withTracking";

const MyComponent = () => <div>My App</div>;

// Chain HOCs
export default withAuth("admin")(withTracking("home_page")(MyComponent));

Or use a library like Redux for cleaner chaining:

import { compose } from "redux";

export default compose(withAuth("admin"), withTracking("home_page"))(MyComponent);

Why It’s Useful

Composability lets you mix and match HOCs, like adding auth and tracking to one component. 🔄 Chaining HOCs was tricky at first, but it’s super powerful. Start with two and build up! 🚀

Let’s Recap 📝

HOCs are a clever way to reuse logic in React. They wrap components to add features like debugging, data fetching, or security, keeping your code clean and organized. My Notion notes taught me they’re not hard—just smart tools for building better apps. 💡

What’s your favorite React pattern? Let me know in the comments—I’d love to hear your thoughts! 💬

Mastering React Design Patterns: Recursive, Partial, and Composition for Scalable Code 🚀

Tanzim Hossain — Fri, 18 Apr 2025 02:50:19 +0000

Master these three React design patterns to write scalable, reusable, and maintainable code with detailed explanations and practical examples! 🌟

React’s component-based architecture is a game-changer for building dynamic user interfaces, but as applications grow, so does complexity. Design patterns offer reusable solutions to common challenges, helping you write cleaner, more maintainable code. In this post, we’ll explore three essential React design patterns: Recursive Components 🌳, Partial Components 🛠️, and Composition 🧩. We’ll dive deep into each pattern with detailed explanations, practical examples, and visual aids to ensure clarity.

1. Recursive Components: Simplifying Nested Data Structures 🌳

Recursive components are perfect for rendering hierarchical or nested data, such as JSON objects, file directories, or comment threads. By having a component call itself, you can elegantly handle complex, nested structures without repetitive code. 🔄

How It Works

A recursive component processes data by:

Checking if the input data is a primitive (e.g., string, number) or an object.
Rendering primitives directly as leaf nodes.
For objects, iterating over key-value pairs and recursively rendering each value.

This approach mirrors the recursive nature of the data, making the code concise and maintainable. ✅

Example: Rendering a Nested Object 📋

Here’s a component that renders a nested JavaScript object as a nested HTML list:

const isValidObj = (data) => typeof data === "object" && data !== null;

const Recursive = ({ data }) => {
  if (!isValidObj(data)) {
    return <li>{data}</li>;
  }

  const pairs = Object.entries(data);
  return (
    <>
      {pairs.map(([key, value]) => (
        <li key={key}>
          {key}:
          <ul>
            <Recursive data={value} />
          </ul>
        </li>
      ))}
    </>
  );
};

const myNestedObject = {
  key1: "value1",
  key2: {
    innerKey1: "innerValue1",
    innerKey2: {
      innerInnerKey1: "innerInnerValue1",
      innerInnerKey2: "innerInnerValue2",
    },
  },
  key3: "value3",
};

function App() {
  return <Recursive data={myNestedObject} />;
}

Detailed Explanation 📚

Base Case: The isValidObj function checks if data is an object (and not null). If data is a primitive (e.g., "value1"), it’s rendered as a <li> element, stopping the recursion. 🛑
Recursive Case: If data is an object, Object.entries converts it into an array of [key, value] pairs. For each pair, the component renders the key and a nested <ul>, recursively calling <Recursive> on the value. 🔁
Key Prop: The key prop ensures React efficiently updates the DOM by uniquely identifying each <li>. 🔑
Output: The nested object is rendered as a nested <ul> structure, visually representing the hierarchy. 🎨

Visualizing the Recursion 📊

To better understand, here’s a diagram of how the myNestedObject is processed:

myNestedObject
├── key1: "value1" → <li>key1: <ul><li>value1</li></ul></li>
├── key2: { ... } → <li>key2: <ul>
│   ├── innerKey1: "innerValue1" → <li>innerKey1: <ul><li>innerValue1</li></ul></li>
│   └── innerKey2: { ... } → <li>innerKey2: <ul>
│       ├── innerInnerKey1: "innerInnerValue1" → <li>innerInnerKey1: <ul><li>innerInnerValue1</li></ul></li>
│       └── innerInnerKey2: "innerInnerValue2" → <li>innerInnerKey2: <ul><li>innerInnerValue2</li></ul></li>
└── key3: "value3" → <li>key3: <ul><li>value3</li></ul></li>

This tree-like structure shows how each level of the object is recursively processed, resulting in a nested HTML list. 🌲

Use Cases 💡

Rendering nested menus or dropdowns. 📜
Displaying threaded comments in a discussion forum. 💬
Visualizing JSON data for debugging or user interfaces. 🖥️

Benefits 🎉

Simplifies code for complex, nested data.
Eliminates the need for multiple components to handle different levels of nesting.
Scales well with varying data depths.

2. Partial Components: Reusing Components with Predefined Props 🛠️

Partial components allow you to create specialized versions of a component by predefining some of its props. This pattern is ideal for reusing components with consistent configurations, reducing duplication and ensuring uniformity. 🔧

How It Works

A higher-order component (HOC) wraps the base component and injects predefined props. The returned component merges these predefined props with any additional props passed during usage, offering flexibility and reusability. 🔄

Example: Customizable Buttons 🎨

Let’s create a Button component and derive specialized versions using the partial pattern:

const partial = (Component, partialProps) => {
  return (props) => {
    return <Component {...partialProps} {...props} />;
  };
};

const Button = ({ size, color, text, ...props }) => {
  return (
    <button
      style={{
        fontSize: size === "large" ? "25px" : "16px",
        backgroundColor: color,
      }}
      {...props}
    >
      {text}
    </button>
  );
};

const SmallButton = partial(Button, { size: "small" });
const LargeRedButton = partial(Button, { size: "large", color: "crimson" });

// Usage
function App() {
  return (
    <>
      <SmallButton text="Click Me" color="blue" />
      <LargeRedButton text="Submit" />
    </>
  );
}

Detailed Explanation 📖

HOC Definition: The partial function takes a Component and partialProps (the predefined props). It returns a new component that spreads partialProps and any additional props onto the original component. 🔗
Prop Merging: The spread operator (...) ensures that props passed at runtime (e.g., color="blue") can override or supplement the predefined props. 🔄
Specialized Components: SmallButton always has size="small", while LargeRedButton has size="large" and color="crimson". Both can accept additional props like text or onClick. 🛠️
Output: <SmallButton text="Click Me" color="blue" /> renders a small blue button, while <LargeRedButton text="Submit" /> renders a large crimson button. 🎉

Why Use Partial Components? 🤔

Consistency: Ensures components share common configurations (e.g., all SmallButtons have the same size). ✅
Reusability: Reduces the need to repeatedly specify the same props. 🔄
Flexibility: Allows customization through additional props. 🌈

Use Cases 💼

Creating branded buttons (e.g., primary, secondary, danger). 🎨
Standardizing form inputs with default styles or behaviors. 📝
Reusing UI elements across different parts of an application. 🏗️

3. Composition: Building Flexible Components 🧩

Composition is a core React principle that involves combining smaller components to create more complex ones. Unlike inheritance, composition promotes flexibility by allowing components to be layered and customized through props. 🛠️

How It Works

A parent component passes props to a child component, which may itself be composed of other components. This creates a chain of components that build on each other, enabling reusable and modular UI elements. 🔗

Example: Composing Button Variants 🎨

Let’s create a Button component and compose it to create specialized variants:

const Button = ({ size, color, text, ...props }) => {
  return (
    <button
      style={{
        fontSize: size === "large" ? "25px" : "16px",
        backgroundColor: color,
      }}
      {...props}
    >
      {text}
    </button>
  );
};

const SmallButton = (props) => {
  return <Button {...props} size="small" />;
};

const SmallRedButton = (props) => {
  return <SmallButton {...props} color="crimson" />;
};

// Usage
function App() {
  return (
    <>
      <SmallButton text="Cancel" color="blue" />
      <SmallRedButton text="Delete" />
    </>
  );
}

Detailed Explanation 📚

Base Component: The Button component accepts size, color, and text props, rendering a styled <button>. 🖌️
First Layer: SmallButton composes Button by setting size="small". It passes through all other props using the spread operator. 🔄
Second Layer: SmallRedButton composes SmallButton by adding color="crimson". It also passes through any additional props. 🔗
Prop Flow: Props passed to SmallRedButton (e.g., text="Delete") flow through SmallButton to Button, ensuring flexibility. 🌊
Output: <SmallButton text="Cancel" color="blue" /> renders a small blue button, while <SmallRedButton text="Delete" /> renders a small crimson button. 🎉

Why Use Composition? 🤔

Modularity: Breaks down complex components into smaller, reusable pieces. 🧩
Flexibility: Allows layering of functionality without rigid inheritance. 🌈
Maintainability: Makes it easier to update or replace individual components. 🔧

Use Cases 💡

Building a library of UI components with progressive customization. 📚
Creating complex layouts with reusable header, footer, and sidebar components. 🏛️
Structuring forms by composing inputs, labels, and buttons. 📝

Comparing the Patterns 📊

Pattern	Best For	Key Benefit	Example Use Case
Recursive Components 🌳	Nested or hierarchical data	Simplifies complex rendering	Rendering JSON or comment threads
Partial Components 🛠️	Reusing components with defaults	Ensures consistency and reusability	Standardized buttons or inputs
Composition 🧩	Building modular UIs	Promotes flexibility and modularity	Layered UI components or layouts

Conclusion 🎉

Mastering React design patterns like Recursive Components 🌳, Partial Components 🛠️, and Composition 🧩 can transform how you build applications. Recursive components simplify nested data rendering, partial components streamline reusable configurations, and composition enables flexible, modular UIs. By incorporating these patterns, you’ll write code that’s not only cleaner but also scalable and maintainable. 🚀

Experiment with these patterns in your next React project, and see how they improve your workflow. Which pattern are you most excited to try? Share your thoughts or questions in the comments below! 💬

Splitting Prisma Schema into Multiple Files: A Simple Guide

Tanzim Hossain — Mon, 03 Mar 2025 01:07:40 +0000

Hey buddy! Today, I want to share a solution I found for a common problem with Prisma. By default, Prisma uses just one file called schema.prisma to store all your database models. This can get messy when your project grows. I figured out how to split it into multiple files, and I'll show you how to do it step by step.

What's the Problem?

When you start using Prisma, your folder looks like this:

prisma
┗ schema.prisma

Everything—your models, settings, all of it—lives in that one schema.prisma file. For small projects, that's okay. But when you add more models, like users, addresses, or tests, it becomes a big, confusing file. I wanted to split it up like this:

prisma
┗ 📂 schema
 ┣ 📜 user.prisma
 ┣ 📜 address.prisma
 ┣ 📜 schema.prisma
 ┗ 📜 test.prisma

This way, each model gets its own file, and the project stays clean and easy to manage. Here's how I did it.

What You Need Before Starting

Prisma installed: You should already have Prisma set up in your project. If not, check the official Prisma guide to install it.
Basic Prisma knowledge: You should know what schema.prisma does—like how it defines your database models.

Step-by-Step Guide

Step 1: Turn On the Special Feature

Prisma has a feature that lets you use multiple schema files, but it's not on by default. We need to turn it on.

Open your schema.prisma file.
Find the generator client part. It usually looks like this:

generator client {
  provider = "prisma-client-js"
}

Add one line to it like this:

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["prismaSchemaFolder"]
}

The previewFeatures = ["prismaSchemaFolder"] line tells Prisma, "Hey, let me use multiple files!" Here's what my full schema.prisma looks like after this:

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["prismaSchemaFolder"]
}

datasource db {
  provider = "mongodb"
  url = env("DATABASE_URL")
}

Note: This feature is in "preview," so it might change later. Keep an eye on the Prisma docs for updates.

Step 2: Make a New Folder for Your Files

Now, let's organize your models into separate files.

Inside the prisma folder, make a new folder called schema.
Move your schema.prisma file into this new schema folder.
Create new files for each model—like user.prisma, address.prisma, or test.prisma—inside the schema folder.

After this, your folder should look like:

prisma
┗ 📂 schema
 ┣ 📜 user.prisma
 ┣ 📜 address.prisma
 ┣ 📜 schema.prisma
 ┗ 📜 test.prisma

The schema.prisma file still holds the generator and datasource parts, while the other files can hold your models (like user or address).

Step 3: Tell Prisma Where Your Files Are

Prisma needs to know where you put your schema files. We'll update the package.json file for this.

Open your package.json file.
Add this part to it:

"prisma": {
  "schema": "./prisma/schema/"
}

Here's what my package.json looks like after adding it:

{
  "name": "@repo/database",
  "version": "0.0.1",
  "dependencies": {
    "@prisma/client": "5.15.0"
  },
  "devDependencies": {
    "prisma": "5.15.0"
  },
  "prisma": {
    "schema": "./prisma/schema/"
  }
}

This line says, "Prisma, look in ./prisma/schema/ for my files." Double-check the path to make sure it matches your folder setup.

Step 4: Update Your Scripts

The last step is to update the commands you run for Prisma, so they know where your files are. We do this in package.json too.

Find the "scripts" section in package.json.
Add the -schema=./prisma/schema/ flag to each Prisma command. Here's an example for MongoDB:

"scripts": {
  "db:generate": "prisma generate -schema=./prisma/schema/",
  "db:push": "prisma db push -schema=./prisma/schema/",
  "db:pull": "prisma db pull -schema=./prisma/schema/",
  "db:studio": "prisma studio -schema=./prisma/schema/"
}

My full package.json now looks like this:

{
  "name": "@repo/database",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "db:generate": "prisma generate -schema=./prisma/schema/",
    "db:push": "prisma db push -schema=./prisma/schema/",
    "db:pull": "prisma db pull -schema=./prisma/schema/",
    "db:studio": "prisma studio -schema=./prisma/schema/"
  },
  "dependencies": {
    "@prisma/client": "5.15.0"
  },
  "devDependencies": {
    "prisma": "5.15.0"
  },
  "prisma": {
    "schema": "./prisma/schema/"
  }
}

Note: I use MongoDB, so my commands fit that. If you use a different database (like PostgreSQL or MySQL), change the db:* commands to match your setup. Just keep the -schema part the same.

Check If It Works

To make sure everything is okay, run a command like:

npx prisma generate

Or, if you use pnpm:

pnpm run db:generate

If it runs without errors, you're all set! Prisma is now using your split files.

Why This is Awesome

Splitting your Prisma schema into multiple files keeps your project neat. Each model has its own file, so it's easy to find and fix things. I hope this guide was simple and clear for you. Try it out in your project, and let me know how it goes in the comments below!

Happy coding, friends! 🚀

Implementing Multiple Middleware in Next.js: Combining NextAuth V(5) and Internationalization

Tanzim Hossain — Tue, 21 May 2024 14:05:09 +0000

Have you ever wondered how to use multiple middleware functions in Next.js when it only exports one function? In this tutorial, I'll guide you through implementing a modular middleware architecture that combines authentication with NextAuth v5 and internationalization using Next-Intl.

By the end of this article, you'll have a clean, maintainable approach to chaining middleware that you can easily extend for additional functionality.

Let's dive in! 🚀

The Challenge

Next.js middleware is incredibly powerful, but there's a limitation: you can only export one middleware function. This creates a challenge when you need multiple middleware capabilities like:

Authentication checks
Language detection and routing
Logging or analytics
Rate limiting

How do we solve this elegantly? By creating a middleware chain that preserves modularity while meeting Next.js requirements.

Our Approach

We'll create:

A utility to chain multiple middleware functions
Individual middleware modules for authentication and internationalization
A clean way to combine them in the correct order

File Structure

First, let's understand our project organization:

/my-next-app
|-- /src
|   |-- /middlewares
|   |   |-- chain.ts
|   |   |-- withI18nMiddleware.ts
|   |   `-- withAuthMiddleware.ts
|   |-- auth.config.ts
|   |-- auth.ts
|   |-- middleware.ts
|   |-- i18n.config.ts
`-- next.config.js

Step 1: Creating the Chain Utility

The chain utility is the foundation of our solution. It takes an array of middleware functions and returns a single function that executes them in sequence.

// middlewares/chain.ts
import { NextMiddlewareResult } from 'next/dist/server/web/types';
import { NextResponse } from 'next/server';
import type { NextFetchEvent, NextRequest } from 'next/server';

export type CustomMiddleware = (
  request: NextRequest,
  event: NextFetchEvent,
  response: NextResponse
) => NextMiddlewareResult | Promise<NextMiddlewareResult>;

type MiddlewareFactory = (middleware: CustomMiddleware) => CustomMiddleware;

export function chain(
  functions: MiddlewareFactory[],
  index = 0
): CustomMiddleware {
  const current = functions[index];

  if (current) {
    const next = chain(functions, index + 1);
    return current(next);
  }

  return (request: NextRequest, event: NextFetchEvent, response: NextResponse) => {
    return response;
  };
}

This recursive implementation allows each middleware to decide whether to continue the chain or terminate early by returning a response.

Step 2: Internationalization Middleware

Next, let's implement a middleware that handles language detection and routing:

// middlewares/withI18nMiddleware.ts
import { NextResponse } from 'next/server';
import type { NextFetchEvent, NextRequest } from 'next/server';
import { i18n } from '@/i18n.config';
import { match as matchLocale } from '@formatjs/intl-localematcher';
import Negotiator from 'negotiator';
import { CustomMiddleware } from './chain';

function getLocale(request: NextRequest): string | undefined {
  const negotiatorHeaders: Record<string, string> = {};
  request.headers.forEach((value, key) => (negotiatorHeaders[key] = value));

  // @ts-ignore locales are readonly
  const locales: string[] = i18n.locales;
  const languages = new Negotiator({ headers: negotiatorHeaders }).languages();

  const locale = matchLocale(languages, locales, i18n.defaultLocale);
  return locale;
}

export function withI18nMiddleware(middleware: CustomMiddleware) {
  return async (
    request: NextRequest,
    event: NextFetchEvent,
    response: NextResponse
  ) => {
    const pathname = request.nextUrl.pathname;
    const pathnameIsMissingLocale = i18n.locales.every(
      locale => !pathname.startsWith(`/${locale}/`) && pathname !== `/${locale}`
    );

    if (pathnameIsMissingLocale) {
      const locale = getLocale(request)
      const redirectURL = new URL(request.url)
      if (locale) {
        redirectURL.pathname = `/${locale}${pathname.startsWith('/') ? '' : '/'}${pathname}`
      }

      // Preserve query parameters
      redirectURL.search = request.nextUrl.search

      return NextResponse.redirect(redirectURL.toString())
    }

    return middleware(request, event, response);
  };
}

This middleware detects the user's preferred language and ensures URLs include the appropriate locale prefix.

Step 3: Authentication Middleware

Now for our authentication middleware using NextAuth v5:

// middlewares/withAuthMiddleware.ts
import { getToken } from 'next-auth/jwt';
import { NextResponse } from 'next/server';
import type { NextFetchEvent, NextRequest } from 'next/server';
import { CustomMiddleware } from './chain';

export function withAuthMiddleware(middleware: CustomMiddleware): CustomMiddleware {
  return async (request: NextRequest, event: NextFetchEvent, response: NextResponse) => {
    const token = await getToken({ req: request, secret: process.env.NEXTAUTH_SECRET });

    if (!token) {
      return NextResponse.redirect(new URL('/api/auth/signin', request.url));
    }

    return middleware(request, event, response);
  };
}

This middleware checks for a valid authentication token and redirects unauthenticated users to the sign-in page.

Step 4: Combining Everything

Finally, let's put it all together in our main middleware file:

// middleware.ts
import { chain } from '@/middlewares/chain';
import { withI18nMiddleware } from '@/middlewares/withI18nMiddleware';
import { withAuthMiddleware } from '@/middlewares/withAuthMiddleware';

export default chain([withI18nMiddleware, withAuthMiddleware]);

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|favicon.ico|images).*)'],
};

Note the order matters! Here, internationalization runs first, followed by authentication. This ensures we handle locale routing before authentication checks.

The Benefits of This Approach

Our middleware chain architecture provides several advantages:

Modularity: Each middleware focuses on a single responsibility
Extensibility: Add new middleware by creating a module and adding it to the chain
Maintainability: Logic is isolated, making debugging and updates easier
Reusability: Middleware can be reused across projects

Conclusion

With this architecture in place, you can easily combine multiple middleware functions in Next.js while maintaining clean, modular code. This approach scales beautifully as your application grows in complexity.

You could extend this further with middleware for:

Analytics and logging
Rate limiting
Feature flags
A/B testing

What other middleware would you add to your Next.js applications? Let me know in the comments!

DEV Community: Tanzim Hossain

The Precompute Pattern: How to Stop One Cookie from Wrecking Your Entire Next.js App

The problem: one dynamic call poisons the whole tree

The Precompute Pattern: encode it, don't read it

How to build it

Step 1: Define your context shape

Step 2: Encode in the proxy

Step 3: Read context in components

Step 4: Pre-generate variants with generateStaticParams

Vercel's Flags SDK formalizes this exact pattern

The trap: variant count explodes fast

Does 'use cache' in Next.js 16 make this unnecessary?

The missing piece: rootParams

When to use this pattern

The honest summary

Auth.js v5 + Google OAuth: How to Create Users With the Correct Role (The Right Way)

The Real Problem

Why This Happens (OAuth Reality)

The Correct Mental Model

The Solution: Secure Short-Lived Cookie

Step 1: Store Role in a Secure Cookie (Client)

Step 2: Read the Cookie on the Server

Step 3: Create the User With the Correct Role

Step 4: Delete the Cookie After Use (Important)

Security Considerations

Why This Works Reliably

Final Takeaway

Remember This

How to Fix the Copilot Sidebar in Microsoft Edge on Linux

A simple, two-command fix to get the AI assistant working on Ubuntu and other distros.

Step 0: A Quick Prerequisite Check

The Fix: Choose Your Installation Path

Option A: For Flatpak Installations

Option B: For Standard .deb/APT Installations

Final Step: Restart and Enjoy

Understanding the Leaky Bucket Algorithm for System Design

Why the Leaky Bucket Matters

How the Leaky Bucket Works

A Real-World Example

Implementing the Leaky Bucket

Where the Leaky Bucket Shines

Leaky Bucket vs. Token Bucket

Performance Tips

Conclusion

Token Bucket Algorithm Explained

why rate limiting matters

what is the token bucket algorithm?

diagram of token bucket

the math behind it

example run

pros and cons

code example (javascript)

real-world use cases

comparing with other methods

conclusion

Mastering React HOCs: A Clear Guide to Reusable Code 🚀

What’s an HOC in React? 🤔

Why Use HOCs?

Example 1: Debugging Props with an HOC 🐞

Code: checkProps.js

Usage: App.js

Component: UserInfo.js

How It Works

Why It’s Useful

Example 2: Fetching Data with an HOC 📡

Code: includeUpdatableUser.js

Usage: UserInfoForm.js

How It Works

Why It’s Useful

Example 3: A Reusable HOC for Any Resource 🔄

Code: includeUpdatableResource.js

Usage: ProductForm.js

How It Works

Why It’s Useful

Real-World HOC Use Cases 🌍

1. Securing Pages with Authentication 🔒

Code: withAuth.js

Usage

Why It’s Useful

2. Tracking Page Visits 📈

Code: `checkProps.js`

Usage: `App.js`

Component: `UserInfo.js`

Code: `includeUpdatableUser.js`

Usage: `UserInfoForm.js`

Code: `includeUpdatableResource.js`

Usage: `ProductForm.js`

Code: `withAuth.js`

Code: `withTracking.js`

Code: `withTheme.js`