DEV Community: Anas Sheikh

Your Next.js Page Might Be Caching One User's Data and Serving It to Everyone Else

Anas Sheikh — Thu, 20 Aug 2026 09:51:31 +0000

This is the scariest bug class I've run into in Next.js, not because it's exotic, but because it's genuinely easy to introduce without realizing it, and when it happens, the symptom is one user seeing another user's actual data. Not a crash. Not an error. A real privacy leak that looks, from the outside, like the app is just working fine.

How This Actually Happens

Next.js aggressively tries to render pages statically when it can, generating the HTML once and serving that same cached HTML to every visitor, which is fantastic for performance on genuinely static content. The App Router decides whether a page can be static based on whether it detects anything that makes the page dynamic, reading cookies, reading headers, using searchParams in certain ways.

The danger is when a page reads user-specific data through a path Next.js doesn't recognize as a dynamic signal.

// app/dashboard/page.tsx
export default async function DashboardPage() {
  const user = await getCurrentUserFromSomewhere(); // how is this actually getting the user?
  return <h1>Welcome back, {user.name}</h1>;
}

If getCurrentUserFromSomewhere reads the session correctly through cookies(), Next.js detects that and correctly marks the route as dynamic, rendered fresh per request, never cached. But if that function, or anything it calls, reads user identity from something Next.js doesn't recognize as a dynamic signal, a global variable set elsewhere, a value cached from a previous request, a misconfigured fetch call with cache: 'force-cache' on what should have been user-specific data, the page can get statically generated once, with one specific user's data baked directly into the HTML, and then served identically to every subsequent visitor.

A More Concrete, Realistic Version

// lib/queries/user.ts
export async function getDashboardData(userId: string) {
  // Explicitly opted into caching, on data that's actually user-specific
  const res = await fetch(`https://api.example.com/dashboard/${userId}`, {
    cache: 'force-cache',
  });
  return res.json();
}

// app/dashboard/page.tsx
import { cookies } from 'next/headers';

export default async function DashboardPage() {
  const cookieStore = await cookies();
  const userId = cookieStore.get('userId')?.value;
  const data = await getDashboardData(userId as string);
  return <Dashboard data={data} />;
}

Reading cookies() here does correctly mark the page as dynamic. But the fetch call inside getDashboardData explicitly overrides caching behavior with cache: 'force-cache', and that specific fetch result can get cached and reused across different users' requests to that same route, if the URL happens to be identical or if the caching layer isn't scoped as tightly as the developer assumed. The exact mechanics depend on deployment setup, but the root mistake is the same: explicitly forcing caching on a fetch that returns user-specific data.

Why This Is So Easy to Miss

Locally, testing as yourself, everything looks completely correct. You see your own data every time, because you're the only user testing, and the timing of cache population versus your own requests rarely exposes the overlap. This bug typically surfaces in production, under real concurrent traffic, when User A loads the dashboard first, gets served fresh data, and User B loads it moments later and gets served User A's cached response instead of their own. Nobody sees an error. The page just quietly shows the wrong person's information.

The Actual Rule

Anything genuinely user-specific should never have cache: 'force-cache' applied to it, explicitly or by inheriting a default from a shared fetch wrapper. If a fetch call's result depends on who's asking, the caching behavior needs to reflect that.

// ❌ Force-caching something that varies per user
const res = await fetch(url, { cache: 'force-cache' });

// ✅ Explicitly no caching for user-specific data
const res = await fetch(url, { cache: 'no-store' });

// ✅ Or, if using a direct database query instead of fetch, use React's cache()
// for per-request deduplication only, never a persistent cache like unstable_cache
import { cache } from 'react';
export const getUserData = cache(async (userId: string) => { ... });

no-store explicitly tells Next.js this fetch should never be cached, full stop, fetched fresh every single time regardless of anything else happening around it. For direct database queries, this is exactly why request-scoped cache() (resetting on every new request) is the safe default for anything user-specific, and unstable_cache (persisting across requests) should be reserved specifically for data that's genuinely the same for everyone, never anything scoped to an individual user.

The Checklist

Anything reading user identity should read it from cookies(), headers(), or an authenticated session, explicitly, not from something implicit or shared. This is what lets Next.js correctly detect the route as dynamic in the first place.

Any fetch call returning user-specific data should be cache: 'no-store' or use next: { revalidate: 0 }, never force-cache, and never inherit a default caching config from a shared wrapper without checking.

Any direct database query returning user-specific data should use cache() for per-request deduplication at most, never unstable_cache, which is explicitly meant to persist across different requests and different users.

Test with two different accounts, not just your own, specifically checking whether switching accounts ever shows stale data from the previous one. This is the actual way to catch this in practice, since testing solo as one user almost never surfaces it.

If you're running a Next.js app with any personalized dashboard, genuinely go test it logged in as two different accounts, in quick succession, and watch closely for any data that seems to lag behind or briefly show the wrong account's info. If you've hit this in production before, I'd genuinely like to hear how it actually surfaced, drop it in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

I've Reviewed a Dozen Next.js Stripe Integrations. Almost None Handle This Race Condition.

Anas Sheikh — Wed, 19 Aug 2026 09:22:05 +0000

Quick fact that surprises a lot of developers the first time they hear it: Stripe does not guarantee it will deliver a webhook event exactly once, and it does not guarantee events arrive in the order they happened. Both of those are explicitly documented, stated plainly in Stripe's own docs, and almost every webhook handler I've reviewed on a client project or open source repo is written as if neither is true.

What This Actually Breaks

Here's a completely standard-looking webhook handler, the kind that shows up in probably half the Next.js Stripe tutorials online:

// app/api/webhooks/stripe/route.ts
export async function POST(request: Request) {
  const event = stripe.webhooks.constructEvent(body, signature, webhookSecret);

  switch (event.type) {
    case 'checkout.session.completed': {
      const session = event.data.object as Stripe.Checkout.Session;
      await User.findByIdAndUpdate(session.metadata?.userId, {
        subscriptionStatus: 'active',
      });

      await resend.emails.send({
        to: session.customer_email,
        subject: 'Welcome! Your subscription is active',
        // ...
      });
      break;
    }
  }

  return new Response('OK', { status: 200 });
}

This works perfectly, right up until Stripe retries the delivery, which it does automatically if your endpoint responds slowly, times out, or your server has a brief blip during deployment. When that retry arrives, this handler runs the exact same logic again. The user's subscription status gets set to active a second time, harmless on its own, but the welcome email goes out twice. On a busier handler doing something less harmless, granting credits, incrementing a usage counter, creating a database record, a duplicate delivery means duplicate side effects, silently, in production, with no error thrown anywhere to tell you it happened.

Why This Doesn't Show Up in Testing

Locally, using the Stripe CLI to forward events, you get exactly one delivery per event almost every time, a clean, predictable environment. Retries happen specifically when something is slightly off, a slow response, a deploy happening at the wrong moment, a brief network hiccup, exactly the conditions your local dev environment almost never produces. This bug lives specifically in the gap between "works every time I test it" and "works reliably under real production conditions," which is exactly why it slips through so often.

The Fix: Track Processed Event IDs

Every Stripe event has a unique id. Idempotency means checking whether you've already processed that specific ID before doing anything else.

// app/api/webhooks/stripe/route.ts
import ProcessedEvent from '@/models/ProcessedEvent';

export async function POST(request: Request) {
  const event = stripe.webhooks.constructEvent(body, signature, webhookSecret);

  await connectDB();

  const alreadyProcessed = await ProcessedEvent.findOne({ eventId: event.id });
  if (alreadyProcessed) {
    return new Response('OK', { status: 200 }); // acknowledge, but do nothing
  }

  switch (event.type) {
    case 'checkout.session.completed': {
      const session = event.data.object as Stripe.Checkout.Session;
      await User.findByIdAndUpdate(session.metadata?.userId, {
        subscriptionStatus: 'active',
      });
      await resend.emails.send({ /* ... */ });
      break;
    }
  }

  await ProcessedEvent.create({ eventId: event.id, processedAt: new Date() });

  return new Response('OK', { status: 200 });
}

A small collection, just event IDs and timestamps, is enough. This single check means a retried delivery still returns a successful response to Stripe, so Stripe stops retrying, but does absolutely nothing the second time, no duplicate email, no duplicate side effect.

The Second Part Nobody Handles: Out-of-Order Delivery

This one's subtler and catches even developers who already handled duplicate delivery. Stripe does not guarantee checkout.session.completed arrives before a later customer.subscription.updated for the same customer. If your handler for the later event assumes certain fields already exist because "the completed event must have run first," that assumption can be wrong.

// ❌ Assumes the user record already has stripeCustomerId set
case 'customer.subscription.updated': {
  const subscription = event.data.object as Stripe.Subscription;
  await User.findOneAndUpdate(
    { stripeCustomerId: subscription.customer as string }, // might not be set yet
    { subscriptionStatus: subscription.status }
  );
  break;
}

