DEV Community: Anas Sheikh

Error Handling in Next.js 15 error.tsx, notFound(), and the Patterns I Actually Use

Anas Sheikh — Thu, 30 Jul 2026 09:15:53 +0000

For a while, every unhandled error in my Next.js apps meant one thing: the whole page went white.

One failed fetch, one bad database query, and the user got a blank screen or a generic Next.js error page — no matter how small the broken piece actually was.

The App Router gives you file-based error boundaries that fix this properly. Here's how I use them now.

1. `error.tsx` — Route-Level Error Boundaries

Any folder in app/ can have an error.tsx. It automatically wraps everything below it in an error boundary — no manual <ErrorBoundary> wrapping required:

// app/dashboard/error.tsx
'use client';

export default function DashboardError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  return (
    <div className="p-8 text-center">
      <h2 className="text-lg font-semibold">Something went wrong</h2>
      <p className="text-sm text-slate-500 mt-2">{error.message}</p>
      <button
        onClick={reset}
        className="mt-4 px-4 py-2 rounded-lg bg-brand-500 text-white"
      >
        Try again
      </button>
    </div>
  );
}

error.tsx must be a Client Component — it needs reset(), which re-renders the segment and attempts recovery. If /dashboard/analytics throws, only that segment shows this fallback. The rest of the dashboard — sidebar, nav, other pages — keeps working.

2. Nested Error Boundaries — Isolate the Blast Radius

This is the part people miss: error boundaries nest. Put one closer to the risky code, and a failure there won't take out the parent route at all.

app/
├── dashboard/
│   ├── layout.tsx
│   ├── error.tsx          ← catches errors anywhere in dashboard
│   └── analytics/
│       ├── page.tsx
│       └── error.tsx      ← catches errors only in analytics

// app/dashboard/analytics/error.tsx
'use client';

export default function AnalyticsError({ reset }: { reset: () => void }) {
  return (
    <div className="rounded-lg border border-red-500/20 p-4">
      <p>Analytics failed to load.</p>
      <button onClick={reset}>Retry</button>
    </div>
  );
}

If the analytics panel throws, the sidebar and the rest of the dashboard stay fully interactive — only the analytics section shows the fallback. Without this, one flaky third-party analytics API can take down a page that has nothing to do with it.

3. `global-error.tsx` — The Last Resort

For errors in the root layout itself — where even your normal error boundaries can't help, since they live inside that layout:

// app/global-error.tsx
'use client';

export default function GlobalError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  return (
    <html>
      <body>
        <div className="p-8 text-center">
          <h1>Something went wrong</h1>
          <button onClick={reset}>Try again</button>
        </div>
      </body>
    </html>
  );
}

This one replaces the entire root layout, including <html> and <body> — it's the only case where that's necessary, and it's the fallback of last resort, not something you reach for often.

4. `not-found.tsx` and `notFound()`

For missing data — a blog post that doesn't exist, a user ID that isn't in the database — that's not really an "error," it's a 404:

// app/blog/[slug]/page.tsx
import { notFound } from 'next/navigation';

export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  if (!post) {
    notFound();
  }

  return <article>{post.content}</article>;
}

// app/blog/[slug]/not-found.tsx
export default function PostNotFound() {
  return (
    <div className="text-center py-20">
      <h2>Post not found</h2>
      <p>The post you're looking for doesn't exist or was removed.</p>
    </div>
  );
}

notFound() isn't an error — it's a signal. It stops rendering and shows the nearest not-found.tsx, with a proper 404 status code, instead of you having to manually build that logic into every page that fetches by ID or slug.

5. `loading.tsx` — Instant Loading States for Free

Pair with error boundaries for the full picture. Any segment can have a loading.tsx, and Next.js shows it automatically while the async Server Component fetches:

// app/dashboard/analytics/loading.tsx
export default function AnalyticsLoading() {
  return (
    <div className="animate-pulse space-y-4">
      <div className="h-8 w-48 bg-surface-700 rounded" />
      <div className="h-64 bg-surface-700 rounded-lg" />
    </div>
  );
}

No useState, no manual isLoading flag — Next.js wraps the segment in Suspense for you and swaps loading.tsx in the instant navigation starts, then swaps the real content in once the data resolves.

6. try/catch Still Has a Job — Inside the Fetch, Not Around It

error.tsx catches what escapes the render. It won't catch a fetch that fails silently and returns undefined instead of throwing. Handle that at the source:

// lib/queries/posts.ts
export async function getPost(slug: string) {
  try {
    const res = await fetch(`https://api.example.com/posts/${slug}`);
    if (!res.ok) return null;
    return res.json();
  } catch (err) {
    console.error('Failed to fetch post:', err);
    return null;
  }
}

Returning null on failure and handling it explicitly (if (!post) notFound()) gives you control over whether a fetch failure means "404" or "error page" — throwing indiscriminately from inside a query helper takes that decision away from the caller.

7. Server Action Errors Don't Need `error.tsx` at All

Server Actions that return a typed result instead of throwing keep failures in the UI, not in an error boundary:

// actions/posts.ts
'use server';

export async function deletePost(id: string) {
  try {
    await db.posts.delete({ where: { id } });
    revalidatePath('/dashboard/posts');
    return { success: true };
  } catch {
    return { success: false, message: 'Could not delete post' };
  }
}

A failed delete shouldn't send the user to a full error boundary — it should show an inline "couldn't delete that, try again" message right next to the button they clicked. Catch it, return it, render it.

Summary

File / Pattern	Handles
`error.tsx`	Unexpected render/fetch errors in a route segment
Nested `error.tsx`	Isolates failures to the smallest segment possible
`global-error.tsx`	Errors in the root layout itself (rare, last resort)
`not-found.tsx` + `notFound()`	Missing data — not an error, a 404
`loading.tsx`	Automatic loading UI while a segment fetches
try/catch in query helpers	Turning a failed fetch into a controlled `null`, not a crash
Typed return in Server Actions	Inline failure messages instead of a full error boundary

The shift that matters most: stop thinking of "error handling" as one big try/catch around everything, and start thinking about which segment should fail without taking the rest of the page with it.

I use this exact error/loading/not-found setup across every route in my dashboards and templates.

See it in a real codebase:

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

Do you lean on error.tsx or handle most failures with try/catch and typed returns? Drop it below 👇

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

Authentication in Next.js 15 The Pattern I Use for Every SaaS

Anas Sheikh — Wed, 29 Jul 2026 08:45:20 +0000

I used to reach for NextAuth on every project by default.

Then I built a few dashboards where I needed full control over the token — custom claims, a specific cookie strategy, no extra abstraction layer to fight with. Rolling my own JWT auth turned out simpler than expected, and it's what I use now unless a client specifically wants OAuth providers out of the box.

Here's the exact setup.

1. The Auth Helpers

// lib/auth.ts
import jwt from 'jsonwebtoken';
import { cookies } from 'next/headers';

const JWT_SECRET = process.env.JWT_SECRET as string;
const COOKIE_NAME = 'auth-token';

export interface SessionPayload {
  userId: string;
  email: string;
  role: 'admin' | 'user';
}

export function signToken(payload: SessionPayload): string {
  return jwt.sign(payload, JWT_SECRET, { expiresIn: '7d' });
}

export function verifyToken(token: string): SessionPayload | null {
  try {
    return jwt.verify(token, JWT_SECRET) as SessionPayload;
  } catch {
    return null;
  }
}

export async function setSessionCookie(payload: SessionPayload) {
  const token = signToken(payload);
  const cookieStore = await cookies();

  cookieStore.set(COOKIE_NAME, token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 60 * 60 * 24 * 7, // 7 days
    path: '/',
  });
}

export async function getSession(): Promise<SessionPayload | null> {
  const cookieStore = await cookies();
  const token = cookieStore.get(COOKIE_NAME)?.value;
  if (!token) return null;
  return verifyToken(token);
}

export async function clearSession() {
  const cookieStore = await cookies();
  cookieStore.delete(COOKIE_NAME);
}

httpOnly is non-negotiable — it's what stops the token from being readable by client-side JavaScript, which closes off the most common XSS token-theft path.

2. Login as a Server Action

// actions/auth.ts
'use server';
import { connectDB } from '@/lib/db';
import { User } from '@/models/User';
import { setSessionCookie } from '@/lib/auth';
import bcrypt from 'bcryptjs';
import { redirect } from 'next/navigation';

export async function login(prevState: any, formData: FormData) {
  const email = formData.get('email') as string;
  const password = formData.get('password') as string;

  await connectDB();
  const user = await User.findOne({ email }).select('+password');

  if (!user || !(await bcrypt.compare(password, user.password))) {
    return { success: false, message: 'Invalid email or password' };
  }

  await setSessionCookie({
    userId: user._id.toString(),
    email: user.email,
    role: user.role,
  });

  redirect('/dashboard');
}

Notice .select('+password') — the schema should exclude password from queries by default (select: false), and you opt back in only where you actually need to compare it. One less way to accidentally leak a password hash into a response.

3. Protecting Routes with Middleware

Middleware runs before the page renders, so it's the right place to block unauthenticated requests before any server component even starts fetching data:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { verifyToken } from '@/lib/auth';

const protectedRoutes = ['/dashboard', '/settings'];
const authRoutes = ['/login', '/signup'];

