DEV Community: Tanzim Hossain

React architecture: what nobody tells you when your app starts growing

Tanzim Hossain — Tue, 05 May 2026 02:00:11 +0000

I've seen this happen more times than I can count. A React app starts clean — components are small, state is local, everyone understands the code. Six months later, the same codebase is a maze. Components import from three directories up. State lives in seven different places. Adding a feature means touching twelve files. Nobody planned for it to go wrong. It just did.

The problem isn't React. React is deliberately flexible. It doesn't force structure on you, which is both why developers love it and why large teams struggle with it. Without a deliberate architecture, that flexibility turns into entropy.

This article covers the architectural decisions that actually matter in production React apps — folder structure, component design, state management, API abstraction, routing, and performance. By the end, you'll have a complete mental model for building React applications that stay maintainable as they grow.

The real cost of no architecture

Before diving into solutions, let me be direct about what poor architecture costs you.

A component that fetches data, handles form state, controls its own visibility, and renders UI is doing four jobs at once. When it breaks, you spend 20 minutes reading it before you understand what's wrong. When you need to reuse its data-fetching logic, you can't — it's buried inside a component that also handles UI. When you test it, you have to mock a server just to render a button.

That cost compounds. The longer poor structure persists, the more expensive it becomes to fix. Developers stop touching files they don't own. Features get duplicated because nobody knows where to put shared logic. Onboarding new engineers takes three weeks instead of three days.

Good architecture isn't about following rules for their own sake. It's about building a system where changes stay local, where you can reason about one thing at a time, and where the codebase doesn't punish you for growing.

Part 1: Folder structure

The folder-by-type mistake

Most React tutorials start here:

src/
  components/
  hooks/
  utils/
  pages/
  services/

This works for small apps. It fails for large ones. When your components/ folder has 80 files in it, "find the user profile card" means searching through everything. When you delete a feature, you have to hunt across four folders to find all related files.

The root problem: folder-by-type organizes around file type, not around business domain. But code changes are triggered by business changes, not by technical categories.

Feature-based structure

The better approach organizes code around features — the parts of your application that users actually interact with.

src/
  features/
    auth/
      components/
        LoginForm.jsx
        LoginForm.test.jsx
      hooks/
        useAuth.js
      authSlice.js
      authService.js
      index.js
    dashboard/
      components/
      hooks/
      dashboardSlice.js
      dashboardService.js
      index.js
  components/       ← shared UI components (Button, Modal, Input)
  hooks/            ← shared hooks (useDebounce, usePagination)
  services/         ← shared API config (axios instance, interceptors)
  routes/
  store/

Each feature owns its components, hooks, state slice, and service calls. The index.js acts as the feature's public API — anything not exported there is private to the feature.

When you need to work on authentication, you open features/auth/. When a feature is deleted, you delete one folder. When a new engineer asks where the dashboard state lives, the answer is obvious.

Shared code that's needed by more than one feature goes in the top-level components/, hooks/, or services/ directories. The rule is simple: if only one feature needs it, it lives inside that feature. If two features need it, it moves up.

Part 2: Component architecture

Three component types, not one

Every React component you write falls into one of three categories. Treating them the same is where most component complexity comes from.

Presentation components render UI based on props. They hold no state, make no API calls, and contain no business logic. A UserCard that receives a user object and renders a name and avatar is a presentation component. These are the easiest to test, the easiest to reuse, and the easiest to reason about.

// Presentation component — pure UI
const UserCard = ({ name, avatarUrl, role }) => (
  <div className="user-card">
    <img src={avatarUrl} alt={name} />
    <h3>{name}</h3>
    <span>{role}</span>
  </div>
);

Container components handle data. They fetch from APIs, manage state, and pass data down to presentation components. They contain logic, but minimal rendering.

// Container component — data and logic
const UserCardContainer = ({ userId }) => {
  const { data: user, isLoading } = useQuery(['user', userId], () => getUser(userId));

  if (isLoading) return <Spinner />;
  return <UserCard name={user.name} avatarUrl={user.avatar} role={user.role} />;
};