If this event somehow arrives before the customer ID was ever set on the user record, this update silently matches nothing, and the update just disappears with no error. The fix is designing each handler to be safe regardless of arrival order, either by looking up the user a different way (Stripe's customer ID stored at signup, not only set during checkout completion), or by handling a "no match found" case explicitly instead of assuming it can't happen.

The Actual Checklist

Store and check event IDs before processing anything. This alone fixes the majority of real-world duplicate delivery issues.

Never assume event order. Design each event handler to work correctly on its own, not dependent on a specific event having already run first.

Always return a 200 quickly, even for events you don't care about. A slow or failing response is exactly what triggers Stripe's retry logic in the first place, so an unhandled event type returning an error status can actually be the thing causing your own duplicate-delivery problem.

Log every event processed, with its ID, somewhere you can actually query later. When something does go wrong with a payment, having a real record of which events arrived and when is the difference between a five-minute investigation and a genuinely confusing debugging session.

If you've got a Stripe webhook handler in production right now, go check whether it's actually idempotent, not whether it works when you test it once locally. Drop what you find in the comments, curious whether this is as common in the wild as what I've personally run into reviewing client codebases.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Next.js Automatically Dedupes fetch() Calls. Your MongoDB Queries Don't Get That for Free.

Anas Sheikh — Tue, 18 Aug 2026 09:29:09 +0000

Here's something that trips up almost everyone moving from a fetch-based API to a direct MongoDB connection in Next.js, and it's costing real database load on projects that don't even realize it's happening.

Next.js automatically deduplicates fetch() calls with identical parameters within a single render pass. If your layout, your page, and three nested components all call fetch('/api/user'), Next.js is smart enough to only actually make that request once and reuse the result everywhere else it's called. This is called request memoization, and it's one of the quieter, genuinely useful things the App Router does for you automatically.

Direct database queries get none of this. Nothing.

What This Actually Looks Like

// lib/queries/user.ts
import { connectDB } from '@/lib/db';
import User from '@/models/User';

export async function getCurrentUser(userId: string) {
  await connectDB();
  return User.findById(userId).lean();
}

// app/dashboard/layout.tsx
export default async function DashboardLayout({ children }) {
  const user = await getCurrentUser(userId); // query #1
  return <div><Sidebar user={user} />{children}</div>;
}

// app/dashboard/page.tsx
export default async function DashboardPage() {
  const user = await getCurrentUser(userId); // query #2, same user, same request
  return <Header user={user} />;
}

// components/UserMenu.tsx (Server Component, rendered inside the page)
export default async function UserMenu() {
  const user = await getCurrentUser(userId); // query #3
  return <Menu user={user} />;
}

Three separate calls to getCurrentUser, same user ID, same single incoming request from the browser. If this were fetch('/api/user') instead of a direct Mongoose query, Next.js would automatically collapse these into one actual network call. Since it's a direct database query, none of that automatic deduplication applies. This is three real round trips to MongoDB, for data that was identical all three times, on every single page load.

Why This Doesn't Show Up in Development

On a local database with almost no latency and no real load, three redundant queries feel instant, indistinguishable from one. This is exactly why it's so easy to ship without noticing. The cost only becomes visible under real production conditions, real network latency to your database, real concurrent traffic, where those extra round trips add up into measurably slower page loads and meaningfully higher database load than the page actually needed.

The Actual Fix: React's cache() Function

React ships a cache() function specifically for this. It memoizes a function's result within a single render pass, exactly the same behavior fetch gets automatically, just applied manually to whatever function you wrap with it.

// lib/queries/user.ts
import { cache } from 'react';
import { connectDB } from '@/lib/db';
import User from '@/models/User';

export const getCurrentUser = cache(async (userId: string) => {
  await connectDB();
  return User.findById(userId).lean();
});

That's the entire fix. Every call to getCurrentUser with the same userId, anywhere in that same render pass, layout, page, nested component, now returns the same cached promise instead of triggering a new query. Three calls become one actual database hit.

The Part People Get Wrong About cache()

This is request-scoped, not persistent across requests. It deduplicates calls within one single render of one single incoming request, then resets completely for the next request. It is not the same thing as unstable_cache, which persists data across multiple requests and needs explicit revalidation.

// cache() - deduplicates within ONE request, resets every time
export const getCurrentUser = cache(async (userId: string) => { ... });

// unstable_cache - persists ACROSS requests, needs revalidateTag to update
export const getPosts = unstable_cache(async () => { ... }, ['posts'], {
  revalidate: 3600,
});

Mixing these up causes two different problems. Using cache() where you needed unstable_cache means you're still hitting the database on every single request, just once instead of three times. Using unstable_cache where you needed cache() means you're persisting data across requests when you actually just wanted to avoid redundant calls within one page load, which can serve stale data longer than intended.

Where I'd Actually Add This

Not everywhere, that would be over-engineering a solution for calls that only ever happen once per request anyway. The pattern worth watching for specifically: any query function, getCurrentUser, getTenant, getSession-adjacent lookups, that reasonably gets called from multiple places in the same component tree, a layout, a page, and a few nested components all independently needing "who is the current user."

Check Your Own Project

Grep your query functions for ones called from more than one component in the same tree, and check whether they're wrapped in cache(). If they're not, and they're not already going through unstable_cache or an equivalent persistent layer, you likely have the exact redundant-query pattern above running silently in production right now.

Curious how many people actually knew about this before reading this post versus assumed Next.js handled it automatically the same way it does for fetch. Drop your honest answer in the comments, genuinely curious how well-known this actually is.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Your Next.js Server Actions Are Public API Endpoints. Most Developers Don't Realize This.

Anas Sheikh — Mon, 17 Aug 2026 14:08:09 +0000

Quick question. If you have a Server Action that deletes a user's account, called from a single delete button buried three clicks deep in account settings, how many people can actually trigger it?

If your answer is "only someone who clicks that specific button," I'd genuinely like you to go check, because the real answer is anyone who can send a POST request with the right shape, whether or not they ever saw your button at all.

Why This Surprises People

Server Actions feel like regular functions. You write 'use server', call it from onClick or a form action, and it just works, no fetch, no API route, no visible endpoint in your code. That ergonomics is genuinely great. It also creates a false sense that the function is somehow private to the component that calls it.

It isn't. Under the hood, Next.js compiles every Server Action into a real HTTP endpoint. Your component calling it is one way to reach that endpoint. It is not the only way. Anyone who inspects your client bundle, or just watches the network tab while using your app, can find the action's reference and call it directly, completely bypassing whatever UI, whatever button, whatever "you'd have to click three things to get here" flow you built around it.

What This Actually Looks Like

// actions/account.ts
'use server';
import { connectDB } from '@/lib/db';
import User from '@/models/User';

export async function deleteAccount(userId: string) {
  await connectDB();
  await User.findByIdAndDelete(userId);
  return { success: true };
}

This looks completely reasonable if you're only thinking about the one delete button that calls it. The problem is userId is just a parameter. Nothing here checks whether the person calling this action is actually authenticated, let alone whether they're allowed to delete this specific account. Someone could call this with any user ID they want, and as far as this function is concerned, that's a perfectly valid request.

The Fix Is Not Complicated, It's Just Easy to Skip

// actions/account.ts
'use server';
import { connectDB } from '@/lib/db';
import User from '@/models/User';
import { getSession } from '@/lib/auth';

export async function deleteAccount() {
  const session = await getSession();
  if (!session) {
    throw new Error('Not authenticated');
  }

  await connectDB();
  // Delete the SESSION's user, never a userId passed in as a parameter
  await User.findByIdAndDelete(session.userId);

  return { success: true };
}

Notice what changed. userId is gone as a parameter entirely. The action figures out who's making the request from the authenticated session, server-side, not from anything the caller supplies. Even if someone calls this endpoint directly, bypassing your UI completely, the worst they can do is delete their own account, because there is no longer any parameter that lets them specify someone else's.

This is the actual rule: any value a Server Action needs to know "who is this for" should come from the session, never from an argument. If you find yourself passing a userId into an action instead of deriving it from getSession(), that's worth a second look.

This Isn't Just About Deletion

The same gap shows up everywhere once you start looking for it:

// ❌ Trusts a role passed in from the client
export async function promoteToAdmin(userId: string, newRole: string) {
  await User.findByIdAndUpdate(userId, { role: newRole });
}

// ❌ Trusts a price passed in from the client
export async function createOrder(items: CartItem[], totalPrice: number) {
  await Order.create({ items, total: totalPrice }); // never trust a client-supplied price
}

// ❌ Trusts a tenant ID passed in from the client (the multi-tenancy nightmare)
export async function getInvoices(tenantId: string) {
  return Invoice.find({ tenantId });
}

Every one of these takes something security-relevant as a parameter instead of deriving it server-side. Every one of them is callable directly, with whatever value an attacker chooses, by anyone who finds the endpoint, regardless of what your UI would normally send.

The Actual Checklist

Before shipping any Server Action, I ask three questions now:

Does this need to know who's calling it? If yes, that comes from getSession(), never a parameter.

Does this touch or return data scoped to a specific user, tenant, or role? If yes, that scope gets enforced server-side against the session, not trusted from anything passed in.

Would this still be safe if called directly, with any argument value, by someone who never saw my UI at all? If the honest answer is no, the action is missing a check, not a UI restriction, an actual server-side check.

Why This Matters More With AI-Assisted Coding

This gap has gotten easier to introduce, not harder, as AI coding tools have gotten better at quickly generating working Server Actions. A tool asked to "add a delete button that removes a user" will happily generate exactly the vulnerable version above, because it works, it satisfies the request, and nothing about "does this check who's calling it" is implied by that prompt. The code runs, the button works, the demo looks perfect. The gap only shows up when someone deliberately calls the endpoint directly, which almost never happens during normal testing.

Go check your own Server Actions right now, specifically anything that deletes, updates a role, or touches data that should be scoped to one user. If you find one trusting a client-supplied ID instead of the session, you're not alone, drop what you found in the comments. I'm genuinely curious how common this actually is across real projects.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Stop Wrapping Everything in 'use client'. It's Quietly Killing Your Next.js Performance.

Anas Sheikh — Sun, 16 Aug 2026 08:35:59 +0000

Open ten random Next.js App Router projects on GitHub right now. I'd bet real money that at least seven of them have a 'use client' directive sitting at the top of a page component that never needed to be there in the first place, quietly shipping way more JavaScript to the browser than the page actually requires.

This is not a hypothetical problem. I've audited client projects where removing three unnecessary 'use client' directives cut the initial JS bundle by more than a third. Nobody put them there maliciously. Everybody put them there out of habit, muscle memory from the Pages Router days, or because one small interactive piece "made it easier" to just mark the whole file client-side instead of extracting it.

Why This Happens

The App Router defaults to Server Components. No JavaScript for that component ships to the browser at all, it renders on the server and sends HTML. The moment you add 'use client', that component and everything it imports becomes part of the client bundle.

The trap is that 'use client' doesn't just affect the file it's written in. It affects every component that file renders, unless those child components are passed in as children from a Server Component parent. So a page-level 'use client' for one button with an onClick handler can silently drag the entire page's markup, every heading, every paragraph, every static section, into the client bundle with it.

What This Actually Looks Like in Real Code

// ❌ The whole page becomes client-side JavaScript
'use client';

export default function ProductPage({ product }) {
  const [inCart, setInCart] = useState(false);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <img src={product.image} alt={product.name} />
      <ReviewsSection reviews={product.reviews} />
      <RelatedProducts productId={product.id} />
      <button onClick={() => setInCart(true)}>Add to cart</button>
    </div>
  );
}