export function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;
  const session = token ? verifyToken(token) : null;
  const { pathname } = request.nextUrl;

  const isProtected = protectedRoutes.some((route) => pathname.startsWith(route));
  const isAuthRoute = authRoutes.some((route) => pathname.startsWith(route));

  if (isProtected && !session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  if (isAuthRoute && session) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/login', '/signup'],
};

The matcher config is what keeps middleware from running on every single request — static assets, images, and unrelated routes never touch it.

4. Reading the Session in Server Components

// app/(dashboard)/layout.tsx
import { getSession } from '@/lib/auth';
import { redirect } from 'next/navigation';

export default async function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const session = await getSession();

  if (!session) {
    redirect('/login');
  }

  return (
    <div className="flex">
      <Sidebar role={session.role} />
      <main className="flex-1">{children}</main>
    </div>
  );
}

Middleware handles the redirect for most cases, but checking again in the layout is cheap insurance — it also gives you the session data itself, not just a yes/no on whether one exists.

5. Role-Based Access on Top of Auth

Being logged in and being allowed to see a page aren't the same check. Keep them separate:

// lib/authorize.ts
import { getSession } from '@/lib/auth';
import { redirect } from 'next/navigation';

export async function requireRole(allowedRoles: Array<'admin' | 'user'>) {
  const session = await getSession();

  if (!session) {
    redirect('/login');
  }

  if (!allowedRoles.includes(session.role)) {
    redirect('/dashboard'); // logged in, just not allowed here
  }

  return session;
}

// app/(dashboard)/admin/page.tsx
import { requireRole } from '@/lib/authorize';

export default async function AdminPage() {
  const session = await requireRole(['admin']);

  return <div>Welcome, admin {session.email}</div>;
}

This separates "not logged in" (→ login page) from "logged in but not authorized" (→ somewhere safe) instead of collapsing both into one redirect, which is a common source of confusing UX for users who are authenticated but hit a page above their role.

6. Logging Out

// actions/auth.ts
'use server';
import { clearSession } from '@/lib/auth';
import { redirect } from 'next/navigation';

export async function logout() {
  await clearSession();
  redirect('/login');
}

// components/layout/LogoutButton.tsx
import { logout } from '@/actions/auth';

export function LogoutButton() {
  return (
    <form action={logout}>
      <button type="submit">Log out</button>
    </form>
  );
}

No client JavaScript needed for something this simple — the form posts straight to the server action.

The Mistakes I See Most

Storing the JWT in localStorage. It's readable by any script on the page, which means any XSS vulnerability becomes a full account takeover. httpOnly cookies aren't perfectly immune to everything, but they close off this specific and very common attack path.

Checking auth only in middleware. Middleware can be bypassed in edge cases (direct server action calls, certain caching scenarios). Always re-check the session in the layout or page itself for anything sensitive.

One giant role check. Don't sprinkle if (user.role === 'admin') across a dozen components. Centralize it in one requireRole helper so the logic only has to be correct once.

Summary

Layer	Responsibility
`lib/auth.ts`	Sign, verify, and store the JWT in an httpOnly cookie
`middleware.ts`	Block unauthenticated requests before rendering starts
Layout-level `getSession()`	Second check + gives you the session data itself
`requireRole()`	Separates "not logged in" from "not authorized"
Server Actions	Login/logout with no client-side token handling at all

I use this exact auth setup — middleware, httpOnly cookies, role helper — across the dashboards and SaaS templates I build.

See it in a real codebase:

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

Do you roll your own auth or reach for NextAuth/Clerk by default? Drop it below 👇

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

MongoDB + Mongoose Patterns I Use in Every Next.js Project

Anas Sheikh — Tue, 28 Jul 2026 18:04:36 +0000

Every MERN project starts the same way.

You copy-paste a connectDB function from an old repo. You write a schema with no validation. Three months later you're debugging duplicate connections in production.

Here's the exact Mongoose setup I use in every Next.js project now — no more guessing.

1. The Connection Caching Pattern

Next.js reuses modules across hot reloads and serverless invocations. Without caching, you'll open a new MongoDB connection on every request.

// lib/db.ts
import mongoose from 'mongoose';

const MONGODB_URI = process.env.MONGODB_URI as string;

if (!MONGODB_URI) {
  throw new Error('Missing MONGODB_URI in .env');
}

interface MongooseCache {
  conn: typeof mongoose | null;
  promise: Promise<typeof mongoose> | null;
}

declare global {
  var mongooseCache: MongooseCache | undefined;
}

const cached: MongooseCache = global.mongooseCache ?? { conn: null, promise: null };

export async function connectDB() {
  if (cached.conn) return cached.conn;

  if (!cached.promise) {
    cached.promise = mongoose.connect(MONGODB_URI, {
      bufferCommands: false,
    });
  }

  cached.conn = await cached.promise;
  global.mongooseCache = cached;
  return cached.conn;
}

The global cache survives hot reloads in dev and warm serverless functions in production. This one file fixes 90% of the "too many connections" errors people hit on Vercel.

2. Schema Design That Doesn't Bite You Later

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

export interface IUser {
  name: string;
  email: string;
  role: 'admin' | 'user';
  avatar?: string;
  createdAt: Date;
  updatedAt: Date;
}

const UserSchema = new Schema<IUser>(
  {
    name: {
      type: String,
      required: [true, 'Name is required'],
      trim: true,
      maxlength: 50,
    },
    email: {
      type: String,
      required: [true, 'Email is required'],
      unique: true,
      lowercase: true,
      trim: true,
      match: [/^\S+@\S+\.\S+$/, 'Invalid email format'],
    },
    role: {
      type: String,
      enum: ['admin', 'user'],
      default: 'user',
    },
    avatar: String,
  },
  { timestamps: true }
);

// Prevents model overwrite errors on hot reload
export const User = models.User || model<IUser>('User', UserSchema);

Three things that always bite people: no unique index on email, no timestamps: true, and redefining the model on every hot reload. The models.User || check solves that last one for good.

3. Typing Documents vs. Plain Objects

Mongoose documents and plain JS objects are not the same shape, and mixing them up causes constant type errors:

// types/db.ts
import { IUser } from '@/models/User';

// What you get back from Mongoose (has _id, methods, etc.)
export type UserDocument = IUser & { _id: string };

// What you send to the client (safe to serialize)
export type UserDTO = Omit<UserDocument, 'password'>;

export function toUserDTO(doc: any): UserDTO {
  return {
    _id: doc._id.toString(),
    name: doc.name,
    email: doc.email,
    role: doc.role,
    avatar: doc.avatar,
    createdAt: doc.createdAt,
    updatedAt: doc.updatedAt,
  };
}

Never pass a raw Mongoose document straight into a Server Component or Response.json(). Convert it first — otherwise you'll hit "Only plain objects can be passed to Client Components" errors.

4. Query Helpers Instead of Repeating `.lean()` Everywhere

// lib/queries/users.ts
import { connectDB } from '@/lib/db';
import { User } from '@/models/User';
import { toUserDTO, UserDTO } from '@/types/db';

export async function getUserById(id: string): Promise<UserDTO | null> {
  await connectDB();
  const user = await User.findById(id).lean();
  return user ? toUserDTO(user) : null;
}

export async function getUsersByRole(role: 'admin' | 'user'): Promise<UserDTO[]> {
  await connectDB();
  const users = await User.find({ role }).sort({ createdAt: -1 }).lean();
  return users.map(toUserDTO);
}

.lean() returns plain JS objects instead of full Mongoose documents — faster, and avoids serialization issues in Server Components. Wrapping every query in a typed function also means you never write raw User.find() inside a page component again.

5. Validation Before It Touches the Database

Mongoose validation runs at the database layer, but you want to reject bad input before that — same as the Zod pattern from typed Server Actions:

// lib/validations/user.ts
import { z } from 'zod';

export const CreateUserSchema = z.object({
  name: z.string().min(2).max(50),
  email: z.string().email(),
});

export type CreateUserInput = z.infer<typeof CreateUserSchema>;

// actions/users.ts
'use server';
import { connectDB } from '@/lib/db';
import { User } from '@/models/User';
import { CreateUserSchema } from '@/lib/validations/user';
import { revalidatePath } from 'next/cache';

export async function createUser(formData: FormData) {
  const parsed = CreateUserSchema.safeParse({
    name: formData.get('name'),
    email: formData.get('email'),
  });

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

  await connectDB();

  const exists = await User.findOne({ email: parsed.data.email });
  if (exists) {
    return { success: false, message: 'Email already in use' };
  }

  await User.create(parsed.data);
  revalidatePath('/dashboard/users');
  return { success: true, message: 'User created' };
}

Zod catches malformed input. The findOne check catches duplicates before Mongoose throws a raw E11000 error you'd otherwise have to parse.

6. Indexes You Actually Need

Most people never add indexes beyond the default _id. On any collection you filter or sort by often, add one:

UserSchema.index({ email: 1 }, { unique: true });
UserSchema.index({ role: 1, createdAt: -1 });

The second index speeds up exactly the kind of query from getUsersByRole above — filter by role, sort by createdAt. Without it, Mongo scans the full collection once it grows past a few thousand documents.

Summary