Generic reusable components are your design system — Button, Modal, Input, Dropdown. These live in the shared components/ directory. They accept props for every behavior they support, depend on nothing outside themselves, and never make API calls.

Keeping these three types separate isn't academic. When a UserCard starts fetching its own user data, you've lost the ability to test it without a network, reuse it with different data sources, or compose it inside a larger data-fetching component without triggering double fetches.

Atomic design (when you need it)

For teams building large design systems, Atomic Design adds useful vocabulary:

Atoms → Molecules → Organisms → Templates → Pages

Atoms are single elements: a button, an input, a label. Molecules combine atoms: a search form is an input + button. Organisms are complete UI sections: a navigation bar, a product card. Templates define page layouts. Pages are instances of templates with real data.

This system works well when multiple teams share a component library. For smaller apps, the three-type model above is simpler and sufficient.

Part 3: State management

The most common state mistake

Reaching for Redux on day one. This is incorrect.

Redux solves a real problem — sharing state across many disconnected components — but it solves it with significant overhead. You write action creators, reducers, selectors, and setup code before you can store a single value. For state that only one component needs, this is pure cost with no benefit.

Use the right tool for each type of state:

Local state (useState, useReducer) handles form inputs, UI toggles, modal visibility, accordion open/close. If the data is only relevant to one component, keep it there.

Server state (React Query / TanStack Query) handles data that comes from an API. This is the one most developers get wrong. Server state has unique properties — it lives on the server, it can become stale, it needs caching, it needs background refetch. Redux doesn't handle any of this by default. React Query does all of it.

// React Query handles caching, refetching, and loading states
const { data: users, isLoading, error } = useQuery({
  queryKey: ['users'],
  queryFn: getUsers,
  staleTime: 5 * 60 * 1000, // consider fresh for 5 minutes
});

Global client state (Redux Toolkit, Zustand, Context) handles state that multiple components across the tree need simultaneously — authenticated user, theme, shopping cart, notifications. This is the correct use case for global state.

The decision rule:

One component needs it → useState
Comes from an API → React Query
Multiple disconnected components need it → Zustand or Redux Toolkit

Zustand vs Redux Toolkit

Redux Toolkit reduced Redux boilerplate significantly, but Zustand takes it further. For most apps that need global client state, Zustand is faster to set up and easier to read.

// Zustand store — minimal setup
import { create } from 'zustand';

const useAuthStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
  logout: () => set({ user: null }),
}));

Redux Toolkit makes more sense when: your team already knows Redux, you need DevTools time-travel debugging, or you're managing complex state with many interdependent slices. For greenfield projects with a small team, Zustand wins on simplicity.

Part 4: API and data layer

The service layer pattern

Components should never contain raw fetch or axios calls. Here's why: when your API URL changes, when you add auth headers, when you need to handle errors consistently, you want to make that change in one place — not across 40 components.

The service layer is that one place.

// utils/axios.js — configure once
import axios from 'axios';

const api = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
  timeout: 10000,
});

// Add auth token to every request
api.interceptors.request.use((config) => {
  const token = localStorage.getItem('token');
  if (token) config.headers.Authorization = `Bearer ${token}`;
  return config;
});

// Handle errors in one place
api.interceptors.response.use(
  (response) => response.data,
  (error) => {
    if (error.response?.status === 401) {
      // redirect to login
    }
    return Promise.reject(error);
  }
);

export default api;

// features/users/userService.js — thin API functions
import api from '../../utils/axios';

export const getUsers = () => api.get('/users');
export const getUserById = (id) => api.get(`/users/${id}`);
export const updateUser = (id, data) => api.put(`/users/${id}`, data);

// features/users/hooks/useUsers.js — React Query wraps service calls
import { useQuery } from '@tanstack/react-query';
import { getUsers } from '../userService';

export const useUsers = () => {
  return useQuery({
    queryKey: ['users'],
    queryFn: getUsers,
  });
};

The data flow is UI → Hook → Service → API. Each layer has one job. UI renders. Hooks coordinate. Services call the API. When something breaks, you know exactly where to look.

Part 5: Routing architecture

React Router v6 with nested layouts

Flat route lists don't scale. When you have 30 routes, a flat list becomes unreadable. Nested routes let you group related pages under shared layouts.