Every one of those components, the reviews section, the related products list, none of which need any client-side interactivity at all, now ships as JavaScript because of one button at the bottom of the file.

// ✅ Only the actual interactive piece ships as client JS
export default function ProductPage({ product }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <img src={product.image} alt={product.name} />
      <ReviewsSection reviews={product.reviews} />
      <RelatedProducts productId={product.id} />
      <AddToCartButton productId={product.id} />
    </div>
  );
}

// components/AddToCartButton.tsx
'use client';
export function AddToCartButton({ productId }) {
  const [inCart, setInCart] = useState(false);
  return <button onClick={() => setInCart(true)}>Add to cart</button>;
}

Same functionality. The page component itself never runs in the browser at all. ReviewsSection and RelatedProducts stay Server Components, rendered entirely on the server, shipping zero JavaScript for content that was never interactive to begin with.

The Check That Actually Catches This

Don't trust your gut on this. Run the bundle analyzer and look:

npm install @next/bundle-analyzer
ANALYZE=true npm run build

If a page you'd expect to be mostly static, a blog post, a product page, a marketing page, shows up with a suspiciously large client bundle, that is almost always a 'use client' boundary sitting higher in the tree than it needs to be. I've caught this exact issue on client projects more times than I can count, always the same root cause, an interactive piece pulling its entire static parent along with it.

The Rule I Actually Follow Now

Push 'use client' as far down the component tree as it can possibly go. Not "this page has one interactive thing, so I'll mark the page client." Extract that one interactive thing into its own small component, mark only that component client, and let everything else stay server-rendered.

A useful mental test before adding the directive: does this specific piece of code need useState, useEffect, an event handler, or a browser API. If the answer is no, it does not need 'use client', even if something nearby does.

Where People Push Back on This

I know the counterargument. "It's simpler to just mark the whole page client and not think about the boundary." That's true, and for a small personal project, it might genuinely not matter. For anything with real traffic, real users on real connections, that simplicity is costing your actual users load time and interactivity delay, every single visit, forever, in exchange for a few minutes saved once during development.

The other pushback I hear: "Doesn't this add complexity, splitting things into more files?" A little, yes. It's also exactly the kind of complexity that pays for itself immediately in bundle size, and it becomes second nature within a few projects, not a genuine ongoing tax on how you write code.

Go check your own bundle right now. I'd bet you find at least one page where a 'use client' boundary is sitting higher in the tree than it actually needs to be. Drop what you find in the comments, curious how common this actually is across real projects versus how common I think it is.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Cron Jobs and Scheduled Tasks in Next.js 15 The Setup I Actually Use

Anas Sheikh — Sat, 15 Aug 2026 09:20:36 +0000

Next.js has no built-in concept of a background job that runs on a schedule, since it is fundamentally a request-response framework. Every scheduled task, checking for expired subscriptions, cleaning up stale records, sending a daily digest email, needs something outside the normal request cycle to trigger it. Here is how I set that up.

1. Vercel Cron for Scheduled Triggers

If the project is already deployed on Vercel, Vercel Cron is the simplest option, no separate service to manage, configured directly in the project.

// vercel.json
{
  "crons": [
    {
      "path": "/api/cron/check-subscriptions",
      "schedule": "0 0 * * *"
    },
    {
      "path": "/api/cron/cleanup-old-sessions",
      "schedule": "0 */6 * * *"
    }
  ]
}

"0 0 * * *" is standard cron syntax, midnight every day. "0 */6 * * *" runs every six hours. Vercel calls each path with a GET request on the defined schedule, which means the actual logic just needs to live behind a normal route handler.

2. The Route Handler

// app/api/cron/check-subscriptions/route.ts
import { connectDB } from '@/lib/db';
import User from '@/models/User';
import { resend } from '@/lib/email';
import { PastDueEmail } from '@/emails/PastDue';

export async function GET(request: Request) {
  await connectDB();

  const expiredUsers = await User.find({
    subscriptionStatus: 'active',
    currentPeriodEnd: { $lt: new Date() },
  });

  for (const user of expiredUsers) {
    await User.findByIdAndUpdate(user._id, { subscriptionStatus: 'expired' });

    await resend.emails.send({
      from: 'billing@pixelanas.com',
      to: user.email,
      subject: 'Your subscription has expired',
      react: PastDueEmail({ name: user.name }),
    });
  }

  return Response.json({ processed: expiredUsers.length });
}

This runs as a normal Next.js route handler, using the same database connection and email setup as everything else in the app. Nothing special about the logic itself, the only thing that changes is what triggers it.

3. Securing the Endpoint

This is the part people skip, and it matters a lot. A cron endpoint is a public URL by default, anyone who finds it can call it directly and trigger whatever it does, repeatedly, on demand.

// app/api/cron/check-subscriptions/route.ts
export async function GET(request: Request) {
  const authHeader = request.headers.get('authorization');

  if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
    return new Response('Unauthorized', { status: 401 });
  }

  // proceed with the actual job
}

Vercel automatically sends this authorization header on its own scheduled calls when CRON_SECRET is set as an environment variable, so legitimate scheduled runs work without extra configuration, while a random request without the correct secret gets rejected outright.

4. Handling Long-Running Jobs Within Serverless Limits

Serverless functions have execution time limits, and a cron job processing thousands of records in a single request can hit that ceiling. Batching keeps each invocation fast and predictable.

// app/api/cron/cleanup-old-sessions/route.ts
const BATCH_SIZE = 500;

export async function GET(request: Request) {
  const authHeader = request.headers.get('authorization');
  if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
    return new Response('Unauthorized', { status: 401 });
  }

  await connectDB();

  const cutoff = new Date(Date.now() - 30 * 24 * 60 * 60 * 1000);

  const result = await Session.deleteMany({
    lastActive: { $lt: cutoff },
  }).limit(BATCH_SIZE);

  return Response.json({ deleted: result.deletedCount });
}