Pattern	Why
Cached connection in `lib/db.ts`	Stops duplicate connections on hot reload / serverless
`models.User \	\
Separate Document / DTO types	Keeps Server Components from choking on Mongoose objects
{% raw %}`.lean()` in query helpers	Faster reads, plain objects, one place to change queries
Zod validation before `User.create`	Clean errors instead of raw Mongoose exceptions
Indexes on filtered/sorted fields	Keeps queries fast as collections grow

This is the same lib/db.ts and model setup across every MERN project I ship — dashboards, SaaS backends, and the templates I sell.

See it in a real codebase:

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

How do you handle Mongoose connections in serverless? Drop it below 👇

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

How to Make Your Next.js App Blazing Fast — Performance Checklist

Anas Sheikh — Mon, 27 Jul 2026 09:53:59 +0000

A slow Next.js app is almost always caused by the same 6 things.

Here's how to find and fix all of them.

1. Images — The Biggest Performance Win

Images are responsible for most slow page loads.

// 🚫 Regular img — no optimization
<img src="/hero.jpg" alt="Hero" className="w-full" />

// ✅ Next.js Image — automatic WebP, lazy load, size optimization
import Image from 'next/image';

// For images above the fold — add priority
<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority  // preloads — only use for above-fold images
  className="w-full"
/>

// For images below the fold — lazy load by default
<Image
  src="/feature.jpg"
  alt="Feature"
  width={600}
  height={400}
  // No priority — lazy loads automatically
/>

Additional tips:

Use WebP format for all images
Compress images before uploading — use squoosh.app
Never use fill without a sized parent container

2. Fonts — Eliminate Layout Shift

// 🚫 External font link — causes layout shift and render blocking
<link href="https://fonts.googleapis.com/css2?family=Inter" rel="stylesheet" />

// ✅ next/font — self-hosted, zero layout shift
import { Inter, Plus_Jakarta_Sans } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',      // show fallback font while loading
  variable: '--font-inter',
});

const jakarta = Plus_Jakarta_Sans({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-jakarta',
});

export default function RootLayout({ children }) {
  return (
    <html className={`${inter.variable} ${jakarta.variable}`}>
      <body>{children}</body>
    </html>
  );
}

3. Bundle Size — Stop Loading What You Don't Need

Check your bundle size:

npm install -D @next/bundle-analyzer

# next.config.ts
import bundleAnalyzer from '@next/bundle-analyzer';

const withBundleAnalyzer = bundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
});

export default withBundleAnalyzer({ /* your config */ });

# Run analysis
ANALYZE=true npm run build

Common fixes:

// 🚫 Importing entire library
import _ from 'lodash';
const result = _.groupBy(items, 'category');

// ✅ Import only what you need
import groupBy from 'lodash/groupBy';
const result = groupBy(items, 'category');

// 🚫 Loading heavy component on every page
import { HeavyChart } from '@/components/HeavyChart';

// ✅ Dynamic import — only loads when needed
import dynamic from 'next/dynamic';
const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <div className="animate-pulse h-64 bg-slate-700 rounded" />,
  ssr: false, // skip server render for client-only components
});

4. Server Components — Reduce JavaScript Sent to Browser

Every 'use client' component adds JavaScript to your bundle.

// 🚫 Whole page is client JavaScript
'use client';
export default function Dashboard() {
  const [data, setData] = useState(null);
  // fetches on client, adds to bundle
}

// ✅ Server component — zero client JavaScript
export default async function Dashboard() {
  const data = await db.analytics.findMany();
  // fetches on server, sends only HTML
  return <AnalyticsDisplay data={data} />;
}

// Only make interactive parts client components
'use client';
export function AnalyticsDisplay({ data }) {
  const [view, setView] = useState('chart');
  // minimal client JS
}

Rule: only add 'use client' when you need useState, useEffect, or browser APIs.

5. Suspense and Streaming

Don't let one slow query block the whole page:

import { Suspense } from 'react';

export default function Dashboard() {
  return (
    <div>
      {/* Shows instantly */}
      <DashboardHeader />

      {/* Streams in when ready */}
      <Suspense fallback={<StatsSkeleton />}>
        <SlowStats />  {/* fetches its own data */}
      </Suspense>

      {/* Streams in independently */}
      <Suspense fallback={<ChartSkeleton />}>
        <RevenueChart />  {/* fetches its own data */}
      </Suspense>
    </div>
  );
}

Each Suspense boundary streams independently. User sees content progressively instead of waiting for everything.

6. Metadata and Preloading

// app/layout.tsx
export default function RootLayout({ children }) {
  return (
    <html>
      <head>
        {/* Preconnect to external domains */}
        <link rel="preconnect" href="https://fonts.googleapis.com" />

        {/* DNS prefetch for API domains */}
        <link rel="dns-prefetch" href="https://api.example.com" />

        {/* Preload critical assets */}
        <link
          rel="preload"
          href="/fonts/inter.woff2"
          as="font"
          type="font/woff2"
          crossOrigin="anonymous"
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

Performance Checklist

Run through this before every deployment:

Images:

[ ] All images use next/image
[ ] Above-fold images have priority
[ ] Images compressed to WebP

Fonts:

[ ] Using next/font not external links
[ ] display: 'swap' on all fonts

JavaScript:

[ ] Heavy components use dynamic imports
[ ] Third party libraries imported selectively
[ ] Minimal 'use client' usage

Data fetching:

[ ] Slow queries wrapped in Suspense
[ ] Static data cached appropriately
[ ] No waterfall fetches (fetch in parallel)

Core Web Vitals targets:

LCP under 2.5 seconds
FID under 100ms
CLS under 0.1

Measure First

Don't optimize blindly. Measure first:

# Lighthouse in terminal
npx lighthouse https://yoursite.com --view

# Or use PageSpeed Insights
# https://pagespeed.web.dev/

Fix what Lighthouse flags before anything else. It tells you exactly what's slow and how to fix it.

I applied all these optimizations to my Next.js templates — they all score 95+ on Lighthouse:

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

What's your biggest Next.js performance win? Drop it below 👇

Anas — full-stack Next.js developer. X: @pixelanas

How to Use Prisma with Next.js 15 — Complete Setup Guide

Anas Sheikh — Sun, 26 Jul 2026 10:03:06 +0000

Prisma is the best ORM for Next.js projects.

Type-safe queries, auto-generated types, clean migrations — it makes working with databases feel like working with TypeScript objects.

Here's the complete setup.

Install

npm install prisma @prisma/client
npx prisma init

This creates:

prisma/schema.prisma — your database schema
.env — with DATABASE_URL placeholder

Schema Design

// prisma/schema.prisma
generator client {
  provider = "prisma-client-js"
}

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

model User {
  id        String   @id @default(cuid())
  name      String
  email     String   @unique
  password  String
  role      Role     @default(USER)
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  posts     Post[]
  profile   Profile?

  @@index([email])
}

model Post {
  id          String   @id @default(cuid())
  title       String
  content     String
  published   Boolean  @default(false)
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt

  author      User     @relation(fields: [authorId], references: [id])
  authorId    String

  @@index([authorId])
}

model Profile {
  id     String  @id @default(cuid())
  bio    String?
  avatar String?

  user   User    @relation(fields: [userId], references: [id])
  userId String  @unique
}

enum Role {
  USER
  ADMIN
}

Run Migration

# Create and apply migration
npx prisma migrate dev --name init

# Push schema without migration (good for prototyping)
npx prisma db push

# Open Prisma Studio — visual database browser
npx prisma studio

The Connection Problem in Next.js

Next.js hot reloading creates new Prisma Client instances on every file change. This exhausts your database connections fast.

Fix it with the global singleton pattern:

// lib/db.ts
import { PrismaClient } from '@prisma/client';

const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClient | undefined;
};

export const db =
  globalForPrisma.prisma ??
  new PrismaClient({
    log: process.env.NODE_ENV === 'development'
      ? ['query', 'error', 'warn']
      : ['error'],
  });

if (process.env.NODE_ENV !== 'production') {
  globalForPrisma.prisma = db;
}

Import db from this file everywhere — never create new PrismaClient() directly.

CRUD Operations

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

// CREATE
const user = await db.user.create({
  data: {
    name: 'Anas',
    email: 'anas@example.com',
    password: hashedPassword,
  },
});

// READ one
const user = await db.user.findUnique({
  where: { email: 'anas@example.com' },
  include: { profile: true }, // join profile
});

// READ many with filters
const posts = await db.post.findMany({
  where: {
    published: true,
    authorId: userId,
  },
  orderBy: { createdAt: 'desc' },
  take: 10,   // limit
  skip: 0,    // offset
  select: {   // only fetch what you need
    id: true,
    title: true,
    createdAt: true,
    author: {
      select: { name: true }
    }
  }
});

// UPDATE
const updated = await db.user.update({
  where: { id: userId },
  data: { name: 'New Name' },
});

// DELETE
await db.user.delete({
  where: { id: userId },
});

// UPSERT — create or update
const profile = await db.profile.upsert({
  where: { userId },
  create: { userId, bio: 'New bio' },
  update: { bio: 'Updated bio' },
});

Using in API Routes

// app/api/posts/route.ts
import { NextRequest } from 'next/server';
import { db } from '@/lib/db';
import { z } from 'zod';

const CreatePostSchema = z.object({
  title: z.string().min(3).max(100),
  content: z.string().min(10),
});

export async function GET(request: NextRequest) {
  try {
    const posts = await db.post.findMany({
      where: { published: true },
      orderBy: { createdAt: 'desc' },
      include: {
        author: {
          select: { name: true, email: true }
        }
      }
    });

    return Response.json({ success: true, data: posts });
  } catch (error) {
    return Response.json({ error: 'Failed to fetch posts' }, { status: 500 });
  }
}

export async function POST(request: NextRequest) {
  try {
    const body = await request.json();
    const result = CreatePostSchema.safeParse(body);

    if (!result.success) {
      return Response.json(
        { error: result.error.errors[0].message },
        { status: 400 }
      );
    }

    const post = await db.post.create({
      data: {
        ...result.data,
        authorId: 'user-id-from-auth', // get from session
      },
    });

    return Response.json({ success: true, data: post }, { status: 201 });

  } catch (error: any) {
    // Handle unique constraint violation
    if (error.code === 'P2002') {
      return Response.json({ error: 'Already exists' }, { status: 409 });
    }
    return Response.json({ error: 'Server error' }, { status: 500 });
  }
}

The Prisma error code P2002 is the equivalent of MongoDB's 11000 — unique constraint violation.

Transactions

When multiple operations must succeed or fail together:

// Both operations succeed or both fail
const result = await db.$transaction(async (tx) => {
  // Deduct credits from sender
  const sender = await tx.user.update({
    where: { id: senderId },
    data: { credits: { decrement: amount } },
  });

  if (sender.credits < 0) {
    throw new Error('Insufficient credits');
  }

  // Add credits to receiver
  const receiver = await tx.user.update({
    where: { id: receiverId },
    data: { credits: { increment: amount } },
  });

  return { sender, receiver };
});

If the error is thrown inside the transaction — both updates are rolled back automatically.

Seeding the Database

// prisma/seed.ts
import { PrismaClient } from '@prisma/client';

const db = new PrismaClient();

async function main() {
  // Create admin user
  await db.user.upsert({
    where: { email: 'admin@example.com' },
    update: {},
    create: {
      name: 'Admin',
      email: 'admin@example.com',
      password: 'hashed-password',
      role: 'ADMIN',
    },
  });

  console.log('Database seeded');
}

main()
  .catch(console.error)
  .finally(() => db.$disconnect());

Add to package.json:

"prisma": {
  "seed": "ts-node prisma/seed.ts"
}

Run with: npx prisma db seed

Common Error Codes

Code	Meaning	Fix
`P2002`	Unique constraint failed	Handle duplicate data
`P2025`	Record not found	Check if record exists first
`P2003`	Foreign key constraint	Check related record exists
`P2016`	Query interpretation error	Fix your query syntax

Environment Setup

# .env
# PostgreSQL (recommended for production)
DATABASE_URL="postgresql://user:password@localhost:5432/mydb"

# Or use Supabase (free PostgreSQL hosting)
DATABASE_URL="postgresql://postgres:[password]@db.[project].supabase.co:5432/postgres"

# Or use Neon (free serverless PostgreSQL)
DATABASE_URL="postgresql://user:password@ep-xxx.us-east-1.aws.neon.tech/neondb?sslmode=require"

Prisma takes 30 minutes to set up and saves hundreds of hours of manual SQL and type casting.

I use it in all my production Next.js projects.

My templates: https://pixelanas.gumroad.com

What ORM do you use with Next.js? Drop it below 👇

Anas — full-stack Next.js developer. X: @pixelanas

Stop Manually Validating API Input — Use Zod in Next.js

Anas Sheikh — Sat, 25 Jul 2026 07:51:08 +0000

Every production Next.js app needs input validation.

Most developers do it manually:

if (!body.email) return error('Email required');
if (!body.email.includes('@')) return error('Invalid email');
if (!body.password) return error('Password required');
if (body.password.length < 8) return error('Password too short');

This is error-prone, verbose, and gives you no TypeScript types.

Zod fixes all of this.

Install

npm install zod

Basic Schema

import { z } from 'zod';

const UserSchema = z.object({
  name: z.string().min(2, 'Name too short').max(50),
  email: z.string().email('Invalid email'),
  age: z.number().min(18, 'Must be 18+').optional(),
  role: z.enum(['admin', 'user']).default('user'),
});

// TypeScript type — automatically inferred
type User = z.infer<typeof UserSchema>;
// { name: string; email: string; age?: number; role: 'admin' | 'user' }

You get runtime validation AND TypeScript types from the same definition.

Using in API Routes

// app/api/users/route.ts
import { NextRequest } from 'next/server';
import { z } from 'zod';

const CreateUserSchema = z.object({
  name: z.string().min(2, 'Name must be at least 2 characters'),
  email: z.string().email('Please enter a valid email'),
  password: z.string()
    .min(8, 'Password must be at least 8 characters')
    .regex(/[A-Z]/, 'Password must contain at least one uppercase letter')
    .regex(/[0-9]/, 'Password must contain at least one number'),
});

export async function POST(request: NextRequest) {
  const body = await request.json();

  // safeParse never throws — returns result object
  const result = CreateUserSchema.safeParse(body);

  if (!result.success) {
    return Response.json(
      {
        error: 'Validation failed',
        // First error message — clean for users
        message: result.error.errors[0].message,
        // All errors — useful for forms
        errors: result.error.flatten().fieldErrors,
      },
      { status: 400 }
    );
  }

  // result.data is fully typed here
  const { name, email, password } = result.data;

  // Save to database...
  return Response.json({ success: true });
}

Using in Server Actions

// actions/auth.ts
'use server';
import { z } from 'zod';

const LoginSchema = z.object({
  email: z.string().email('Invalid email'),
  password: z.string().min(1, 'Password is required'),
});

export async function login(
  prevState: { error: string } | null,
  formData: FormData
) {
  const result = LoginSchema.safeParse({
    email: formData.get('email'),
    password: formData.get('password'),
  });

  if (!result.success) {
    return { error: result.error.errors[0].message };
  }

  const { email, password } = result.data;
  // authenticate user...
}

Common Zod Patterns

String Validations

z.string()                          // any string
z.string().min(3)                   // minimum length
z.string().max(100)                 // maximum length
z.string().email()                  // valid email
z.string().url()                    // valid URL
z.string().uuid()                   // valid UUID
z.string().regex(/^\d{4}$/)        // matches pattern
z.string().trim()                   // trim whitespace
z.string().toLowerCase()            // convert to lowercase
z.string().optional()               // can be undefined
z.string().nullable()               // can be null
z.string().default('guest')         // default value

Number Validations

z.number().min(0)                   // minimum value
z.number().max(100)                 // maximum value
z.number().int()                    // must be integer
z.number().positive()               // must be > 0
z.number().nonnegative()            // must be >= 0
z.coerce.number()                   // convert string "42" to number 42

Object Patterns

// Partial — all fields optional
const UpdateUserSchema = UserSchema.partial();

// Pick — only specific fields
const LoginSchema = UserSchema.pick({ email: true, password: true });

// Omit — exclude specific fields
const PublicUserSchema = UserSchema.omit({ password: true });

// Extend — add fields to existing schema
const AdminSchema = UserSchema.extend({
  permissions: z.array(z.string()),
});

Validating Query Params

// app/api/posts/route.ts
const QuerySchema = z.object({
  page: z.coerce.number().min(1).default(1),
  limit: z.coerce.number().min(1).max(100).default(10),
  search: z.string().optional(),
  status: z.enum(['draft', 'published', 'all']).default('all'),
});

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);

  const result = QuerySchema.safeParse({
    page: searchParams.get('page'),
    limit: searchParams.get('limit'),
    search: searchParams.get('search'),
    status: searchParams.get('status'),
  });

  if (!result.success) {
    return Response.json({ error: 'Invalid query params' }, { status: 400 });
  }

  const { page, limit, search, status } = result.data;
  // all values are typed and validated
}

The z.coerce.number() is key — URL params are always strings, coerce converts them to numbers automatically.

Validating Environment Variables

// lib/env.ts
import { z } from 'zod';

const EnvSchema = z.object({
  MONGODB_URI: z.string().url('Invalid MongoDB URI'),
  JWT_SECRET: z.string().min(32, 'JWT secret must be at least 32 characters'),
  NODE_ENV: z.enum(['development', 'test', 'production']).default('development'),
  PORT: z.coerce.number().default(3000),
});

// Validate at startup — crashes immediately if env vars are missing
const result = EnvSchema.safeParse(process.env);

if (!result.success) {
  console.error('Invalid environment variables:');
  console.error(result.error.flatten().fieldErrors);
  process.exit(1); // crash immediately with helpful error
}

export const env = result.data;

Usage anywhere:

import { env } from '@/lib/env';
// env.MONGODB_URI is typed as string
// env.PORT is typed as number

Form Error Display

'use client';
import { useActionState } from 'react';
import { submitForm } from '@/actions/form';

export function ContactForm() {
  const [state, action] = useActionState(submitForm, null);

  return (
    <form action={action}>
      <div>
        <input name="email" type="email" />
        {state?.errors?.email && (
          <p className="text-red-400 text-sm mt-1">
            {state.errors.email[0]}
          </p>
        )}
      </div>
      <button type="submit">Send</button>
    </form>
  );
}

Summary

Without Zod	With Zod
Manual if/else checks	One schema definition
No TypeScript types	Types auto-inferred
Inconsistent error messages	Consistent validation messages
Runtime crashes	Caught at validation
Repeated code	Reusable schemas

Zod is one of those libraries where once you use it, you can't imagine going back.

I use it in every Next.js project and all my templates:

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

What validation library do you use? Drop it below 👇

Anas — full-stack Next.js developer. X: @pixelanas

Next.js 15 Caching Explained — Finally Makes Sense

Anas Sheikh — Fri, 24 Jul 2026 13:51:13 +0000

Next.js caching confused me for months.

The docs are thorough but overwhelming. Nobody explains the simple mental model.

Here it is.

The Simple Mental Model

Next.js has one question for every data fetch:

"How fresh does this data need to be?"

Old data is fine → cache it
Always needs to be live → skip cache
Refresh every X seconds → revalidate on timer
Refresh when something changes → revalidate on demand

Everything else follows from this.

1. Default — Cached Forever

// Cached on first request — never fetches again
const data = await fetch('https://api.example.com/posts');

Use this for data that never changes — like static content, documentation, or marketing copy.

2. Never Cache — Always Fresh

// Fresh data on every request
const data = await fetch('https://api.example.com/orders', {
  cache: 'no-store'
});

Use this for data that must be real-time — user dashboards, live prices, notifications.

3. Revalidate on a Timer

// Refetch every 60 seconds
const data = await fetch('https://api.example.com/products', {
  next: { revalidate: 60 }
});

Use this for data that changes occasionally — blog posts, product listings, leaderboards.

Good revalidation times:

News feed → 60 seconds
Product catalog → 300 seconds (5 mins)
Blog posts → 3600 seconds (1 hour)

4. Revalidate on Demand

The most powerful pattern — refresh cache exactly when data changes:

// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from 'next/cache';
import { NextRequest } from 'next/server';

export async function POST(request: NextRequest) {
  const { path, tag, secret } = await request.json();

  // Protect with secret key
  if (secret !== process.env.REVALIDATION_SECRET) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  if (path) revalidatePath(path);    // revalidate a specific page
  if (tag) revalidateTag(tag);       // revalidate tagged fetches

  return Response.json({ revalidated: true });
}

Call this API from your CMS, database webhook, or admin panel when content changes.

Tags — The Missing Piece

Tags let you group related fetches and invalidate them together:

// Tag your fetches
const posts = await fetch('https://api.example.com/posts', {
  next: { tags: ['posts'] }
});

const post = await fetch(`https://api.example.com/posts/${id}`, {
  next: { tags: ['posts', `post-${id}`] }
});