routes/
  AppRoutes.jsx       ← top-level route config
  ProtectedRoute.jsx  ← auth guard component
  PublicRoute.jsx     ← redirect logged-in users away

// routes/AppRoutes.jsx
const AppRoutes = () => (
  <Routes>
    {/* Public routes */}
    <Route element={<PublicRoute />}>
      <Route path="/login" element={<Login />} />
      <Route path="/register" element={<Register />} />
    </Route>

    {/* Protected routes with shared layout */}
    <Route element={<ProtectedRoute />}>
      <Route element={<DashboardLayout />}>
        <Route path="/" element={<Home />} />
        <Route path="/users" element={<Users />} />
        <Route path="/users/:id" element={<UserDetail />} />
        <Route path="/settings" element={<Settings />} />
      </Route>
    </Route>

    <Route path="*" element={<NotFound />} />
  </Routes>
);

// routes/ProtectedRoute.jsx
const ProtectedRoute = () => {
  const { user } = useAuthStore();
  return user ? <Outlet /> : <Navigate to="/login" replace />;
};

The ProtectedRoute and PublicRoute components handle authentication at the routing level. Components don't need to check auth state themselves. The DashboardLayout renders the sidebar and nav once — every nested route gets them automatically without re-rendering the shell.

Part 6: Hooks architecture

Custom hooks are the most underused tool in React. They're how you move logic out of components without needing a state management library.

The rule: if a component has more than two useState calls, or more than one useEffect, those should probably be a custom hook.

// hooks/useDebounce.js — reusable across features
import { useState, useEffect } from 'react';

export const useDebounce = (value, delay = 300) => {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
};

// features/users/hooks/useUserSearch.js — feature-specific hook
export const useUserSearch = () => {
  const [query, setQuery] = useState('');
  const debouncedQuery = useDebounce(query, 400);

  const { data: results, isLoading } = useQuery({
    queryKey: ['users', 'search', debouncedQuery],
    queryFn: () => searchUsers(debouncedQuery),
    enabled: debouncedQuery.length > 0,
  });

  return { query, setQuery, results, isLoading };
};

The component that uses useUserSearch has no idea how debouncing works, when queries fire, or how results cache. It calls the hook and gets data. That's the right level of abstraction.

Avoid "god hooks" — hooks that do ten things because you didn't want to write two. A hook that handles search, pagination, sorting, and filtering is as hard to maintain as a component that does the same.

Part 7: Performance

When to optimize and when not to

Most React performance problems come from optimizing too early or in the wrong place.

React.memo prevents a component from re-rendering if its props haven't changed. Use it on components that render frequently, are expensive to render, and receive stable props. Don't wrap every component in memo — you add overhead and gain nothing most of the time.

// Only wrap when you've measured a real performance problem
const UserCard = React.memo(({ name, avatarUrl }) => (
  <div>...</div>
));

useMemo and useCallback cache computed values and function references. The rule: use them when a child component is wrapped in memo and depends on the reference, or when a computation is genuinely expensive (measured, not assumed).

const filteredUsers = useMemo(
  () => users.filter(user => user.active),
  [users]
);

Code splitting with React.lazy

Bundle everything together and your initial load suffers. React.lazy with Suspense splits your code at the route level — users download only what they need.

const Dashboard = lazy(() => import('./features/dashboard/pages/Dashboard'));
const Settings = lazy(() => import('./features/settings/pages/Settings'));

const AppRoutes = () => (
  <Suspense fallback={<PageLoader />}>
    <Routes>
      <Route path="/" element={<Dashboard />} />
      <Route path="/settings" element={<Settings />} />
    </Routes>
  </Suspense>
);

List virtualization

Rendering 1,000 list items creates 1,000 DOM nodes. Virtualization renders only what's visible.

import { FixedSizeList as List } from 'react-window';

const UserList = ({ users }) => (
  <List
    height={600}
    itemCount={users.length}
    itemSize={72}
    width="100%"
  >
    {({ index, style }) => (
      <div style={style}>
        <UserCard user={users[index]} />
      </div>
    )}
  </List>
);