For a genuinely large cleanup, running this more frequently at a smaller batch size, six times a day at 500 records instead of once a day at unlimited records, keeps each individual run well within execution limits rather than risking a timeout on a single massive run.

5. Idempotency, So a Retried Job Doesn't Double-Process

Scheduled jobs can occasionally run twice, a platform retry after a slow response, a manual re-trigger while debugging. The job itself should be safe to run more than once without causing duplicate side effects.

// ❌ Sends a duplicate email if this job runs twice for the same day
await resend.emails.send({ to: user.email, subject: 'Daily digest', ... });

// ✅ Checks whether it already ran today before sending anything
const alreadySent = await DigestLog.findOne({
  userId: user._id,
  date: today,
});

if (!alreadySent) {
  await resend.emails.send({ to: user.email, subject: 'Daily digest', ... });
  await DigestLog.create({ userId: user._id, date: today });
}

A small log collection tracking what has already run for a given period turns an accidental double-trigger from a real problem, duplicate emails, duplicate charges, into a harmless no-op.

6. Manually Triggering a Job for Testing

Since these endpoints require the secret header, testing locally means sending that header manually rather than just visiting the URL in a browser.

curl -X GET http://localhost:3000/api/cron/check-subscriptions \
  -H "Authorization: Bearer your-local-cron-secret"

This confirms the actual logic works correctly without waiting for the real schedule to trigger it, useful during development or when debugging a job that failed in production.

7. Alternatives to Vercel Cron

For projects not on Vercel, or needing more control over scheduling than Vercel Cron's minimum one-minute granularity allows, external services like Upstash QStash or a traditional cron service calling a webhook work the same way, an external trigger calling a secured route handler on a schedule. The route handler code itself stays identical either way, only the thing invoking it changes.

Summary

Piece	Handles
`vercel.json` cron config	Defining the schedule without a separate service
Route handler with normal app logic	The actual job, using the same db/email setup as everything else
`CRON_SECRET` header check	Preventing anyone from triggering the job by just visiting the URL
Batched processing	Staying within serverless execution time limits
Idempotency check before side effects	Safe behavior if the job accidentally runs twice
Manual curl trigger with the auth header	Testing the job locally without waiting on the real schedule

The part that actually matters most here is treating a cron endpoint with the same seriousness as any other route that changes data or sends emails. It is a public URL until proven otherwise, and the two failure modes that actually cause damage, an unsecured endpoint and a non-idempotent job, are both fixed with a small amount of code up front.

I use this exact Vercel Cron setup, secured with a shared secret, idempotent through a log check, for subscription checks and cleanup jobs across the SaaS projects I build.

Get the templates: https://pixelanas.gumroad.com

Do you run scheduled jobs on Vercel Cron, or reach for something external? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Internationalization in Next.js 15 The Setup I Use for Multi-Language Apps

Anas Sheikh — Fri, 14 Aug 2026 12:45:37 +0000

The first time I added a second language to a project, I stored the actual translated string in component state instead of a translation key. It worked fine until a user switched languages mid-session and half the interface stayed in the old language because the state never knew it needed to update. Small mistake, annoying bug, and it taught me the one rule that makes i18n actually maintainable, translated strings never belong in state, only keys do.

Here is the setup I use now with next-intl.

1. The Setup

npm install next-intl

messages/
├── en.json
└── es.json

// messages/en.json
{
  "nav": {
    "home": "Home",
    "pricing": "Pricing",
    "contact": "Contact"
  },
  "hero": {
    "title": "Build faster with Next.js templates",
    "subtitle": "Production-ready templates for your next project"
  }
}

// messages/es.json
{
  "nav": {
    "home": "Inicio",
    "pricing": "Precios",
    "contact": "Contacto"
  },
  "hero": {
    "title": "Construye más rápido con plantillas Next.js",
    "subtitle": "Plantillas listas para producción para tu próximo proyecto"
  }
}

Nested keys, not flat ones, matter here. nav.home reads clearly and groups related strings together, versus a flat file with dozens of loosely related top-level keys that gets hard to navigate as a project grows.

2. Locale-Based Routing

// i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: ['en', 'es'],
  defaultLocale: 'en',
});

// middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

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

app/
├── [locale]/
│   ├── layout.tsx
│   ├── page.tsx
│   └── pricing/
│       └── page.tsx

Every route lives under a [locale] segment, /en/pricing and /es/pricing, and middleware detects the visitor's preferred language from their browser and redirects to the matching locale automatically on first visit.

3. Using Translations in a Server Component

// app/[locale]/page.tsx
import { useTranslations } from 'next-intl';

export default function HomePage() {
  const t = useTranslations('hero');

  return (
    <div>
      <h1>{t('title')}</h1>
      <p>{t('subtitle')}</p>
    </div>
  );
}

useTranslations('hero') scopes the translator to the hero object in the messages file, so t('title') reaches hero.title without repeating the full path on every call.

4. Never Store Translated Strings in State

This is the mistake from the intro, and it is easy to make without noticing.

// ❌ Storing the translated string itself
'use client';
const [status, setStatus] = useState('Loading...'); // hardcoded, English only

// ✅ Storing the key, translating at render time
'use client';
import { useTranslations } from 'next-intl';

function StatusDisplay({ statusKey }: { statusKey: 'loading' | 'done' }) {
  const t = useTranslations('status');
  return <p>{t(statusKey)}</p>;
}

The first version breaks the moment a user switches languages, since the string was already resolved into English and stored, with nothing left to tell it to re-translate. The second version always reads the current locale at render time, so switching languages updates every piece of text immediately, including state that was set before the switch happened.

5. Pluralization and Variables

Hardcoding plural forms breaks in most languages, since pluralization rules differ from English in ways that go beyond just adding an "s."

// messages/en.json
{
  "queue": {
    "waitingCount": "{count, plural, =0 {No one waiting} =1 {1 person waiting} other {# people waiting}}"
  }
}

const t = useTranslations('queue');
t('waitingCount', { count: waitingPatients.length });

ICU message format, the {count, plural, ...} syntax, handles the actual pluralization logic per language, rather than a hardcoded count === 1 ? 'person' : 'people' check that only works correctly for English's specific pluralization rules.

6. Language Switching Without Losing the Current Page

// components/LocaleSwitcher.tsx
'use client';
import { usePathname, useRouter } from 'next/navigation';
import { useLocale } from 'next-intl';

export function LocaleSwitcher() {
  const router = useRouter();
  const pathname = usePathname();
  const currentLocale = useLocale();

  function switchLocale(newLocale: string) {
    const newPath = pathname.replace(`/${currentLocale}`, `/${newLocale}`);
    router.push(newPath);
  }

  return (
    <select value={currentLocale} onChange={(e) => switchLocale(e.target.value)}>
      <option value="en">English</option>
      <option value="es">Español</option>
    </select>
  );
}

Replacing just the locale segment of the current path, rather than redirecting to the home page, keeps someone on /es/pricing when they switch from Spanish back to /en/pricing, instead of dropping them back to the homepage and losing their place.

7. Metadata Per Locale

SEO metadata needs to be translated too, not just the visible page content, since a title tag in the wrong language for a given locale looks broken to both users and search engines.

// app/[locale]/page.tsx
import { getTranslations } from 'next-intl/server';

export async function generateMetadata({ params }: { params: Promise<{ locale: string }> }) {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: 'metadata' });

  return {
    title: t('title'),
    description: t('description'),
  };
}

getTranslations, the server-side equivalent of useTranslations, works the same way inside generateMetadata, keeping title and description translated per locale rather than defaulting to one language across every version of the page.

8. Hreflang Tags for Search Engines

Without this, Google may not understand that /en/pricing and /es/pricing are the same page in different languages, rather than duplicate content competing against each other.

// app/[locale]/layout.tsx
export async function generateMetadata({ params }: { params: Promise<{ locale: string }> }) {
  const { locale } = await params;

  return {
    alternates: {
      languages: {
        en: '/en',
        es: '/es',
      },
    },
  };
}

This tells search engines these pages are language variants of the same content, which is the correct signal for a genuinely multi-language site, distinct from the canonical URL issue covered in the SEO metadata setup, that one was about duplicate versions of the same-language content, this is about intentionally different-language versions of the same page.

Summary

Pattern	Handles
Nested translation keys per locale	Organized, maintainable translation files
`[locale]` route segment + middleware	Locale-aware routing and automatic detection
Keys stored, not translated strings	Language switches updating everything immediately
ICU plural format	Pluralization rules that differ from English
Locale switcher preserving the current path	Not losing the user's place when they change language
`generateMetadata` with `getTranslations`	SEO metadata translated per locale, not just page content
`hreflang` via `alternates.languages`	Telling search engines these are language variants, not duplicates