Now when a post is updated — invalidate just the affected tags:

import { revalidateTag } from 'next/cache';

// In your Server Action when post is updated
export async function updatePost(id: string, data: PostData) {
  await db.posts.update({ where: { id }, data });

  revalidateTag(`post-${id}`);  // invalidate this specific post
  revalidateTag('posts');        // invalidate the posts list
}

Real Example — Blog with On-Demand Revalidation

// app/blog/page.tsx
async function BlogPage() {
  // Cache for 1 hour, tag as 'posts'
  const posts = await fetch('https://api.example.com/posts', {
    next: { 
      revalidate: 3600,
      tags: ['posts']
    }
  }).then(r => r.json());

  return (
    <div>
      {posts.map(post => (
        <article key={post.id}>
          <h2>{post.title}</h2>
        </article>
      ))}
    </div>
  );
}

// app/blog/[slug]/page.tsx
async function BlogPost({ params }) {
  const { slug } = await params;

  // Tag with specific post ID
  const post = await fetch(`https://api.example.com/posts/${slug}`, {
    next: { 
      revalidate: 3600,
      tags: ['posts', `post-${slug}`]
    }
  }).then(r => r.json());

  return <article>{post.content}</article>;
}

// Server Action — called when admin publishes/edits post
export async function publishPost(slug: string) {
  'use server';

  await db.posts.update({ 
    where: { slug }, 
    data: { published: true } 
  });

  // Instantly refresh affected pages
  revalidateTag(`post-${slug}`);
  revalidateTag('posts');
}