Use react-window for any list over 100 items. The performance difference is dramatic — users see smooth scrolling instead of frame drops.

Part 8: Error handling

Error boundaries

JavaScript errors inside components crash the whole tree by default. Error boundaries catch errors and show fallback UI instead.

class ErrorBoundary extends React.Component {
  state = { hasError: false, error: null };

  static getDerivedStateFromError(error) {
    return { hasError: true, error };
  }

  componentDidCatch(error, info) {
    // Log to Sentry, LogRocket, etc.
    console.error(error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback || <p>Something went wrong.</p>;
    }
    return this.props.children;
  }
}

// Usage
<ErrorBoundary fallback={<ErrorPage />}>
  <Dashboard />
</ErrorBoundary>

Wrap top-level routes and feature sections in error boundaries. If the dashboard crashes, the nav still works.

Centralized API error handling

Handle network errors in the axios interceptor — 401 redirects, 500 error toasts, network timeouts. Don't scatter error handling logic across service functions.

React Query gives you error state out of the box for API errors that don't need central handling:

const { data, isLoading, error } = useQuery({ queryKey: ['users'], queryFn: getUsers });

if (error) return <ErrorMessage message={error.message} />;

Part 9: Testing architecture

What to test and where

Unit tests cover isolated logic — service functions, utility functions, custom hooks. Integration tests cover component behavior — does the form submit with correct data? Does the error state appear when the API fails? End-to-end tests cover user flows — can a user log in, navigate to the dashboard, and see their data?

src/
  features/
    auth/
      components/
        LoginForm.jsx
        LoginForm.test.jsx    ← integration test lives next to component
      hooks/
        useAuth.test.js       ← hook test
      authService.test.js     ← service test
  __tests__/
    e2e/                      ← Playwright or Cypress tests

// LoginForm.test.jsx — test behavior, not implementation
import { render, screen, userEvent } from '@testing-library/react';
import { QueryClientProvider } from '@tanstack/react-query';
import LoginForm from './LoginForm';

test('shows error when login fails', async () => {
  server.use(
    rest.post('/api/login', (req, res, ctx) => res(ctx.status(401)))
  );

  render(
    <QueryClientProvider client={queryClient}>
      <LoginForm />
    </QueryClientProvider>
  );

  await userEvent.type(screen.getByLabelText('Email'), 'test@example.com');
  await userEvent.type(screen.getByLabelText('Password'), 'wrongpassword');
  await userEvent.click(screen.getByRole('button', { name: /sign in/i }));

  expect(await screen.findByText(/invalid credentials/i)).toBeInTheDocument();
});

Test what users experience, not internal implementation. If you're asserting on component state directly, you're testing the wrong thing.

Part 10: The complete architecture picture

Here's how all the layers connect:

UI Layer (Pages, Components)
        ↓
Hooks Layer (useAuth, useUsers, useSearch)
        ↓
Service Layer (userService, authService)
        ↓
API Layer (configured axios instance)
        ↓
Backend / External APIs
        ↓
Cache Layer (React Query cache)
        ↑
State Layer (Zustand for global client state)

Data flows down from the service layer through hooks into components. User actions flow up from components through hooks to service calls. Global state sits beside this flow — components read from Zustand stores directly when they need cross-cutting data like the current user.

The folder structure maps directly to this:

src/
  features/           ← business domain code (feature-scoped)
    auth/
    dashboard/
    users/
  components/         ← shared UI (presentational only)
  hooks/              ← shared logic
  services/           ← shared API config
  routes/             ← routing
  store/              ← global state config

What to do next

Don't try to refactor an existing codebase to this architecture all at once. That approach fails every time. Instead:

Pick the most painful feature in your app — the one developers avoid touching. Migrate that feature to the feature-based structure. Add a service layer for its API calls. Move its state to React Query where it makes sense. Write tests for the pieces you move.

Once it works and the team sees the difference, migration becomes pull-request-by-pull-request over months instead of a risky rewrite.

The architecture described here isn't theory. It's the pattern that survives contact with real teams, real deadlines, and real codebases that need to grow. The sooner you introduce structure, the lower the cost. The longer you wait, the more expensive the fix.

Start with the next feature you build.

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!