The rule that actually matters most: state and component logic should only ever hold translation keys, never resolved strings. Everything else in this setup, plurals, routing, metadata, follows naturally once that one boundary is respected consistently.

I use this exact next-intl setup on any project that needs more than one language, keeping translation keys in state and letting the render layer handle the actual translation every time.

Get the templates: https://pixelanas.gumroad.com

Have you built a multi-language Next.js app before? What tripped you up? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Multi-Tenancy in Next.js 15 The Pattern I Use for SaaS Products

Anas Sheikh — Thu, 13 Aug 2026 10:16:31 +0000

The first version of a multi-tenant feature I built had a bug where one clinic's queue data briefly showed up in another clinic's dashboard. Nothing malicious, just a missing filter on one query, but it was the kind of mistake that makes clear how unforgiving multi-tenancy actually is. Get isolation wrong once, and you are not looking at a cosmetic bug, you are looking at one customer's data appearing in front of another.

Here is how I structure it now to make that mistake much harder to make.

1. What Multi-Tenancy Actually Means

A multi-tenant SaaS serves multiple separate customers, tenants, clinics, companies, teams, from one shared application and often one shared database, while keeping each tenant's data completely isolated from every other tenant's.

The alternative, a fully separate database per tenant, is more isolated by default but far more operationally expensive to run and maintain at any real scale. For most SaaS products, a shared database with tenant scoping enforced at the application layer is the more practical starting point.

2. Scoping Every Model to a Tenant

Every collection that holds tenant-specific data needs a tenantId (or clinicId, organizationId, whatever fits the domain) field, indexed, and referenced on every single query without exception.

// models/QueueEntry.ts
import { Schema, model, models } from 'mongoose';

const QueueEntrySchema = new Schema({
  tenantId: {
    type: Schema.Types.ObjectId,
    ref: 'Tenant',
    required: true,
    index: true,
  },
  patientName: { type: String, required: true },
  status: { type: String, enum: ['waiting', 'called', 'done'], default: 'waiting' },
  position: Number,
}, { timestamps: true });

export const QueueEntry = models.QueueEntry || model('QueueEntry', QueueEntrySchema);

Indexing tenantId matters beyond correctness, every query is going to filter by it, so it needs to actually be fast once a tenant's data grows.

3. Centralizing Tenant Scoping Instead of Repeating It

The dangerous version of multi-tenancy is remembering to add { tenantId } to every single query by hand, across every file, forever. One missed filter is exactly the kind of bug that leaks data between tenants. Centralizing it removes that risk from individual query authors.

// lib/tenant-scope.ts
import { getSession } from '@/lib/auth';

export async function getTenantId(): Promise<string> {
  const session = await getSession();
  if (!session?.tenantId) {
    throw new Error('No tenant context available');
  }
  return session.tenantId;
}

// lib/queries/queue.ts
import { getTenantId } from '@/lib/tenant-scope';
import { QueueEntry } from '@/models/QueueEntry';

export async function getQueue() {
  const tenantId = await getTenantId();
  return QueueEntry.find({ tenantId }).sort({ position: 1 }).lean();
}

export async function callNext() {
  const tenantId = await getTenantId();
  return QueueEntry.findOneAndUpdate(
    { tenantId, status: 'waiting' },
    { status: 'called' },
    { sort: { position: 1 }, new: true }
  );
}

Every query function pulls tenantId from the same place, the current session, rather than trusting a value passed in from the client, which could be tampered with. The tenant boundary is enforced server-side, based on who is actually logged in, not on anything the request itself claims.

4. Never Trust a Tenant ID from the Client

This is the mistake that actually causes cross-tenant data leaks in practice. A tenant ID sent as a form field, a query parameter, or a request body value can be edited by anyone who opens dev tools, if the server blindly trusts it.

// ❌ Trusting a client-supplied tenant ID
export async function getQueue(tenantId: string) {
  return QueueEntry.find({ tenantId }).lean(); // tenantId came from the request
}

// ✅ Deriving tenant ID from the authenticated session, server-side only
export async function getQueue() {
  const tenantId = await getTenantId(); // from the session, never the request
  return QueueEntry.find({ tenantId }).lean();
}

The only place a tenant ID should ever come from is the authenticated session on the server. If a query function accepts a tenant ID as a parameter passed in from outside, that is the exact shape of bug that leaks one tenant's data into another's view.

5. Subdomain-Based Tenant Routing

For a SaaS where each tenant gets their own subdomain, clinicname.yourapp.com, middleware resolves which tenant a request belongs to before it reaches any page.

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const host = request.headers.get('host') || '';
  const subdomain = host.split('.')[0];

  if (subdomain && subdomain !== 'www' && subdomain !== 'app') {
    const response = NextResponse.next();
    response.headers.set('x-tenant-subdomain', subdomain);
    return response;
  }

  return NextResponse.next();
}

// lib/tenant-scope.ts
import { headers } from 'next/headers';

export async function getTenantFromSubdomain() {
  const headersList = await headers();
  const subdomain = headersList.get('x-tenant-subdomain');

  if (!subdomain) throw new Error('No tenant subdomain found');

  const tenant = await Tenant.findOne({ subdomain }).lean();
  if (!tenant) throw new Error('Tenant not found');

  return tenant;
}

This resolves which tenant a request belongs to purely from the URL, before any session even needs to be checked, useful for public-facing tenant pages that do not require login, a clinic's public queue display, for example.

6. Combining Subdomain and Session-Based Scoping

For authenticated dashboard routes, both checks matter together, the subdomain tells you which tenant's app is being accessed, and the session confirms the logged-in user actually belongs to that tenant.

// lib/tenant-scope.ts
export async function requireTenantAccess() {
  const session = await getSession();
  if (!session) redirect('/login');

  const tenant = await getTenantFromSubdomain();

  if (session.tenantId !== tenant._id.toString()) {
    // Logged in, but to a different tenant than the one being accessed
    redirect('/unauthorized');
  }

  return { session, tenant };
}

Without this second check, a user logged into one tenant could potentially navigate to another tenant's subdomain and, depending on how session cookies are scoped, end up interacting with data that does not belong to them. Checking both explicitly closes that gap.

7. Tenant-Scoped Rate Limiting and Usage Limits

Multi-tenant SaaS often needs per-tenant limits, a free plan capped at a certain number of records, an API limit per tenant rather than per user.

// lib/queries/queue.ts
export async function addToQueue(patientName: string) {
  const tenantId = await getTenantId();

  const tenant = await Tenant.findById(tenantId).lean();
  const currentCount = await QueueEntry.countDocuments({ tenantId, status: 'waiting' });

  if (tenant.plan === 'free' && currentCount >= 20) {
    throw new Error('Queue limit reached for your plan');
  }

  return QueueEntry.create({ tenantId, patientName, status: 'waiting' });
}

Checking the plan limit inside the same function that creates the record, rather than as a separate step that could be skipped, keeps the limit actually enforced everywhere the record could be created.

Summary

Pattern	Handles
`tenantId` on every tenant-scoped model, indexed	Data isolation at the schema level
Centralized `getTenantId()` from session	Removing the risk of a manually forgotten filter
Never trusting a client-supplied tenant ID	The actual cause of most real cross-tenant data leaks
Subdomain middleware resolution	Routing and public pages scoped per tenant, pre-auth
Combined subdomain + session check	Preventing a logged-in user from reaching another tenant's data
Plan limits enforced inside the write function	Usage limits that cannot be bypassed by skipping a separate check

The single rule that matters most: a tenant ID is a security boundary, not just a filter. It should only ever come from something the server itself can verify, the authenticated session, never from anything the client sends in a request. Every real multi-tenancy bug I have seen traces back to that boundary being trusted from the wrong source.

I use this exact pattern, session-derived tenant scoping, subdomain routing, plan limits enforced at the write layer, in the SaaS products I build.

Get the templates: https://pixelanas.gumroad.com

Have you built multi-tenant features before? What tripped you up first? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Accessibility in Next.js 15 The Patterns I Actually Check For

Anas Sheikh — Wed, 12 Aug 2026 10:43:12 +0000

For a long time accessibility was something I meant to get to eventually, after the actual features were done. Then a client project needed to meet real accessibility requirements for a healthcare-adjacent product, and going back to retrofit it after the fact took far longer than building it in from the start would have.

Here is what I actually check for now, built in as I go rather than audited in afterward.

1. Focus Management on Client-Side Navigation

This is the one most App Router sites get wrong, and it is specific to how client-side routing works. On a traditional page load, focus resets to the top of the document naturally. With client-side navigation, it does not, a screen reader user can navigate to a new page and have no indication anything changed, since focus stays wherever it was on the previous page.

// components/RouteAnnouncer.tsx
'use client';
import { usePathname } from 'next/navigation';
import { useEffect, useRef } from 'react';