When admin clicks "Publish" — both the post page and the blog listing update instantly. No waiting for the timer.

Caching with Database Queries

The same patterns work with direct database calls using unstable_cache:

import { unstable_cache } from 'next/cache';

// Cache database query for 5 minutes
const getCachedPosts = unstable_cache(
  async () => {
    return db.posts.findMany({ 
      where: { published: true },
      orderBy: { createdAt: 'desc' }
    });
  },
  ['posts'],           // cache key
  { 
    revalidate: 300,   // 5 minutes
    tags: ['posts']    // for on-demand invalidation
  }
);

// Use in server component
const posts = await getCachedPosts();

Quick Reference

Pattern	Code	Use when
Cache forever	`fetch(url)`	Static content
Never cache	`cache: 'no-store'`	Real-time data
Timer revalidate	`next: { revalidate: 60 }`	Mostly static
Tag revalidate	`next: { tags: ['x'] }`	CMS content
Path revalidate	`revalidatePath('/page')`	After mutation
Tag invalidate	`revalidateTag('x')`	After mutation

Once this clicked for me I stopped over-fetching and under-caching. My Next.js apps became significantly faster with almost no extra code.

I use these patterns in all my Next.js templates:

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

What's your caching strategy? Drop it below 👇

Anas — full-stack Next.js developer. X: @pixelanas

Node.js for Frontend Developers — What Nobody Explains

Anas Sheikh — Thu, 23 Jul 2026 11:33:08 +0000

I spent 4 years as a frontend developer before learning Node.js.

Everything confused me at first.

Not because it's hard — but because nobody explains how it connects to what you already know.

Here's what I wish someone had told me.

The Event Loop — Finally Explained Simply

Frontend developers know JavaScript is single-threaded. But how does Node.js handle thousands of requests at the same time?

console.log('1 - Start');

setTimeout(() => {
  console.log('3 - Timeout');
}, 0);

Promise.resolve().then(() => {
  console.log('2 - Promise');
});

console.log('4 - End');

// Output:
// 1 - Start
// 4 - End
// 2 - Promise
// 3 - Timeout

The order: synchronous code first → microtasks (promises) → macrotasks (setTimeout)

Node.js doesn't wait for slow operations. It hands them off and keeps processing. When they finish, it comes back and handles the result.

This is why Node.js can handle thousands of concurrent requests without multiple threads.

require vs import

Coming from frontend you're used to ES modules:

// Frontend (ES Modules)
import express from 'express';
import { readFile } from 'fs/promises';

// Old Node.js (CommonJS)
const express = require('express');
const { readFile } = require('fs/promises');

In modern Node.js projects — add "type": "module" to your package.json and use ES module syntax everywhere. Or use TypeScript which handles this automatically.

The Middleware Pattern

This confused me the most coming from React.

Middleware is just a function that runs between a request and response:

import express from 'express';
const app = express();

// Middleware 1 — runs for every request
app.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next(); // pass to next middleware
});

// Middleware 2 — parse JSON bodies
app.use(express.json());

// Middleware 3 — auth check
function requireAuth(req, res, next) {
  const token = req.headers.authorization;
  if (!token) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  next();
}

// Route — only runs if all middleware passed
app.get('/dashboard', requireAuth, (req, res) => {
  res.json({ message: 'Welcome to dashboard' });
});

Think of middleware as a chain. Each function either:

Calls next() to pass to the next one
Sends a response to stop the chain

Same concept as Next.js middleware — just lower level.

Environment Variables

Never hardcode secrets. Ever.

// 🚫 Never do this
const db = mongoose.connect('mongodb+srv://user:password123@cluster.mongodb.net/mydb');

// ✅ Always use environment variables
import 'dotenv/config'; // npm install dotenv
const db = mongoose.connect(process.env.MONGODB_URI);

Create a .env file:

MONGODB_URI=mongodb+srv://user:password@cluster.mongodb.net/mydb
JWT_SECRET=your-secret-key-here
PORT=3000

Add .env to .gitignore immediately:

# .gitignore
.env
.env.local
node_modules/

If you accidentally commit a secret — rotate it immediately. GitHub scans for exposed keys.

Async Error Handling

The most common Node.js bug for beginners:

// 🚫 Unhandled promise rejection — crashes your server
app.get('/users', async (req, res) => {
  const users = await db.find(); // if this throws — server crashes
  res.json(users);
});

// ✅ Always wrap async routes in try/catch
app.get('/users', async (req, res) => {
  try {
    const users = await db.find();
    res.json(users);
  } catch (error) {
    console.error(error);
    res.status(500).json({ error: 'Server error' });
  }
});

// ✅ Or create a wrapper function
function asyncHandler(fn) {
  return (req, res, next) => {
    Promise.resolve(fn(req, res, next)).catch(next);
  };
}

app.get('/users', asyncHandler(async (req, res) => {
  const users = await db.find();
  res.json(users);
}));

The asyncHandler wrapper catches all errors and passes them to Express's error handler automatically.

Reading and Writing Files

import { readFile, writeFile, readdir } from 'fs/promises';
import path from 'path';
import { fileURLToPath } from 'url';

// Get current directory (ESM equivalent of __dirname)
const __dirname = path.dirname(fileURLToPath(import.meta.url));

// Read a file
const content = await readFile(
  path.join(__dirname, 'data.json'),
  'utf-8'
);
const data = JSON.parse(content);