export function RouteAnnouncer() {
  const pathname = usePathname();
  const announcerRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    if (announcerRef.current) {
      const title = document.title;
      announcerRef.current.textContent = `Navigated to ${title}`;
    }
  }, [pathname]);

  return (
    <div
      ref={announcerRef}
      role="status"
      aria-live="polite"
      className="sr-only"
    />
  );
}

// app/layout.tsx
import { RouteAnnouncer } from '@/components/RouteAnnouncer';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <RouteAnnouncer />
        {children}
      </body>
    </html>
  );
}

aria-live="polite" means a screen reader announces the content change without interrupting whatever the user is currently doing, and sr-only (a class that visually hides content while keeping it available to assistive tech) means this never shows up on screen, it exists purely for the announcement.

2. Semantic HTML Before Any ARIA

The single most impactful accessibility habit is also the simplest, using the HTML element that actually matches what something is, rather than a div with a click handler and an ARIA role bolted on.

// ❌ A div pretending to be a button
<div onClick={handleClick} className="button-style">
  Submit
</div>

// ✅ An actual button
<button onClick={handleClick} className="button-style">
  Submit
</button>

A real <button> gets keyboard focus, responds to Enter and Space, and gets announced correctly by screen readers, all without writing a single line of extra code. A styled div requires manually reimplementing every one of those behaviors, and it is easy to miss one.

3. Labeling Form Inputs Correctly

// ❌ Placeholder as the only label
<input type="email" placeholder="Email address" />

// ✅ A real, associated label
<div>
  <label htmlFor="email">Email address</label>
  <input id="email" type="email" name="email" />
</div>

Placeholder text disappears the moment someone starts typing, and it is not reliably announced by every screen reader as a label in the first place. A real <label> with a matching htmlFor and id stays associated with the input regardless of what has been typed into it.

4. Keyboard Navigation for Custom Components

Anything interactive that is not a native HTML element, a custom dropdown, a modal, a tab interface, needs keyboard support built in explicitly, since none of it comes for free the way a native <select> or <button> does.

// components/Modal.tsx
'use client';
import { useEffect, useRef } from 'react';

export function Modal({ isOpen, onClose, children }: { isOpen: boolean; onClose: () => void; children: React.ReactNode }) {
  const modalRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    if (!isOpen) return;

    function handleKeyDown(e: KeyboardEvent) {
      if (e.key === 'Escape') onClose();
    }

    document.addEventListener('keydown', handleKeyDown);
    modalRef.current?.focus();

    return () => document.removeEventListener('keydown', handleKeyDown);
  }, [isOpen, onClose]);

  if (!isOpen) return null;

  return (
    <div
      ref={modalRef}
      role="dialog"
      aria-modal="true"
      tabIndex={-1}
      className="modal"
    >
      {children}
    </div>
  );
}

Three things matter here beyond the visible markup. role="dialog" and aria-modal="true" tell assistive tech this is a modal overlay, Escape closes it the way users expect any modal to behave, and moving focus into the modal when it opens means keyboard and screen reader users are not left interacting with content hidden behind it.

5. Color Contrast, Checked Not Assumed

A design system built entirely around low-contrast gray-on-gray text, common in a lot of "modern" dark-mode dashboards, frequently fails WCAG contrast requirements without looking obviously broken to a sighted designer with good vision.

/* Often fails contrast checks despite looking fine */
color: #6b7280; /* gray-500 */
background: #111827; /* gray-900 */

/* Passes comfortably */
color: #d1d5db; /* gray-300 */
background: #111827;

Running actual text and background color pairs through a contrast checker, rather than trusting that a design "looks readable," catches this before it ships. WCAG AA requires a 4.5:1 contrast ratio for normal text, and it is genuinely common for a sleek, muted color palette to fall short of that without an obvious visual sign.

6. Images and Icons Need Real Alternative Text

// A meaningful image needs a real description
<Image src="/dashboard-screenshot.png" alt="Analytics dashboard showing monthly revenue trend" width={800} height={500} />

// A purely decorative image should be explicitly hidden from screen readers
<Image src="/decorative-swirl.svg" alt="" width={40} height={40} />

An empty alt="" is not a mistake here, it is deliberate, telling a screen reader to skip an image that carries no actual information. The mistake is the opposite, leaving alt off entirely, which forces some screen readers to read out the file name instead, or applying the exact same generic alt="image" to every image on a page regardless of what it actually shows.

7. Testing With axe, Not Just Manual Review

npm install -D @axe-core/react

// app/layout.tsx (development only)
if (process.env.NODE_ENV === 'development') {
  const React = require('react');
  const ReactDOM = require('react-dom');
  const axe = require('@axe-core/react');
  axe(React, ReactDOM, 1000);
}

This logs accessibility violations directly to the browser console during development, missing labels, insufficient contrast, invalid ARIA usage, catching a real category of issues automatically that are easy to miss scanning a page visually, without needing a full manual audit for every single page.

What Actually Matters Most, in Order

Semantic HTML first. A <button> and a <nav> fix more accessibility issues by default than any amount of ARIA attributes added afterward.

Focus management on navigation. The App Router specific issue that plain HTML pages never had to think about.

Keyboard support on anything custom. If it is not a native element, it needs Escape, Tab, and Enter handled explicitly.

Contrast checked, not assumed. Especially on dark, muted design systems that look fine to a sighted designer but fail a real contrast test.

Real alt text, including deliberately empty alt text for decoration.

Summary

Pattern	Fixes
Route announcer with `aria-live`	Silent navigation on client-side route changes
Semantic HTML over styled `div`s	Keyboard focus and screen reader support, largely for free
Real `<label>` elements	Inputs losing their label the moment someone types
Explicit keyboard handling on custom components	Modals, dropdowns, and tabs unusable without a mouse
Contrast checked against real values	Muted color palettes that fail WCAG without looking broken
`alt=""` for decorative images	Screen readers reading out meaningless file names
axe-core in development	Catching real violations automatically, not just by eye

Accessibility built in from the start costs almost nothing extra, using the right element, writing a real label, adding one aria-live region. Retrofitting it after a project is already built in the wrong shape costs real time, and it is the difference I actually noticed once I started treating this as part of building the component the first time, not a separate pass at the end.

I check every item on this list on client projects now, especially anything used by a genuinely broad audience, not just as an afterthought before launch.

Get the templates: https://pixelanas.gumroad.com

Do you build accessibility in from the start, or treat it as a pass at the end? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Next.js 15 Middleware Everything Beyond Auth Checks

Anas Sheikh — Tue, 11 Aug 2026 19:19:51 +0000

Most middleware tutorials stop at "check if the user is logged in, redirect if not." That is a real use case, but middleware runs before every matched request, which makes it useful for a lot more than auth checks. Here is what else I actually reach for it.

1. What Middleware Actually Is

Middleware runs on the Edge Runtime, before a request reaches your actual route, and before any rendering starts. It can read the request, redirect, rewrite the URL, or modify headers, but it cannot do everything a normal Server Component or route handler can, no direct database access, no Node-specific APIs, since it runs in a more limited environment optimized for speed.

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  return NextResponse.next();
}

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

That matcher pattern excludes static assets and images, since middleware running on every single asset request adds latency for no benefit. Scoping it tightly matters more than it looks like it should once traffic is real.

2. Redirecting Old URLs

For a site migration or a URL structure change, redirecting at the middleware level keeps old links and search rankings intact instead of breaking them.

// middleware.ts
const redirectMap: Record<string, string> = {
  '/old-blog': '/blog',
  '/services': '/templates',
};

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  if (redirectMap[pathname]) {
    return NextResponse.redirect(new URL(redirectMap[pathname], request.url));
  }

  return NextResponse.next();
}

For a handful of redirects, next.config.ts redirects (covered in the SEO metadata setup) are actually the better choice, since they are handled at the CDN level without invoking middleware at all. Middleware redirects make more sense when the logic is dynamic, based on something in the request itself, not just a static old-path-to-new-path map.

3. www and https Canonicalization

The exact fix for the www versus non-www split that shows up as duplicate pages in Search Console:

export function middleware(request: NextRequest) {
  const url = request.nextUrl.clone();
  const host = request.headers.get('host');

  if (host === 'pixelanas.com') {
    url.host = 'www.pixelanas.com';
    url.protocol = 'https';
    return NextResponse.redirect(url, 301);
  }

  return NextResponse.next();
}

A 301, not a 302, matters here specifically for SEO. A 301 tells search engines this redirect is permanent, consolidating ranking signals onto the canonical URL. A 302 signals a temporary redirect, which does not pass that same consolidation.

4. Geolocation-Based Routing

Next.js middleware has access to geolocation data derived from the request, useful for showing region-specific pricing, currency, or content without a client-side flicker after the page has already loaded.

export function middleware(request: NextRequest) {
  const country = request.geo?.country ?? 'US';
  const response = NextResponse.next();
  response.headers.set('x-user-country', country);
  return response;
}