// Write a file
await writeFile(
  path.join(__dirname, 'output.json'),
  JSON.stringify(data, null, 2)
);

// List directory contents
const files = await readdir(path.join(__dirname, 'posts'));

The path.join(__dirname, ...) pattern ensures your paths work on Windows and Mac/Linux.

A Complete Mini API

Putting it all together — a simple REST API:

// server.js
import express from 'express';
import 'dotenv/config';

const app = express();
const PORT = process.env.PORT || 3000;

// Middleware
app.use(express.json());
app.use((req, res, next) => {
  console.log(`${new Date().toISOString()} ${req.method} ${req.path}`);
  next();
});

// In-memory data (replace with database)
let users = [
  { id: 1, name: 'Anas', email: 'anas@example.com' }
];

// Routes
app.get('/api/users', (req, res) => {
  res.json({ success: true, data: users });
});

app.post('/api/users', (req, res) => {
  const { name, email } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: 'Name and email required' });
  }

  const user = { id: Date.now(), name, email };
  users.push(user);
  res.status(201).json({ success: true, data: user });
});

app.delete('/api/users/:id', (req, res) => {
  const id = parseInt(req.params.id);
  users = users.filter(u => u.id !== id);
  res.json({ success: true });
});

// Error handler
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: 'Something went wrong' });
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Key Differences From Frontend JavaScript

Frontend	Node.js
`window`, `document`	Not available
`fetch` API	Built-in from Node 18+
`localStorage`	Use files or database
ES Modules by default	CommonJS by default (add `"type":"module"` to change)
Runs in browser	Runs on server
Single user context	Many users simultaneously

Once Node.js clicked for me I could build full-stack apps without switching languages. It's worth the learning curve.

I use Node.js for all my backend work in my Next.js templates:

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

What confused you most about Node.js? Drop it below 👇

Anas — full-stack developer specializing in Next.js and Node.js. X: @pixelanas

6 React Mistakes That Waste Hours — And How to Fix Them

Anas Sheikh — Wed, 22 Jul 2026 09:25:54 +0000

I've reviewed a lot of React codebases.

The same mistakes appear every time.

Here are the 6 that waste the most time — and exactly how to fix them.

1. useEffect With Missing Dependencies

// 🚫 Bug — userId changes but effect never re-runs
useEffect(() => {
  fetchUserData(userId);
}, []); // missing userId

// ✅ Correct
useEffect(() => {
  fetchUserData(userId);
}, [userId]); // re-runs when userId changes

React's ESLint plugin catches this — install eslint-plugin-react-hooks and enable it. Never ignore the dependency array warning.

2. Creating Objects and Arrays Inside JSX

// 🚫 New object created on every render
// This causes child component to re-render every time
function Parent() {
  return (
    <Child 
      style={{ color: 'red' }}  // new object every render
      items={['a', 'b', 'c']}   // new array every render
    />
  );
}

// ✅ Move constants outside component
const CHILD_STYLE = { color: 'red' };
const ITEMS = ['a', 'b', 'c'];

function Parent() {
  return <Child style={CHILD_STYLE} items={ITEMS} />;
}

If the value never changes — move it outside the component. If it depends on props or state — use useMemo.

3. Fetching Data in useEffect

// 🚫 Client-side fetching when you don't need to
'use client';
function UserList() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch('/api/users')
      .then(r => r.json())
      .then(setUsers);
  }, []);

  return <div>{users.map(u => <div key={u.id}>{u.name}</div>)}</div>;
}

// ✅ Fetch on server — faster, no loading flash, better SEO
async function UserList() {
  const users = await fetch('/api/users').then(r => r.json());
  return <div>{users.map(u => <div key={u.id}>{u.name}</div>)}</div>;
}

In Next.js — if data doesn't depend on user interaction, fetch it in a server component. Instant render, no loading state needed.

4. Not Using Key Prop Correctly

// 🚫 Using index as key — causes bugs with reordering
{items.map((item, index) => (
  <Item key={index} data={item} />
))}

// 🚫 No key at all
{items.map((item) => (
  <Item data={item} />
))}

// ✅ Use stable unique ID
{items.map((item) => (
  <Item key={item.id} data={item} />
))}

Using index as key causes React to reuse the wrong DOM elements when items are added, removed, or reordered. Always use a stable unique ID.

5. Unnecessary useState for Derived Values

// 🚫 Keeping derived state in useState
function Cart({ items }) {
  const [total, setTotal] = useState(0);

  useEffect(() => {
    setTotal(items.reduce((sum, item) => sum + item.price, 0));
  }, [items]);

  return <div>Total: ${total}</div>;
}

// ✅ Calculate directly — no state needed
function Cart({ items }) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  return <div>Total: ${total}</div>;
}

// ✅ If expensive calculation — use useMemo
function Cart({ items }) {
  const total = useMemo(
    () => items.reduce((sum, item) => sum + item.price, 0),
    [items]
  );
  return <div>Total: ${total}</div>;
}

If you can calculate a value from existing props or state — don't put it in useState. It creates an extra render cycle and makes your code harder to follow.

6. Giant Components That Do Everything

// 🚫 One component doing too much
function Dashboard() {
  const [users, setUsers] = useState([]);
  const [stats, setStats] = useState({});
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
  const [selectedUser, setSelectedUser] = useState(null);
  const [modalOpen, setModalOpen] = useState(false);
  // ...50 more lines of state

  return (
    // ...200 lines of JSX
  );
}

// ✅ Split by responsibility
function Dashboard() {
  return (
    <div>
      <StatsOverview />
      <UserTable />
      <RecentActivity />
    </div>
  );
}

// Each component manages its own state and data
function UserTable() {
  const [selectedUser, setSelectedUser] = useState(null);
  // only user table logic here
}

Rule of thumb: if a component has more than 3 useState calls or more than 100 lines — it probably needs to be split.

Summary

Mistake	Fix
Missing useEffect deps	Add all dependencies, use ESLint plugin
Objects/arrays in JSX	Move outside component or use useMemo
Fetching in useEffect	Use server components in Next.js
Index as key	Always use stable unique IDs
Derived state in useState	Calculate directly or use useMemo
Giant components	Split by single responsibility

These are the most common bugs I see in React codebases. Fix them and your code will be faster and easier to maintain.

I apply all these patterns in my Next.js templates:

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

What React mistake cost you the most time? Drop it below 👇

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

TypeScript Patterns I Use in Every Next.js Project

Anas Sheikh — Tue, 21 Jul 2026 09:17:24 +0000

Most TypeScript tutorials teach you the basics.

Nobody shows you the patterns that actually matter in a real Next.js production app.

Here are the ones I use every single project.

1. Type Your API Responses

Stop using any for API responses. Create proper types:

// types/api.ts
export interface ApiResponse<T> {
  success: boolean;
  data?: T;
  error?: string;
}

export interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'user';
  createdAt: string;
}

export interface PaginatedResponse<T> {
  data: T[];
  total: number;
  page: number;
  limit: number;
  hasMore: boolean;
}

Usage in API route:

// app/api/users/route.ts
import { ApiResponse, User } from '@/types/api';

export async function GET(): Promise<Response> {
  const users = await db.users.findMany();

  const response: ApiResponse<User[]> = {
    success: true,
    data: users,
  };

  return Response.json(response);
}

Now your frontend knows exactly what shape the data is.

2. Component Props Pattern

Always define prop types explicitly:

// ❌ Avoid — no type safety
export function UserCard({ user, onDelete, showActions }) {
  return <div>{user.name}</div>;
}

// ✅ Correct — explicit interface
interface UserCardProps {
  user: {
    id: string;
    name: string;
    email: string;
    avatar?: string; // optional with ?
  };
  onDelete: (id: string) => void;
  showActions?: boolean; // optional prop
  className?: string;
}

export function UserCard({
  user,
  onDelete,
  showActions = true, // default value
  className,
}: UserCardProps) {
  return (
    <div className={className}>
      <p>{user.name}</p>
      {showActions && (
        <button onClick={() => onDelete(user.id)}>Delete</button>
      )}
    </div>
  );
}

3. Typing Server Actions

Server Actions need proper typing for form data and return values:

// types/actions.ts
export interface ActionState {
  success: boolean;
  message: string;
  errors?: Record<string, string[]>;
}

// actions/contact.ts
'use server';
import { ActionState } from '@/types/actions';

export async function submitContact(
  prevState: ActionState | null,
  formData: FormData
): Promise<ActionState> {

  const name = formData.get('name') as string;
  const email = formData.get('email') as string;

  if (!name) {
    return {
      success: false,
      message: 'Validation failed',
      errors: { name: ['Name is required'] }
    };
  }

  try {
    await db.contacts.create({ data: { name, email } });
    return { success: true, message: 'Message sent!' };
  } catch {
    return { success: false, message: 'Server error' };
  }
}

4. Typing Next.js Page Props

Pages in Next.js App Router have specific prop types:

// app/blog/[slug]/page.tsx
interface PageProps {
  params: Promise<{ slug: string }>;
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
}

export default async function BlogPost({ params, searchParams }: PageProps) {
  const { slug } = await params;
  const { page } = await searchParams;

  const post = await getPost(slug);

  return <article>{post.content}</article>;
}

// Generate static params
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Note: In Next.js 15, params and searchParams are now Promises — always await them.

5. Utility Types You Actually Need

// types/utils.ts

// Make all properties optional
type PartialUser = Partial<User>;

// Make all properties required
type RequiredUser = Required<User>;

// Pick only specific properties
type UserPreview = Pick<User, 'id' | 'name' | 'avatar'>;

// Omit specific properties
type UserWithoutPassword = Omit<User, 'password'>;

// Make specific properties optional
type UpdateUserInput = Partial<Pick<User, 'name' | 'email' | 'avatar'>>;

Real usage:

// When creating a user — id and createdAt are auto-generated
type CreateUserInput = Omit<User, 'id' | 'createdAt'>;

// When updating — everything is optional except id
type UpdateUserInput = { id: string } & Partial<Omit<User, 'id'>>;

6. Environment Variables Type Safety

// lib/env.ts
const requiredEnvVars = [
  'MONGODB_URI',
  'JWT_SECRET',
  'NEXTAUTH_SECRET',
] as const;

type EnvVar = typeof requiredEnvVars[number];

function getEnv(key: EnvVar): string {
  const value = process.env[key];
  if (!value) {
    throw new Error(`Missing required environment variable: ${key}`);
  }
  return value;
}

export const env = {
  mongodbUri: getEnv('MONGODB_URI'),
  jwtSecret: getEnv('JWT_SECRET'),
  nextAuthSecret: getEnv('NEXTAUTH_SECRET'),
};

Now instead of process.env.MONGODB_URI! everywhere — import from env and get type safety plus runtime validation.

7. Generic Fetch Hook

// hooks/useFetch.ts
import { useState, useEffect } from 'react';

interface FetchState<T> {
  data: T | null;
  loading: boolean;
  error: string | null;
}

export function useFetch<T>(url: string): FetchState<T> {
  const [state, setState] = useState<FetchState<T>>({
    data: null,
    loading: true,
    error: null,
  });

  useEffect(() => {
    let cancelled = false;

    async function fetchData() {
      try {
        const res = await fetch(url);
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        const data: T = await res.json();
        if (!cancelled) setState({ data, loading: false, error: null });
      } catch (err) {
        if (!cancelled) {
          setState({ data: null, loading: false, error: String(err) });
        }
      }
    }

    fetchData();
    return () => { cancelled = true; };
  }, [url]);

  return state;
}

Usage:

const { data, loading, error } = useFetch<User[]>('/api/users');

The cancelled flag prevents state updates on unmounted components — a common memory leak.

Summary

Pattern	Why
Type API responses	No more `any` — catch errors at compile time
Explicit component props	Self-documenting, refactor-safe components
Typed Server Actions	Know exactly what your actions return
Page prop types	Next.js 15 requires awaiting params
Utility types	Reuse types without duplication
Typed env vars	Crash at startup not at runtime
Generic hooks	Reusable data fetching with full type safety

TypeScript feels slow at first. After a month you'll never go back.

I use all these patterns in my Next.js templates:

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

What TypeScript pattern saved you the most time? Drop it below 👇

Anas — full-stack Next.js developer. X: @pixelanas

Next.js Server Actions — Stop Writing API Routes for Forms

Anas Sheikh — Mon, 20 Jul 2026 07:51:48 +0000

I used to write an API route for every form submission.

Server Actions changed everything.

Here's how I use them in every Next.js 15 project now.

What Are Server Actions

Server Actions are async functions that run on the server — called directly from your components. No API route needed.

// Before Server Actions
async function handleSubmit(e) {
  e.preventDefault();
  const res = await fetch('/api/contact', {
    method: 'POST',
    body: JSON.stringify({ name, email, message })
  });
  const data = await res.json();
}

// With Server Actions
async function submitContact(formData: FormData) {
  'use server';
  const name = formData.get('name');
  const email = formData.get('email');
  // directly save to database
  await db.contacts.create({ name, email });
}

The 'use server' directive tells Next.js this function runs on the server even when called from a client component.

1. Basic Form with Server Action

// app/contact/page.tsx
export default function ContactPage() {
  async function submitForm(formData: FormData) {
    'use server';

    const name = formData.get('name') as string;
    const email = formData.get('email') as string;
    const message = formData.get('message') as string;

    // Validate
    if (!name || !email || !message) {
      throw new Error('All fields required');
    }

    // Save to database directly
    await db.messages.create({ data: { name, email, message } });
  }

  return (
    <form action={submitForm}>
      <input name="name" placeholder="Your name" required />
      <input name="email" type="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <button type="submit">Send Message</button>
    </form>
  );
}

No useState. No fetch. No API route. Just a function.

2. With Loading and Error States

'use client';
import { useActionState } from 'react';

async function submitForm(prevState: any, formData: FormData) {
  'use server';

  try {
    const email = formData.get('email') as string;
    await db.subscribers.create({ data: { email } });
    return { success: true, message: 'Subscribed successfully!' };
  } catch (error) {
    return { success: false, message: 'Something went wrong.' };
  }
}

export function SubscribeForm() {
  const [state, action, isPending] = useActionState(submitForm, null);

  return (
    <form action={action}>
      <input name="email" type="email" placeholder="Enter email" />

      <button type="submit" disabled={isPending}>
        {isPending ? 'Subscribing...' : 'Subscribe'}
      </button>

      {state?.message && (
        <p className={state.success ? 'text-green-400' : 'text-red-400'}>
          {state.message}
        </p>
      )}
    </form>
  );
}

useActionState gives you pending state and the previous result automatically.

3. Revalidating Data After Mutation

After updating data you need to refresh the UI. Use revalidatePath:

// actions/posts.ts
'use server';
import { revalidatePath } from 'next/cache';

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string;
  const content = formData.get('content') as string;

  await db.posts.create({ data: { title, content } });

  // Refresh the posts page so new post appears
  revalidatePath('/dashboard/posts');
}

export async function deletePost(id: string) {
  await db.posts.delete({ where: { id } });
  revalidatePath('/dashboard/posts');
}

Usage in component:

import { deletePost } from '@/actions/posts';

export function PostCard({ post }) {
  return (
    <div>
      <h3>{post.title}</h3>
      {/* Pass server action directly to form action */}
      <form action={deletePost.bind(null, post.id)}>
        <button type="submit">Delete</button>
      </form>
    </div>
  );
}

4. Redirect After Action

'use server';
import { redirect } from 'next/navigation';

export async function login(formData: FormData) {
  const email = formData.get('email') as string;
  const password = formData.get('password') as string;

  const user = await verifyCredentials(email, password);

  if (!user) {
    return { error: 'Invalid credentials' };
  }

  // Set cookie
  cookies().set('auth-token', generateToken(user.id), {
    httpOnly: true,
    secure: true,
    maxAge: 60 * 60 * 24 * 7,
  });

  // Redirect to dashboard
  redirect('/dashboard');
}

5. Separate Actions File (Best Practice)

Don't put all your actions inside components. Create a dedicated file:

// actions/users.ts
'use server';

import { connectDB } from '@/lib/db';
import { revalidatePath } from 'next/cache';
import User from '@/models/User';

export async function updateProfile(formData: FormData) {
  await connectDB();

  const name = formData.get('name') as string;
  const userId = formData.get('userId') as string;

  await User.findByIdAndUpdate(userId, { name });
  revalidatePath('/dashboard/settings');
}

export async function deleteAccount(userId: string) {
  await connectDB();
  await User.findByIdAndDelete(userId);
  redirect('/');
}

Import and use anywhere:

import { updateProfile } from '@/actions/users';

export function ProfileForm({ user }) {
  return (
    <form action={updateProfile}>
      <input type="hidden" name="userId" value={user.id} />
      <input name="name" defaultValue={user.name} />
      <button type="submit">Save Changes</button>
    </form>
  );
}

When to Still Use API Routes

Server Actions are not always the answer:

Use Server Actions	Use API Routes
Form submissions	Third party webhooks
CRUD operations	Mobile app backend
Page mutations	Public API
Auth flows	File uploads

If an external service needs to call your endpoint — use an API route. If it's your own Next.js app talking to itself — use Server Actions.

Summary

Old way:  Component → fetch → API Route → Database
New way:  Component → Server Action → Database

Less code. Faster development. Same result.

I use Server Actions in all my Next.js templates for contact forms, auth flows, and dashboard mutations.

See them in action:

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

What do you use — Server Actions or API Routes? Drop it below 👇

Anas — full-stack Next.js developer. X: @pixelanas

Build Authentication in Next.js 15 From Scratch — No Libraries

Anas Sheikh — Sun, 19 Jul 2026 08:16:02 +0000

Everyone reaches for NextAuth immediately.

But if you want to understand how authentication actually works — build it yourself first.

Here's complete JWT authentication in Next.js 15 with no libraries except jsonwebtoken and bcryptjs.

What We're Building

User registration with hashed passwords
Login with JWT token
Protected API routes
Middleware to protect pages
Token refresh

1. Install Dependencies

npm install jsonwebtoken bcryptjs
npm install -D @types/jsonwebtoken @types/bcryptjs

That's it. No NextAuth. No Auth.js. Just two battle-tested libraries.

2. Environment Variables

# .env.local
JWT_SECRET=your-super-secret-key-minimum-32-characters
MONGODB_URI=your-mongodb-connection-string

3. Auth Utilities