// app/pricing/page.tsx
import { headers } from 'next/headers';

export default async function PricingPage() {
  const headersList = await headers();
  const country = headersList.get('x-user-country') ?? 'US';

  const currency = country === 'GB' ? 'GBP' : country === 'PK' ? 'PKR' : 'USD';

  return <PricingTable currency={currency} />;
}

Passing the detected country through as a header, then reading it in the Server Component, keeps the actual pricing logic out of middleware itself, middleware's job here is just detection and forwarding, not business logic.

5. A/B Testing Without Layout Shift

Client-side A/B testing often causes a visible flicker, the default variant renders first, then swaps once JavaScript determines which test group the visitor belongs to. Assigning the variant in middleware avoids this entirely, since the decision happens before any HTML is sent.

export function middleware(request: NextRequest) {
  const response = NextResponse.next();

  let variant = request.cookies.get('ab-variant')?.value;

  if (!variant) {
    variant = Math.random() < 0.5 ? 'a' : 'b';
    response.cookies.set('ab-variant', variant, { maxAge: 60 * 60 * 24 * 30 });
  }

  response.headers.set('x-ab-variant', variant);
  return response;
}

Setting the cookie on first visit and reusing it on subsequent requests keeps a visitor in the same variant across their whole session instead of flipping randomly on every page load, which would make the test data meaningless.

6. Rate Limiting at the Edge

For public routes with tight abuse concerns, checking a rate limit in middleware blocks the request before it reaches your actual route handler or Server Action at all, slightly earlier than checking inside the handler itself as covered in the rate limiting setup.

import { ratelimit } from '@/lib/ratelimit';

export async function middleware(request: NextRequest) {
  if (request.nextUrl.pathname.startsWith('/api/public')) {
    const ip = request.headers.get('x-forwarded-for') ?? 'unknown';
    const { success } = await ratelimit.limit(ip);

    if (!success) {
      return NextResponse.json({ error: 'Too many requests' }, { status: 429 });
    }
  }

  return NextResponse.next();
}

This works well for a small number of genuinely public, high-risk routes. For rate limiting across many different Server Actions with different limits each, handling it per-action, like in the dedicated rate limiting setup, stays more maintainable than trying to encode every rule into one middleware file.

7. What Middleware Should Not Do

Heavy computation. Middleware runs on every matched request, on the Edge Runtime, with tighter execution limits than a normal server function. Anything expensive, a complex database aggregation, heavy processing, belongs in the actual route or Server Component, not middleware.

Direct database queries in most cases. The Edge Runtime does not support every Node.js database driver. Mongoose specifically does not run reliably in middleware. Auth checks in middleware should verify a signed token, not query the database to confirm a session is still valid, that check belongs in the layout or page itself.

Anything that needs to run only once per navigation, not once per request. Middleware fires on every matched request, including prefetches Next.js triggers automatically for links in the viewport. Logic that assumes "the user just navigated here" can fire more often than expected because of this.

Summary

Pattern	Use case
Redirect map	Dynamic redirects that don't fit a static `next.config.ts` list
Host-based 301 redirect	www/non-www and http/https canonicalization
Geolocation header forwarding	Region-specific pricing or content without client flicker
Cookie-based variant assignment	A/B testing without a visible flash of the wrong variant
Edge rate limiting on public routes	Blocking abuse before it reaches a route handler
Signed token check, not a DB query	Fast auth gating without exceeding Edge Runtime limits

The mental model that keeps middleware useful instead of a dumping ground for logic: it is a fast, lightweight gate that runs on every request, not a place to put anything that needs real computation or a database. Detect, redirect, forward a header, block. Anything heavier belongs one layer further in.

I use several of these, canonical redirects, geolocation-based content, together on client sites where they genuinely matter.

Get the templates: https://pixelanas.gumroad.com

Do you use middleware for much beyond auth checks? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Error Monitoring in Next.js 15 with Sentry What I Actually Track

Anas Sheikh — Mon, 10 Aug 2026 09:49:53 +0000

error.tsx` catches a failure and shows the user something reasonable. It does not tell you the failure happened at all unless you are actively watching. For a while my "monitoring" was a client messaging me that something was broken, which is not monitoring, it is finding out from the worst possible source.

Here is the Sentry setup I actually use now, tuned to catch what matters without burying it in noise.

1. The Setup

bash npx @sentry/wizard@latest -i nextjs

The wizard generates the config files and wraps next.config.ts automatically. Worth reviewing what it creates rather than trusting it blindly, since the defaults capture more than most projects actually need.

`ts
// sentry.client.config.ts
import * as Sentry from '@sentry/nextjs';

Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
tracesSampleRate: 0.1,
environment: process.env.NODE_ENV,
});
`

`ts
// sentry.server.config.ts
import * as Sentry from '@sentry/nextjs';

Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
tracesSampleRate: 0.1,
});
`

tracesSampleRate: 0.1 matters more than it looks like it should. Setting this to 1.0 captures full performance tracing on every single request, which sounds thorough and quickly becomes expensive and noisy once real traffic shows up. Ten percent is a reasonable starting point for most projects, adjustable once you see actual volume.

2. Connecting It to error.tsx

This is the piece that is easy to miss. error.tsx handles the user-facing fallback, but nothing about it reports the error anywhere by default.

`tsx
// app/dashboard/error.tsx
'use client';
import * as Sentry from '@sentry/nextjs';
import { useEffect } from 'react';

export default function DashboardError({
error,
reset,
}: {
error: Error & { digest?: string };
reset: () => void;
}) {
useEffect(() => {
Sentry.captureException(error);
}, [error]);

return (

Something went wrong.

Try again

);
}
`

Without this useEffect, the error boundary works perfectly from the user's perspective, and you never find out it fired at all.

3. Capturing Errors in Server Actions

Server Actions that catch their own errors and return a typed result, the pattern from the form handling setup, are good UX. They are also silent by default, since a caught error never reaches an error boundary or Sentry unless you report it explicitly.

`ts
// actions/contact.ts
'use server';
import * as Sentry from '@sentry/nextjs';
import { ContactSchema } from '@/lib/validations/contact';

export async function submitContact(input: unknown) {
const parsed = ContactSchema.safeParse(input);

if (!parsed.success) {
return { success: false, message: 'Validation failed' };
}

try {
await db.messages.create({ data: parsed.data });
return { success: true, message: 'Message sent' };
} catch (error) {
Sentry.captureException(error, {
tags: { action: 'submitContact' },
});
return { success: false, message: 'Something went wrong' };
}
}
`

The tags: { action: 'submitContact' } matters once a project has more than a handful of Server Actions. Without it, every caught error shows up in Sentry as a generic database exception with no indication of which action actually triggered it.

4. Attaching User Context

An error report with no idea which user hit it is far harder to investigate, especially for something that only affects one account or one specific data condition.

`ts
// lib/auth.ts
import * as Sentry from '@sentry/nextjs';