// lib/auth.ts
import jwt from 'jsonwebtoken';
import bcrypt from 'bcryptjs';

const JWT_SECRET = process.env.JWT_SECRET!;

// Hash password before saving
export async function hashPassword(password: string): Promise<string> {
  return bcrypt.hash(password, 12);
}

// Compare password with hash
export async function verifyPassword(
  password: string,
  hash: string
): Promise<boolean> {
  return bcrypt.compare(password, hash);
}

// Generate JWT token
export function generateToken(userId: string): string {
  return jwt.sign(
    { userId },
    JWT_SECRET,
    { expiresIn: '7d' }
  );
}

// Verify JWT token
export function verifyToken(token: string): { userId: string } | null {
  try {
    return jwt.verify(token, JWT_SECRET) as { userId: string };
  } catch {
    return null;
  }
}

4. User Model

// models/User.ts
import mongoose, { Document, Model } from 'mongoose';

export interface IUser extends Document {
  name: string;
  email: string;
  password: string;
  createdAt: Date;
}

const UserSchema = new mongoose.Schema<IUser>(
  {
    name: { type: String, required: true, trim: true },
    email: { type: String, required: true, unique: true, lowercase: true },
    password: { type: String, required: true, minlength: 8 },
  },
  { timestamps: true }
);

const User: Model<IUser> =
  mongoose.models.User || mongoose.model<IUser>('User', UserSchema);

export default User;

5. Register API Route

// app/api/auth/register/route.ts
import { NextRequest } from 'next/server';
import { connectDB } from '@/lib/db';
import { hashPassword, generateToken } from '@/lib/auth';
import User from '@/models/User';
import { z } from 'zod';

const RegisterSchema = z.object({
  name: z.string().min(2, 'Name too short'),
  email: z.string().email('Invalid email'),
  password: z.string().min(8, 'Password must be 8+ characters'),
});

export async function POST(request: NextRequest) {
  try {
    await connectDB();

    const body = await request.json();
    const result = RegisterSchema.safeParse(body);

    if (!result.success) {
      return Response.json(
        { error: result.error.errors[0].message },
        { status: 400 }
      );
    }

    const { name, email, password } = result.data;

    // Check if user exists
    const existingUser = await User.findOne({ email });
    if (existingUser) {
      return Response.json(
        { error: 'Email already registered' },
        { status: 409 }
      );
    }

    // Hash password and create user
    const hashedPassword = await hashPassword(password);
    const user = await User.create({ name, email, password: hashedPassword });

    // Generate token
    const token = generateToken(user._id.toString());

    return Response.json(
      {
        success: true,
        token,
        user: { id: user._id, name: user.name, email: user.email },
      },
      { status: 201 }
    );

  } catch (error) {
    return Response.json({ error: 'Server error' }, { status: 500 });
  }
}

6. Login API Route

// app/api/auth/login/route.ts
import { NextRequest } from 'next/server';
import { connectDB } from '@/lib/db';
import { verifyPassword, generateToken } from '@/lib/auth';
import User from '@/models/User';

export async function POST(request: NextRequest) {
  try {
    await connectDB();

    const { email, password } = await request.json();

    if (!email || !password) {
      return Response.json(
        { error: 'Email and password required' },
        { status: 400 }
      );
    }

    // Find user — include password field (excluded by default)
    const user = await User.findOne({ email }).select('+password');

    if (!user) {
      return Response.json(
        { error: 'Invalid credentials' },
        { status: 401 }
      );
    }

    // Verify password
    const isValid = await verifyPassword(password, user.password);
    if (!isValid) {
      return Response.json(
        { error: 'Invalid credentials' },
        { status: 401 }
      );
    }

    const token = generateToken(user._id.toString());

    return Response.json({
      success: true,
      token,
      user: { id: user._id, name: user.name, email: user.email },
    });

  } catch (error) {
    return Response.json({ error: 'Server error' }, { status: 500 });
  }
}

Note: always return the same error message for wrong email OR wrong password. Never tell the user which one is wrong.

7. Protected API Route

// app/api/profile/route.ts
import { NextRequest } from 'next/server';
import { verifyToken } from '@/lib/auth';
import { connectDB } from '@/lib/db';
import User from '@/models/User';

export async function GET(request: NextRequest) {
  // Get token from header
  const authHeader = request.headers.get('authorization');
  const token = authHeader?.replace('Bearer ', '');

  if (!token) {
    return Response.json({ error: 'No token provided' }, { status: 401 });
  }

  // Verify token
  const payload = verifyToken(token);
  if (!payload) {
    return Response.json({ error: 'Invalid token' }, { status: 401 });
  }

  try {
    await connectDB();
    const user = await User.findById(payload.userId).select('-password');

    if (!user) {
      return Response.json({ error: 'User not found' }, { status: 404 });
    }

    return Response.json({ success: true, user });

  } catch (error) {
    return Response.json({ error: 'Server error' }, { status: 500 });
  }
}

8. Middleware for Protected Pages

// middleware.ts (root of project)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { verifyToken } from '@/lib/auth';

// Pages that require authentication
const protectedRoutes = ['/dashboard', '/settings', '/profile'];

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

  const isProtected = protectedRoutes.some(route =>
    pathname.startsWith(route)
  );

  if (!isProtected) return NextResponse.next();

  // Get token from cookie
  const token = request.cookies.get('auth-token')?.value;

  if (!token || !verifyToken(token)) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/profile/:path*'],
};

Store the token in a cookie (not localStorage) so middleware can access it:

// After successful login — set cookie
const response = NextResponse.json({ success: true });
response.cookies.set('auth-token', token, {
  httpOnly: true,    // JavaScript can't access it
  secure: true,      // HTTPS only
  sameSite: 'lax',
  maxAge: 60 * 60 * 24 * 7, // 7 days
});
return response;

Summary

Step	File
Utilities	`lib/auth.ts`
User model	`models/User.ts`
Register	`app/api/auth/register/route.ts`
Login	`app/api/auth/login/route.ts`
Protected route	Check token in handler
Protected pages	`middleware.ts`

Once you build this yourself you'll understand exactly what NextAuth does under the hood — and you'll know when to use it vs build your own.

I use these patterns building production Next.js SaaS apps.

My templates: https://pixelanas.gumroad.com

Questions? Drop them below 👇

Anas — full-stack Next.js developer. X: @pixelanas

DEV Community: Anas Sheikh

Error Handling in Next.js 15 error.tsx, notFound(), and the Patterns I Actually Use

1. error.tsx — Route-Level Error Boundaries

2. Nested Error Boundaries — Isolate the Blast Radius

3. global-error.tsx — The Last Resort

4. not-found.tsx and notFound()

5. loading.tsx — Instant Loading States for Free

6. try/catch Still Has a Job — Inside the Fetch, Not Around It

7. Server Action Errors Don't Need error.tsx at All

Summary

Authentication in Next.js 15 The Pattern I Use for Every SaaS

1. The Auth Helpers

2. Login as a Server Action

3. Protecting Routes with Middleware

4. Reading the Session in Server Components

5. Role-Based Access on Top of Auth

6. Logging Out

The Mistakes I See Most

Summary

MongoDB + Mongoose Patterns I Use in Every Next.js Project

1. The Connection Caching Pattern

2. Schema Design That Doesn't Bite You Later

3. Typing Documents vs. Plain Objects

4. Query Helpers Instead of Repeating .lean() Everywhere

5. Validation Before It Touches the Database

6. Indexes You Actually Need

Summary

How to Make Your Next.js App Blazing Fast — Performance Checklist

1. Images — The Biggest Performance Win

2. Fonts — Eliminate Layout Shift

3. Bundle Size — Stop Loading What You Don't Need

4. Server Components — Reduce JavaScript Sent to Browser

5. Suspense and Streaming

6. Metadata and Preloading

Performance Checklist

Measure First

How to Use Prisma with Next.js 15 — Complete Setup Guide

Install

Schema Design

Run Migration

The Connection Problem in Next.js

CRUD Operations

Using in API Routes

Transactions

Seeding the Database

Common Error Codes

Environment Setup

Stop Manually Validating API Input — Use Zod in Next.js

Install

Basic Schema

Using in API Routes

Using in Server Actions

Common Zod Patterns

String Validations

Number Validations

Object Patterns

Validating Query Params

Validating Environment Variables

Form Error Display

Summary

Next.js 15 Caching Explained — Finally Makes Sense

The Simple Mental Model

1. Default — Cached Forever

2. Never Cache — Always Fresh

3. Revalidate on a Timer

4. Revalidate on Demand

Tags — The Missing Piece

Real Example — Blog with On-Demand Revalidation

Caching with Database Queries

Quick Reference

Node.js for Frontend Developers — What Nobody Explains

The Event Loop — Finally Explained Simply

require vs import

The Middleware Pattern

Environment Variables

Async Error Handling

Reading and Writing Files

A Complete Mini API

Key Differences From Frontend JavaScript

6 React Mistakes That Waste Hours — And How to Fix Them

1. `error.tsx` — Route-Level Error Boundaries

3. `global-error.tsx` — The Last Resort

4. `not-found.tsx` and `notFound()`

5. `loading.tsx` — Instant Loading States for Free

7. Server Action Errors Don't Need `error.tsx` at All

4. Query Helpers Instead of Repeating `.lean()` Everywhere