export async function getSession(): Promise {
const session = await verifySessionFromCookie();

if (session) {
Sentry.setUser({ id: session.userId, email: session.email });
}

return session;
}
`

Setting this once, near where the session is already being read, means every subsequent error captured during that request automatically includes which user was affected, without needing to pass user info into every individual captureException call.

5. Filtering Out Noise Before It Reaches You

Not every thrown error deserves an alert. Bots hitting invalid routes, expected validation failures, browser extensions injecting broken scripts, all generate errors that are not actually actionable.

ts // sentry.client.config.ts Sentry.init({ dsn: process.env.NEXT_PUBLIC_SENTRY_DSN, ignoreErrors: [ 'ResizeObserver loop limit exceeded', // harmless browser quirk 'Non-Error promise rejection captured', // usually a browser extension ], beforeSend(event, hint) { const error = hint.originalException; if (error instanceof Error && error.message.includes('ChunkLoadError')) { // Usually just a stale cached bundle after a new deploy, not a real bug return null; } return event; }, });

A monitoring setup that alerts on genuine noise trains you to ignore it, which defeats the purpose. Filtering these out up front keeps what does come through worth actually looking at.

6. Alerting on What Actually Matters

Sentry's default alerting fires on every new issue, which becomes unmanageable fast on any project with real traffic. In the Sentry dashboard, alert rules can scope to what genuinely needs immediate attention:

Payment or checkout errors — immediate alert, since this directly affects revenue
Auth failures spiking above normal volume — could indicate an attack or a broken deploy
A new error type appearing for the first time — worth a look, not necessarily urgent
The same known issue recurring — usually just a dashboard check, not a page

Scoping alerts by severity, rather than treating every captured exception as equally urgent, is what keeps monitoring useful instead of becoming another source of notifications everyone learns to dismiss.

7. What I Actually Monitor on Every Project

Server Action failures, tagged by which action, since these often represent a real user-facing failure that a route-level error boundary alone would not surface with enough detail.

Webhook handler failures, specifically Stripe and any other external service. A silently failing webhook means subscription status or payment state quietly goes out of sync with no visible symptom until a customer notices.

Auth and session errors, since these can indicate either a bug or actual malicious activity, and the distinction matters for how urgently to respond.

Anything inside a try/catch that was previously just logged to the console. Console logs disappear the moment a serverless function finishes executing. If it was worth catching and logging before, it is worth Sentry capturing now.

Summary

Piece	Handles
`Sentry.captureException` in `error.tsx`	Actually reporting errors the boundary already catches
Capturing inside Server Action try/catch blocks	Errors that are handled gracefully but still worth knowing about
`Sentry.setUser`	Knowing which account was affected without manual tagging everywhere
`ignoreErrors` and `beforeSend` filtering	Keeping noise out so real issues stand out
Scoped alert rules	Urgent alerts for payment/auth issues, not a notification for every exception
Tagging by action or route	Finding which specific piece of code actually failed

The shift that mattered most for me: an error boundary or a caught exception handling a failure gracefully for the user does not mean the failure does not matter. It means the failure is invisible unless something explicitly reports it, which is the entire gap Sentry closes.

I run this exact setup, Sentry wired into error boundaries, Server Actions, and webhook handlers, on every client project that has actual users depending on it.

Get the templates: https://pixelanas.gumroad.com

Do you have real error monitoring set up, or find out about production bugs from users first? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Animations in Next.js 15 with Framer Motion The Patterns I Actually Use

Anas Sheikh — Sun, 09 Aug 2026 10:17:08 +0000

Most animation advice online is either a flashy demo with a dozen effects stacked on top of each other, or nothing at all. What actually makes a dashboard or product feel polished is usually the opposite of flashy, small, consistent motion that makes state changes feel intentional instead of instant and jarring.

Here are the patterns I actually reach for.

1. The Setup

npm install framer-motion

Every animated element needs to be a Client Component, since Framer Motion relies on browser APIs and hooks that do not exist in a Server Component. The trick is keeping that boundary as small as possible, wrapping just the animated piece, not the whole page.

// components/FadeIn.tsx
'use client';
import { motion } from 'framer-motion';

export function FadeIn({ children }: { children: React.ReactNode }) {
  return (
    <motion.div
      initial={{ opacity: 0, y: 8 }}
      animate={{ opacity: 1, y: 0 }}
      transition={{ duration: 0.3 }}
    >
      {children}
    </motion.div>
  );
}

// app/dashboard/page.tsx
import { FadeIn } from '@/components/FadeIn';

export default async function DashboardPage() {
  const data = await getData(); // server-side, no client JS needed for this

  return (
    <FadeIn>
      <DashboardContent data={data} />
    </FadeIn>
  );
}

The page itself stays a Server Component doing the actual data fetching. Only the thin FadeIn wrapper needs to be client-side, keeping the rest of the JavaScript bundle untouched.

2. Stagger Effects for Lists

A list of cards or rows that all fade in together feels flat. Staggering the animation slightly across items reads as far more polished for very little extra code.

// components/StaggerList.tsx
'use client';
import { motion } from 'framer-motion';

const container = {
  hidden: { opacity: 0 },
  show: {
    opacity: 1,
    transition: { staggerChildren: 0.06 },
  },
};

const item = {
  hidden: { opacity: 0, y: 12 },
  show: { opacity: 1, y: 0 },
};

export function StaggerList({ items }: { items: { id: string; name: string }[] }) {
  return (
    <motion.div variants={container} initial="hidden" animate="show">
      {items.map((entry) => (
        <motion.div key={entry.id} variants={item}>
          {entry.name}
        </motion.div>
      ))}
    </motion.div>
  );
}

staggerChildren: 0.06 means each child starts 60 milliseconds after the previous one. Small enough that the list still feels fast, noticeable enough to register as intentional motion rather than everything appearing at once.

3. Animating Between States, Not Just In

The most common mistake is animating an element appearing once and then leaving every state change afterward completely instant. A toggle, a status change, a value updating, deserves the same care.

// components/StatusBadge.tsx
'use client';
import { motion, AnimatePresence } from 'framer-motion';

export function StatusBadge({ status }: { status: 'pending' | 'active' | 'canceled' }) {
  return (
    <AnimatePresence mode="wait">
      <motion.span
        key={status}
        initial={{ opacity: 0, scale: 0.9 }}
        animate={{ opacity: 1, scale: 1 }}
        exit={{ opacity: 0, scale: 0.9 }}
        transition={{ duration: 0.15 }}
      >
        {status}
      </motion.span>
    </AnimatePresence>
  );
}

AnimatePresence handles the exit animation too, something plain CSS transitions cannot do cleanly, since the DOM element needs to stay mounted just long enough for the exit animation to finish before actually being removed. The key={status} is what tells Framer Motion this is a genuinely new element to animate, not the same one just re-rendering.

4. Animating a List Where Items Get Added or Removed

Combining AnimatePresence with a mapped list handles items entering and leaving cleanly, which matters for anything like a live queue or a to-do list.

// components/QueueList.tsx
'use client';
import { motion, AnimatePresence } from 'framer-motion';

export function QueueList({ entries }: { entries: { id: string; name: string }[] }) {
  return (
    <AnimatePresence>
      {entries.map((entry) => (
        <motion.div
          key={entry.id}
          layout
          initial={{ opacity: 0, height: 0 }}
          animate={{ opacity: 1, height: 'auto' }}
          exit={{ opacity: 0, height: 0 }}
          transition={{ duration: 0.2 }}
        >
          {entry.name}
        </motion.div>
      ))}
    </AnimatePresence>
  );
}

The layout prop is doing real work here. When an item is removed, the remaining items smoothly slide up to fill the gap instead of snapping into their new position instantly, which is what makes a queue or list feel alive rather than just re-rendered.

5. Page Transitions in the App Router

Page transitions in the App Router need a bit more setup than a single-page app, since each route is its own Server Component tree by default.

// app/template.tsx
'use client';
import { motion } from 'framer-motion';

export default function Template({ children }: { children: React.ReactNode }) {
  return (
    <motion.div
      initial={{ opacity: 0 }}
      animate={{ opacity: 1 }}
      transition={{ duration: 0.2 }}
    >
      {children}
    </motion.div>
  );
}

template.tsx is a specific Next.js file convention, unlike layout.tsx, it re-mounts on every navigation, which is exactly what a transition animation needs, a fresh mount to animate in from, rather than a layout that persists and never re-triggers.

6. Respecting Reduced Motion

Skipping this is an easy way to make a site actively worse for someone who has motion sensitivity set at the OS level. Framer Motion makes it simple to respect that preference.

// components/FadeIn.tsx
'use client';
import { motion, useReducedMotion } from 'framer-motion';

export function FadeIn({ children }: { children: React.ReactNode }) {
  const shouldReduceMotion = useReducedMotion();

  return (
    <motion.div
      initial={shouldReduceMotion ? {} : { opacity: 0, y: 8 }}
      animate={{ opacity: 1, y: 0 }}
      transition={{ duration: shouldReduceMotion ? 0 : 0.3 }}
    >
      {children}
    </motion.div>
  );
}

useReducedMotion reads the operating system's accessibility setting directly. Respecting it is a small amount of code for something that genuinely matters to a portion of real users, not just a nice-to-have.

7. Where I Stop

The biggest lesson from client work: nearly every project has more animation opportunities than it needs. Not every card needs a hover lift, not every number needs to count up, not every element needs its own entrance animation. Overusing motion makes an interface feel busy and slower to actually use, even when each individual animation is fast.

What I actually animate, consistently: list items entering with a stagger, state changes like status badges or toggles, page transitions, and hover feedback on genuinely interactive elements like buttons. Static content, headings, paragraphs, layout structure, stays still.

Summary

Pattern	Use it for
Small Client Component wrapper	Keeping animation JS out of the Server Component tree
`staggerChildren`	Lists that should feel sequential, not instant
`AnimatePresence` + `key`	Elements changing state, not just appearing once
`layout` prop	Lists where items are added or removed, like a live queue
`template.tsx`	Page transitions that re-trigger on every navigation
`useReducedMotion`	Respecting accessibility preferences, not just adding motion everywhere

The actual skill here is restraint more than technique. Framer Motion makes almost anything possible, staggered lists, complex page transitions, physics-based springs, but the projects that feel genuinely polished use a small, consistent set of motion patterns applied deliberately, not every available effect applied everywhere.

I use this exact set, stagger on lists, state transitions with AnimatePresence, reduced motion support, across the dashboards and templates I build.

See it in a real codebase: https://neurodash-dashbord.vercel.app/

Get the templates: https://pixelanas.gumroad.com

Do you lean toward subtle motion or go heavier on animation in your projects? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751