DEV Community: Safdar Ali

Prisma + PostgreSQL + Next.js — Full Stack Setup Guide

Safdar Ali — Fri, 30 Oct 2026 13:40:37 +0000

I'm Safdar Ali. When a Next.js project needs real persistence — users, posts, orders — I default to Prisma over PostgreSQL. Not because ORMs are magic, but because typed queries, migrations, and App Router server components fit together cleanly. This prisma nextjs tutorial walks from zero to production queries, the same stack I use when a client needs a full product, not just a marketing shell on safdarali.in.

Prerequisites and project bootstrap

Node 20+, a Next.js 15 App Router app, and PostgreSQL — local Docker, Neon, or Supabase free tier all work. India-friendly tip: Neon and Supabase both have free tiers with Mumbai-adjacent regions for lower latency than US-only hosts.

npx create-next-app@latest my-app --typescript --app --eslint

cd my-app

npm install prisma @prisma/client

npx prisma init

  
  
  .env


DATABASE_URL="postgresql://user:pass@localhost:5432/myapp?schema=public"

I use Docker Compose for local Postgres when clients want offline development — one docker compose up and DATABASE_URL points at localhost. For solo projects I often skip local Postgres entirely and use Neon's free branch per developer; connection string in .env.local, no Docker overhead on a laptop that already runs Next.js, Prisma Studio, and Chrome with twelve tabs. Pick the path that gets you to a working schema fastest; you can always dockerize later.

TypeScript strict mode pairs well with Prisma — generated types flow into Server Components without manual interfaces. Enable strict in tsconfig.json before writing models so nullable fields and relation includes fail at compile time instead of in production when a client reports undefined author name on a blog post.

prisma nextjs tutorial students often skip .env discipline — commit .env.example, never .env.local. Add DATABASE_URL to Vercel before the first deploy that touches the database, or builds succeed and runtime crashes on the first Server Component query. I test locally with npx prisma studio to verify relations before writing UI — faster than debugging empty author names in JSX when the include was wrong.

Schema design — models that match your UI

Start from screens, not tables. A blog needs Post and User; a SaaS needs Organization and Member. Keep relations explicit in Prisma schema — your Server Components will thank you for include types.

// prisma/schema.prisma

generator client {

  provider = "prisma-client-js"

}

datasource db {

  provider = "postgresql"

  url      = env("DATABASE_URL")

}

model User {

  id        String   @id @default(cuid())

  email     String   @unique

  name      String?

  posts     Post[]

  createdAt DateTime @default(now())

}

model Post {

  id        String   @id @default(cuid())

  title     String

  slug      String   @unique

  published Boolean  @default(false)

  authorId  String

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

  createdAt DateTime @default(now())

}

// BEFORE — stringly-typed IDs and no unique slug

model Post {

  id    Int    @id @default(autoincrement())

  slug  String

}

// AFTER — cuid + unique slug for App Router [slug] routes

slug String @unique

Relations deserve early attention. A Post belongs to User today; tomorrow you add Organization with multi-tenant posts. Adding authorId without planning tenantId means painful migrations when the second customer onboard. I sketch entity relationships on paper — or Excalidraw — before writing schema.prisma, even for weekend projects. Prisma makes schema changes easy; product direction changes are what hurt.

Enums versus strings is another choice. status Enum(PUBLISHED, DRAFT) gives database-level validation; status String gives flexibility when product adds ARCHIVED without a migration. For indie MVPs I use strings with Zod enums in application code; for fintech clients I prefer Prisma enums so bad data never lands in Postgres regardless of application bugs.

@@index directives in schema.prisma belong on columns you filter and sort — slug, authorId, published, createdAt. Missing indexes show up as slow dashboards long after launch. I add indexes when queries exist, not speculatively on every string column. Prisma migrate dev generates the SQL; review it like any migration before applying to production.

Migrations — dev flow vs production

Local development: prisma migrate dev creates SQL migration files you commit to Git. Production: prisma migrate deploy in CI or release step — never edit production schema by hand.

# Create and apply migration locally

npx prisma migrate dev --name init_blog

  
  
  Generate client after schema changes


npx prisma generate

  
  
  Production (CI script)


npx prisma migrate deploy

I once skipped committing migration files and watched staging diverge from local — painful afternoon. Treat prisma/migrations like application code.

prisma db seed populates local databases with realistic fixtures — fake users, sample posts, test orders. I commit prisma/seed.ts and wire it in package.json so new engineers run npx prisma db seed after migrate dev. Seeds are not for production; they save hours clicking through empty admin UIs during development. Use faker or static JSON depending on whether you need reproducible demo data for screenshots.

Rollback strategy matters when migrate deploy fails mid-pipeline. CI should fail the deploy, not half-apply schema. I run migrations in a dedicated CI step before next build, with DATABASE_URL pointing at staging first. Production promote only after smoke tests pass. Prisma documents repair commands for drift — read them before you need them at 2 AM Bengaluru time.

prisma db push is for prototypes only — it syncs schema without migration history. I use it on weekend hacks, then throw away the database before production. Production always uses migrate dev and committed migration folders. Clients paying for reliability deserve auditable schema history, not a pushed schema that cannot roll back cleanly.

Prisma client singleton — avoid connection exhaustion

Next.js dev hot reload can spawn multiple PrismaClient instances. The standard singleton pattern fixes "too many connections" on localhost and serverless.

// lib/prisma.ts

import { PrismaClient } from "@prisma/client";

const globalForPrisma = globalThis as unknown as {

  prisma: PrismaClient | undefined;

};

export const prisma =

  globalForPrisma.prisma ??

  new PrismaClient({

    log: process.env.NODE_ENV === "development" ? ["query", "error"] : ["error"],

  });

if (process.env.NODE_ENV !== "production") globalForPrisma.prisma = prisma;

The singleton pattern stores PrismaClient on globalThis during development so hot module replacement does not create connection number fifty-one. In production on serverless, each function invocation may still create a client — pooling at the database layer is mandatory, not optional. I log query duration in development only; production logs errors without printing full SQL that might contain PII from WHERE clauses.

Server queries in App Router — read path

// app/blog/[slug]/page.tsx — Server Component

import { prisma } from "@/lib/prisma";

import { notFound } from "next/navigation";

type Props = { params: Promise<{ slug: string }> };

export default async function BlogPostPage({ params }: Props) {

  const { slug } = await params;

const post = await prisma.post.findUnique({

    where: { slug, published: true },

    include: { author: { select: { name: true } } },

  });

if (!post) notFound();

return (

    <article>

      <h1>{post.title}</h1>

      <p>By {post.author.name}</p>

    </article>

  );

}

HTML ships with content — same SEO win as my Next.js vs React article. No client fetch waterfall.

Pagination belongs in the query, not in JavaScript filter after fetch. Use cursor-based pagination for infinite scroll feeds; offset pagination is fine for admin tables under ten thousand rows. Include only fields the UI needs — select and include are your friends against over-fetching. I have seen findMany without take pull entire tables into server memory and OOM a Vercel function on a client blog with five years of posts.

Caching interacts with Prisma through Next.js fetch cache and unstable_cache — wrap expensive read queries when data can be stale for sixty seconds. Do not cache user-specific rows in shared cache keys unless you include userId in the key. Public blog slugs cache well; /dashboard/me does not.

generateMetadata alongside findUnique lets blog posts ship correct Open Graph titles from the database — one query, SEO and body content aligned. I colocate the prisma call in generateMetadata and the page component only when necessary; often a shared getPostBySlug helper in lib/posts.ts avoids duplicate queries through React cache() in the same request.

Mutations — Server Actions with Prisma

// app/actions/posts.ts

"use server";

import { prisma } from "@/lib/prisma";

import { revalidatePath } from "next/cache";

import { z } from "zod";

const CreatePost = z.object({

  title: z.string().min(1).max(120),

  slug: z.string().regex(/^[a-z0-9-]+$/),

});

export async function createPost(formData: FormData) {

  const parsed = CreatePost.safeParse({

    title: formData.get("title"),

    slug: formData.get("slug"),

  });

  if (!parsed.success) return { error: "Invalid input" };

await prisma.post.create({

    data: {

      title: parsed.data.title,

      slug: parsed.data.slug,

      authorId: "user_id_from_session",

    },

  });

revalidatePath("/blog");

  return { ok: true };

}

Deeper patterns: React Server Actions guide.

Authorization belongs in Server Actions before prisma calls — verify session, check row ownership, then mutate. Never trust authorId from hidden form fields. I load the session server-side and compare post.authorId to session.userId before update or delete. Prisma does not know your auth rules; it executes whatever valid SQL your code requests.

Soft deletes with deletedAt DateTime? optional filter every findMany — easy to forget and leak rows. I prefer explicit archived boolean or a dedicated status enum. Prisma middleware can enforce soft delete globally, but that magic confuses juniors debugging why count queries disagree. Be explicit in query helpers until the team knows the data model cold.

BEFORE / AFTER — raw SQL vs Prisma in a Next.js route

// BEFORE — pg pool in every route, manual mapping

import { Pool } from "pg";

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

export async function GET() {

  const res = await pool.query("SELECT * FROM Post WHERE published = true");

  return Response.json(res.rows);

}

// AFTER — typed Prisma in Server Component

const posts = await prisma.post.findMany({

  where: { published: true },

  orderBy: { createdAt: "desc" },

  take: 20,

});

Raw SQL still has a place — reporting queries with window functions, bulk updates, or Postgres-specific features Prisma does not model. Use prisma.$queryRaw with tagged templates and parameterized values; never string-concatenate user input. For ninety percent of CRUD in Next.js apps, generated client methods stay readable and type-safe enough that raw SQL becomes the exception documented in code comments.

Seeding local data — realistic dev without production dumps

// prisma/seed.ts

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

async function main() {

  await prisma.user.upsert({

    where: { email: "dev@safdarali.in" },

    update: {},

    create: {

      email: "dev@safdarali.in",

      name: "Safdar Ali",

      posts: {

        create: [

          { title: "Draft post", slug: "draft-post", published: false },

          { title: "Hello world", slug: "hello-world", published: true },

        ],

      },

    },

  });

}

main()

  .then(() => prisma.$disconnect())

  .catch((e) => { console.error(e); process.exit(1); });

// package.json

"prisma": {

  "seed": "npx tsx prisma/seed.ts"

}

  
  
  Run after migrate dev


npx prisma db seed

Seed scripts keep your App Router pages testable without clicking through admin UI every refresh. Never run seed against production — use migrations plus one-off scripts with explicit environment checks.

Deploy checklist — connection pooling on serverless

Serverless functions should not open unlimited DB connections. Use Prisma Accelerate, PgBouncer, or Neon's pooled connection string in DATABASE_URL.

# Vercel build

prisma generate

prisma migrate deploy

next build

  
  
  .env.production — pooled URL example (Neon)


DATABASE_URL="postgresql://user:pass@ep-xxx.ap-southeast-1.aws.neon.tech/neondb?sslmode=require&pgbouncer=true"

Platform comparison: deploy Next.js free.

Preview deployments on Vercel need their own DATABASE_URL or a shared staging database with clear naming — I prefix preview branch names in Neon and rotate credentials when interns leave. Never point preview at production Postgres; one bad seed script deletes real customer rows. Environment separation is boring until it saves your company.

Production habits that save you on call

Index columns you filter on (slug, authorId). Never expose prisma to client components. Seed scripts for local dev only. Prisma + PostgreSQL + Next.js is the full-stack default I recommend when the product stores data — learn the schema first, ship server queries second, wire actions third.

Related: GraphQL vs REST, contact.

Serverless without a connection pooler exhausts Postgres connections under traffic spikes. Neon, Supabase, and Railway offer pooled URLs — use them in Vercel environment variables. Prisma Accelerate is an option when latency to your database region is high from Indian users hitting a US-east instance.

Wrap multi-step writes in prisma.$transaction inside Server Actions — partial updates corrupt data. Validate input with Zod before every Prisma call. Use a separate TEST_DATABASE_URL in Jest; never hit production from tests.

prisma nextjs tutorial takeaway: schema first, migrate second, singleton client third, Server Component reads fourth, Server Action writes fifth, deploy with pooler sixth. Ship one CRUD feature this weekend — a blog, a todo app, a contact form that persists — and you will understand the stack better than reading docs alone.

prisma studio is underrated for debugging — npx prisma studio opens a GUI on local data without writing SQL. Use it when Server Actions return unexpected null relations. For production debugging, prefer read-only replicas and logged queries over connecting Studio to live databases from a coffee shop WiFi in Bengaluru.

Indexing strategy: add @@index([authorId]) and @@index([slug]) in schema when lists filter on those columns. Prisma migrate generates the SQL; you review the migration file before apply. Missing indexes show up as slow queries in Neon dashboard long before users complain — if you are not monitoring query time, start there this week.

Soft deletes with deletedAt DateTime fields keep rows for audit without losing foreign keys — Prisma supports filtering where deletedAt is null in every query. Add a wrapper function so engineers cannot forget the filter. Hard deletes for GDPR erasure stay as explicit admin-only Server Actions with logging.

Read replicas are a later concern. For MVPs on Neon free tier, a single primary with connection pooling is enough. When read traffic ten times exceeds write traffic, split reads or move analytics to a warehouse — not on day one from a Bengaluru apartment dev setup.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

PHP2Shell: what the two critical PHP RCE CVEs actually mean for your stack

Safdar Ali — Thu, 22 Oct 2026 22:15:57 +0000

If you're on PHP 8.1 or older, there is no official fix coming. Those branches are end-of-life. Your options are: upgrade, or ask your hosting/distro vendor if they provide a backported patch (some LTS vendors do).

What to actually do today

1. Check what's really running your site, not just your CLI version

php -v

This shows your CLI version. It is not necessarily the version serving requests. Check the SAPI that's actually live:

php-fpm -v
curl -sI https://yoursite.com/ | grep -iE "^(server|x-powered-by):"

CLI and web versions can differ, especially on servers hosting multiple projects.

2. Patch internet-facing systems first

If it's reachable from the open internet, it's the priority. Internal-only services can wait a few hours if you're triaging a lot of infrastructure.

3. Don't forget bundled PHP

Docker base images, CMS installer bundles, and vendor tarballs often ship their own PHP. A host-level patch won't touch these. Check every running image:

docker exec <container> php -v

4. Ask your hosting provider directly

Managed hosts (SiteGround, Cloudflare-fronted setups, etc.) may have already deployed WAF-level mitigations or patched server-side. Don't assume — ask.

5. Watch for post-exploitation signs

Keep an eye on PHP worker processes spawning shells, curl/wget calls, or unexpected outbound connections. That's the pattern seen in active exploitation so far.

A stopgap, not a fix

Some researchers have floated disabling session.upload_progress as a temporary mitigation:

session.upload_progress.enabled = Off

This is not a substitute for patching. Treat it as something you do while you're rolling out the real fix, not instead of it.

If you manage sites for other people

Send a short, plain update today — what happened, what you're doing about it, when it'll be done. Clients hearing about a "PHP vulnerability" from the news before they hear it from you is a worse conversation than this one.

Sources:

Has your stack been patched yet? Drop your setup in the comments — curious how many people are finding PHP buried in places they forgot about.

How AI Changed the Way I Write React Code — 2 Years In

Safdar Ali — Sun, 11 Oct 2026 20:40:04 +0000

I'm Safdar Ali, a frontend engineer in Bengaluru. In late 2024 I installed GitHub Copilot as an experiment. Today — October 2026 — Cursor Agent with Claude is open on every project, including this portfolio at safdarali.in. Two years of daily ai react development did not make me obsolete. It changed where I spend cognitive effort: less on boilerplate, more on architecture, review, and the questions AI cannot answer. This is an honest accounting — not a pitch for any tool.

What actually changed in my daily work

Speed on scaffolding. New components, API route stubs, Zod schemas, and test files appear in minutes instead of half-hours. I start further along on every task.

Context switching dropped. I used to alt-tab between docs, Stack Overflow, and my editor constantly. Now I ask the agent to explain an unfamiliar API against my actual codebase — the answer is contextual, not generic.

Refactors got cheaper. Renaming a prop across 12 files, converting client fetches to Server Components, adding TypeScript strict types to a legacy module — these used to be "schedule for Friday" tasks. Now they're afternoon tasks with review.

My commit size changed. More frequent, smaller commits. AI generates chunks; I review and merge chunk by chunk instead of writing 400-line PRs manually.

// 2024 — I wrote every line of this by hand

export function useDebounce<T>(value: T, delay: number): T {

  const [debounced, setDebounced] = useState(value);

  useEffect(() => {

    const timer = setTimeout(() => setDebounced(value), delay);

    return () => clearTimeout(timer);

  }, [value, delay]);

  return debounced;

}

// 2026 — AI generates this in 3 seconds; I verify edge cases and add tests

// My value-add: knowing WHEN to debounce, not typing the hook from memory

What did not change — and probably never will

Architecture decisions. Server Component vs client component boundaries, state management choices, caching strategy — AI suggests patterns but cannot know your product constraints, team size, or traffic profile.

Debugging production incidents. AI helps read stack traces. It does not replace opening DevTools at 11pm when a hydration mismatch only appears on Android Chrome in India.

Code review judgment. Someone must reject the confident wrong output. That someone needs to understand React reconciliation, not just prompt engineering.

Stakeholder communication. Translating "we need ISR here because catalog updates hourly" into business language — no model does that for you.

What surprised me most over two years: AI did not reduce total hours worked — it shifted where those hours go. I spend less time writing boilerplate and more time in code review, architecture discussions, and debugging the subtle bugs AI introduces — wrong dependency arrays, missing error boundaries, imports from packages not in package.json. The job got more senior, not more absent.

Pair programming changed too. When I mentor juniors in Bengaluru, we use AI together — they prompt, I ask why they accepted the output, we fix it together. That teaches review skills faster than solo tutorial watching. The tool is the same; the mentorship model adapted.

Skills that matter more now — ranked honestly

Skill	Importance in 2024	Importance in 2026	Why
Reading diffs critically	High	Critical	AI generates more code to review
React fundamentals	Critical	Critical	Cannot debug AI output without them
Typing speed / memorisation	Moderate	Lower	Autocomplete handles syntax
System design	High	Higher	AI fills files; you design boundaries
Prompt/task specification	Low	High	Bad prompts waste more time now
Testing discipline	High	Critical	Safety net for AI-generated code
Security awareness	High	Critical	AI leaks patterns, misses auth gaps

Before and after — same feature, two eras

Adding a contact form to a Next.js portfolio — the task I did for this site in 2024 vs 2026.

// BEFORE (2024) — ~4 hours total

// 1. Create API route manually (30 min)

// 2. Write client form with useState validation (45 min)

// 3. Style with Tailwind trial-and-error (60 min)

// 4. Add loading/error states (30 min)

// 5. Debug CORS and env vars (45 min)

// 6. Write tests (30 min)

// AFTER (2026) — ~90 minutes total

// 1. Agent scaffolds Server Action + Zod validation (5 min gen, 15 min review)

// 2. v0 generates form UI, I wire action prop (10 min gen, 20 min review)

// 3. Manual: rate limiting, honeypot, email provider integration (40 min)

// 4. Tests generated, I add edge cases (10 min)

// Time saved: ~2.5 hours. Time still required: integration + review.

The saved time went into performance work and content — not into leaving early. AI shifted the work mix, not the total output expectation.

Code quality did not automatically improve — it shifted form. I write fewer lines manually but read more lines in review. Net lines of code per feature dropped roughly 20% on client projects where AI handled boilerplate, but bug density stayed similar when measured per thousand lines. The bugs moved from typos to logic errors in AI-generated conditionals — a different debugging skill, not fewer bugs by default.

What this means if you are learning React in India

Juniors ask me: "Should I learn to code if AI writes it?" Yes — but learn differently. Skip memorising array method signatures; do not skip building a todo app without AI so you understand state updates. Use AI to explain errors, not to skip the error entirely.

Interviewers in Bengaluru still ask you to walk through a component you wrote. If AI wrote all of it and you cannot explain useEffect dependencies, you will not pass. The bar moved from "can you type code" to "can you own code."

// Bad learning loop — paste AI output, ship, repeat

// You never build mental models

// Good learning loop — AI as tutor

// 1. Try writing the hook yourself (15 min)

// 2. Ask AI to review YOUR code, not generate fresh

// 3. Compare its suggestions to your attempt

// 4. Write the final version by hand with its hints

export function ProductFilter({ onFilter }: { onFilter: (q: string) => void }) {

  const [query, setQuery] = useState("");

  const debounced = useDebounce(query, 300);

useEffect(() => {

    onFilter(debounced);

  }, [debounced, onFilter]);

return <input value={query} onChange={(e) => setQuery(e.target.value)} />;

}

Mistakes I made adopting AI too fast

Shipping AI-generated auth logic without reading it — found a missing CSRF check in review, not in production, luckily. Accepting overly abstracted code because it looked "clean" — three files for what should have been one function. Stopping practice on fundamentals because autocomplete felt good enough — until a whiteboard interview reminded me why muscle memory matters.

The fix was rules, not quitting AI: never merge agent output without reading every changed line; never let AI touch auth, payments, or PII handling without manual security review; keep one personal project per month with AI disabled to stay sharp.

Tools will keep improving — faster models, better repo indexing, cheaper inference. The developers who treat that as leverage rather than replacement will compound their careers. The ones who stop learning fundamentals because autocomplete feels good enough will hit a ceiling in interviews and production incidents. I have seen both outcomes in my network across India's tech hubs over the last two years.

My YouTube audience often asks whether AI makes React tutorials obsolete. No — it makes understanding React more valuable. When anyone can generate a component, the developer who explains why it re-renders, why keys matter, and why the Server Component boundary exists becomes the one teams hire. That is the real shift behind ai react development 2026.

My weekly rhythm with AI in 2026

Monday: plan features manually — no AI for architecture decisions. Tuesday–Thursday: Cursor Agent for implementation, Copilot tab completion while I edit agent output. Friday: code review day — re-read the week's merges without AI assist, run Lighthouse and tests, fix anything that slipped through. Weekend: one hour on personal learning with AI disabled — currently revisiting TypeScript generics the slow way.

That rhythm keeps AI as accelerator, not autopilot. The Friday review catches the subtle bugs — missing dependency arrays, hardcoded API URLs, accessibility gaps — that autocomplete does not flag because they are syntactically valid. Two years in, this rhythm matters more than which model or editor I use.

Where ai react development goes from here

Agents will get better at multi-step tasks — migrations, test coverage, dependency upgrades. They will not replace the engineer who decides whether a migration is worth the risk this sprint. The developers who thrive will treat AI like a fast junior: delegate boilerplate, review everything, own the architecture.

I ship roughly 3x more features per month than in 2024, measured by merged PRs on client work — not because AI writes 3x the code, but because the idle time between "I know what to build" and "first working draft" collapsed. That is the real ai react development 2026 story.

Document your own before/after metrics if you adopt AI tools seriously — merged PRs per week, time from ticket to staging, lines changed in review versus lines changed manually. Without numbers, you will not know if AI actually helps your workflow or just feels faster because typing is more entertaining. I review my metrics monthly and adjust tool usage accordingly.

The single takeaway

AI changed my React workflow profoundly — not by replacing thinking, but by removing friction between thinking and implementation. Fundamentals matter more, not less, because the bottleneck moved from typing to judgment. Learn React deeply, use AI aggressively, review ruthlessly.

Two years from now the tools will look different — new models, new editors, maybe AI built into browsers. The pattern will hold: engineers who understand their stack and review AI output will ship faster than engineers who either reject AI entirely or accept it blindly. Meet in the middle. That is where the career growth lives in ai react development 2026 and beyond.

If you are early in your career, prioritise understanding over speed for the next six months — use AI to explain code you wrote, not to write code you cannot explain. The productivity multiplier kicks in once fundamentals are solid; before that, AI mostly hides gaps that interviews expose.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Jev Is Not an LLM. That Is the Point.

Safdar Ali — Thu, 24 Sep 2026 08:06:46 +0000

Most "AI features" are not writing tasks. They are decisions.

Is this ticket urgent? Which queue owns it? Is this shell command safe to run? Should this request go to a small model, a large one, or a person?

A language model can answer all of those. It does it by generating text, one token at a time, even when you asked for JSON. Jev, from TypeSafe AI, does not generate text at all. You hand it a piece of state and a set of questions whose answers you already defined. It fills those answers in one pass and attaches a confidence score to each one.

That tradeoff is the product. Jev cannot write the email, the summary, or the code. Your program still decides what to do with the judgment.

What you are actually calling

TypeSafe calls Jev a System One model, after the fast, intuitive half of Daniel Kahneman's Thinking, Fast and Slow. The name Jev comes from William Stanley Jevons: when a resource gets cheap enough, people find far more uses for it. The bet is that a decision cheap enough to put inside ordinary control flow gets used in places a frontier chat model never will.

The interface is closer to a function than to a chat:

	A language model	Jev
Output	A string you parse	A value you declared up front
Sampling	One token after another	Every answer in the same request
Uncertainty	Only if you ask, and often overconfident	A confidence score on every answer
Failure mode	Wrong words, broken JSON, a type you did not expect	A wrong choice inside the types you allowed

TypeSafe's published pricing is $0.042 per million input tokens, with output tokens not billed. They report end-to-end times of about 70–500ms, and on their own workflow evals they cite figures around 190× faster and 440× cheaper than the large models they compared against. Those numbers are their benchmark, on workflows their own team wrote, scored against other labs' models. Treat them as a reason to measure your path, not as a number to put in a launch post.

Schema match is a harder claim, and a narrower one. Jev cannot return a string when the field is an enum. It can still pick sales when billing was right. You fixed the shape. You did not get correctness for free.

Put the question on the type, not in the prompt

If you have used Pydantic AI, the call looks like any other structured-output agent. Install the TypeSafe extra and set TYPESAFE_API_KEY.

pip install "pydantic-ai-slim[typesafe]"
export TYPESAFE_API_KEY="your-api-key"

The habit that does not carry over from a language model: the prompt is only the material being judged. The questions live on the output type. A question written into the prompt is more text to judge, not an instruction.

from typing import Literal

from pydantic import BaseModel, Field
from pydantic_ai import Agent

class Ticket(BaseModel):
    """Triage a support ticket."""

    urgent: bool = Field(description="Does this need a reply within the hour?")
    area: Literal["billing", "bug", "account", "other"] = Field(
        description="Which team owns it?"
    )

agent = Agent("typesafe:jev-latest", output_type=Ticket)
result = agent.run_sync(
    "You charged me twice and my account is overdrawn. I need this reversed today."
)
print(result.output)
# urgent=True area='billing'

Several fields go out together. That is where the latency win comes from: independent judgments are not separate generation rounds. Extra fields cost input tokens, not another round trip.

Ask one thing per field. "Is this a good ticket?" is several judgments wearing one name. Jev will still return something, often with low confidence, and you will notice too late. Split it. Combine the answers in code, where the rule is exact.

A str field, an unbounded number, or a datetime is rejected before the request is sent. If the answer is prose, this is the wrong model.

Confidence is the part you branch on

A boolean becomes True when Jev's probability of yes is at least typesafe_boolean_threshold, which defaults to 0.5. That default is a coin flip. It is the wrong bar when the two mistakes do not cost the same. Raising the threshold means a True has to be earned, which is what you want for "safe to run this command with no one watching."

The margin on each field is on the response, not on the model instance:

details = result.response.provider_details or {}
confidence = details.get("confidence", {})
# {'urgent': 0.91, 'area': 0.74}  — illustrative

confidence here is a margin, not "the probability this label is correct." For a yes/no it measures how far the probability sits from the threshold that decided it. For a pick-one, the full distribution is in provider_details['probabilities'].

A practical split:

High margin: let code act.
Middle: send the same state to a stronger generative model.
Low: ask a person.

jev-latest moves when TypeSafe ships a release, and the numbers under a tuned threshold can move with it. Once a bar is calibrated on your own labels, pin a version such as typesafe:jev-1.13.0.

If the honest answer is sometimes "not enough information," put that in the type. A yes/no with no third option forces a side.

Where it fits, and where it does not

Use Jev for the small semantic branch that used to be either a brittle regex or a full model call:

Routing a ticket, a tool call, or a model.
Scoring a rubric you defined (ordered levels, each one described).
Checking an agent step: did it finish, did it leave the requested scope, does a human need to see this?
Guardrails around something a language model already wrote.

Keep a language model for generation and for reasoning that does not fit in one judgment. Keep ordinary code for rules you can write down: amount greater than a limit, a missing field, an allow-list. Jev sitting in the middle does not replace either of those.

Two design limits are worth knowing before you sketch an architecture. Choice lists top out at 255 options, and a high-cardinality pick may be scored in two stages. Fields in the same request are independent, so one answer cannot depend on another answer from that same call. If the second judgment needs the first, make them two steps.

A small architecture, not a new model in every slot

exact rule            → code
bounded judgment      → Jev
writing or reasoning  → a language model
high-stakes uncertainty → a person

The useful question is not which model to standardize on. It is what kind of intelligence a given step needs. If the step is a decision with answers you can name in advance, generating those answers token by token is a lot of machinery for a branch.

Jev is in early access. The TypeSafe announcement has their evals and the caveats attached to them. The Pydantic AI TypeSafe docs are the practical reference for field types, thresholds, and provider_details.

☕ If This Helped You

I publish free tutorials and write-ups like this regularly.

If this article saved you time:

👉 Buy me a coffee:

https://buymeacoffee.com/safdarali

👉 Subscribe to my YouTube channel (free):

https://www.youtube.com/@safdarali_?sub_confirmation=1

More about how I work: safdarali.in/about
Projects and case studies: safdarali.in/projects

Next.js App Router Complete Beginner Guide 2026

Safdar Ali — Fri, 10 Jul 2026 18:30:00 +0000

The nextjs app router tutorial gap is real: official docs are reference-heavy, and beginners still think in Pages Router (pages/index.tsx). App Router uses folders in app/ where the file name tells Next.js what to do. I migrated client sites in 2024–2025 and teach this sequence on my YouTube channel. Follow these steps in order — layout, page, loading, then server fetch.

Mental model — folders are routes

Every folder under app/ maps to a URL segment. Special files: page.tsx = UI, layout.tsx = shared shell, loading.tsx = skeleton while slow segments load.

app/

  layout.tsx      → wraps ALL routes

  page.tsx        → URL: /

  about/

    page.tsx      → URL: /about

  blog/

    page.tsx      → URL: /blog

    [slug]/

      page.tsx    → URL: /blog/my-post

No React Router install. Rename a folder, you rename a route. That is the core App Router win.

If you are coming from Create React App, delete the mental model of a single App.tsx with a Switch. You will have multiple layout.tsx files at different depths — root for html/body, nested for dashboard sidebars. Each layout wraps only its subtree.

Step 1 — Root layout (HTML shell once)

// app/layout.tsx

import type { Metadata } from "next";

import "./globals.css";

export const metadata: Metadata = {

  title: "My App",

  description: "Beginner App Router site",

};

export default function RootLayout({

  children,

}: {

  children: React.ReactNode;

}) {

  return (

    <html lang="en">

      <body className="min-h-screen bg-white text-neutral-900">

        <header className="border-b p-4">My Site</header>

        <main>{children}</main>

      </body>

    </html>

  );

}

Layouts do not remount when navigating between child pages — perfect for nav bars and fonts. Keep providers that must persist here (theme, analytics).

Step 2 — First page

// app/page.tsx — home route

export default function HomePage() {

  return (

    <section className="p-8">

      <h1 className="text-3xl font-bold">Welcome</h1>

      <p>Your first App Router page — no use client needed.</p>

    </section>

  );

}

Default export must be a component. This is a Server Component unless you add "use client" at the top.

Step 3 — loading.tsx for perceived speed

// app/blog/loading.tsx — shows while blog segment loads

export default function BlogLoading() {

  return (

    <div className="animate-pulse space-y-4 p-8">

      <div className="h-8 w-48 rounded bg-neutral-200" />

      <div className="h-4 w-full rounded bg-neutral-200" />

      <div className="h-4 w-3/4 rounded bg-neutral-200" />

    </div>

  );

}

Next.js wraps the segment in Suspense automatically. Users see skeletons instead of frozen UI — critical on Indian mobile networks.

Step 4 — Server Component fetch (no useEffect)

// app/blog/page.tsx

type Post = { slug: string; title: string };

async function getPosts(): Promise<Post[]> {

  const res = await fetch("https://api.example.com/posts", {

    next: { revalidate: 3600 },

  });

  if (!res.ok) throw new Error("Failed to load posts");

  return res.json();

}

export default async function BlogPage() {

  const posts = await getPosts();

  return (

    <ul className="space-y-2 p-8">

      {posts.map((post) => (

        <li key={post.slug}>

          <a href={"/blog/" + post.slug}>{post.title}</a>

        </li>

      ))}

    </ul>

  );

}

// BEFORE — Pages Router habit (client fetch)

"use client";

useEffect(() => fetch("/api/posts").then(/* ... */), []);

// AFTER — async server component

// Data ready before HTML ships — better SEO and LCP

Deeper caching rules: SSR vs SSG vs ISR. Performance tuning: 60% load time case study.

App Router files — quick comparison table

File	Purpose	Required?
layout.tsx	Shared UI wrapper	Root required
page.tsx	Route UI	Yes per route
loading.tsx	Loading skeleton	Optional
error.tsx	Error boundary	Optional
not-found.tsx	404 UI	Optional
route.ts	API endpoint	Optional

Step 5 — Add client components only as leaves

// components/CounterButton.tsx

"use client";

import { useState } from "react";

export function CounterButton() {

  const [n, setN] = useState(0);

  return <button onClick={() => setN(n + 1)}>Clicked {n} times</button>;

}

// app/page.tsx — server page imports client leaf

import { CounterButton } from "@/components/CounterButton";

export default function HomePage() {

  return (

    <section>

      <h1>Home</h1>

      <CounterButton />

    </section>

  );

}

Read RSC vs client components before marking whole pages as client — that is the beginner mistake that balloons bundle size.

Step 6 — Dynamic routes and params

// app/blog/[slug]/page.tsx

type Props = { params: Promise<{ slug: string }> };

export default async function PostPage({ params }: Props) {

  const { slug } = await params;

  const post = await getPost(slug);

  if (!post) return <p>Not found</p>;

  return <article><h1>{post.title}</h1></article>;

}

In Next.js 15, params is a Promise — await it. TypeScript strict mode helps catch forgotten awaits — strict mode guide.

Learning path after this guide

Week 1: layouts + pages + loading. Week 2: server fetch + one dynamic route. Week 3: one client form with Server Action. Week 4: deploy to Vercel and run Lighthouse. If you are choosing between stacks first, read Next.js vs React. Organise folders early with project structure guide.

For AI-assisted coding, see Cursor + Claude workflow — but build this hello-world tree by hand once so file conventions stick.

My production setup

In production I scaffold with root layout, route groups for marketing vs app, loading.tsx on slow segments, and async server pages for public content. This portfolio follows the same pattern — thin app/blog/.../page.tsx files, heavy logic elsewhere.

At my day job, beginners who complete these six steps ship their first internal page in a week — faster than learning Pages Router and relearning later.

The single takeaway

App Router = folders + special files. Layout once, page per route, loading for UX, async server fetch for data. Client components are seasoning, not the main dish.

Related: React 19 features. Contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

WCAG 2.2 Accessibility for React Developers — Practical Guide

Safdar Ali — Thu, 09 Jul 2026 18:30:00 +0000

I'm Safdar Ali, a frontend engineer in Bengaluru. Last quarter I audited a client dashboard that looked polished — clean Tailwind, smooth transitions, Lighthouse performance in the 90s — and failed basic keyboard navigation in under two minutes. Tab order jumped randomly, modals trapped nothing, and icon-only buttons had no labels. WCAG 2.2 is not a legal checkbox for enterprise contracts alone. It is how you ship React UI that works for everyone: screen reader users, keyboard-only users, people on slow 4G with zoom enabled, and your future self debugging at 11pm. This guide covers the wcag 2.2 react patterns I run before every merge.

Why WCAG 2.2 matters for React in 2026
WCAG 2.2 added criteria that directly affect React apps: focus not obscured, dragging movements, target size minimums, and consistent help. React's component model makes accessibility both easier and easier to break — you can encapsulate good patterns in a shared Dialog component, but you can also copy-paste a div-with-onClick button across forty files.

The legal landscape in India is catching up. Government portals and fintech products increasingly require accessibility audits before launch. Even when nobody asks, inclusive UI reduces support tickets — unclear error messages and broken focus management generate more "the form is broken" emails than actual backend failures.

React does not ship accessible components by default. A is focusable; a is not, unless you wire it. Your job is to make the accessible path the default path in your design system.

Focus traps — modals that actually work
A focus trap keeps keyboard focus inside a modal until the user dismisses it. Without one, Tab sends focus to elements behind the overlay — confusing for sighted keyboard users and disorienting for screen reader users who hear content from two layers at once.

How I Structure Large Next.js Projects — Folder Architecture Guide

Safdar Ali — Wed, 08 Jul 2026 18:30:00 +0000

Bad nextjs folder structure does not show up on day one. It shows up at month six when three developers search for the checkout form hook and find four copies. I reorganised a client dashboard after exactly that — this guide is the tree I use now on large App Router projects, why each folder exists, mistakes from my first Next.js apps, and the 10-second findability rule.

Real folder tree — production-shaped layout

my-app/

├── app/                    # routes only — thin pages

│   ├── (marketing)/        # route group — shared layout, no URL segment

│   │   ├── layout.tsx

│   │   ├── page.tsx

│   │   └── pricing/page.tsx

│   ├── (dashboard)/

│   │   ├── layout.tsx

│   │   └── orders/page.tsx

│   ├── api/                # route handlers

│   │   └── webhooks/stripe/route.ts

│   ├── layout.tsx          # root layout

│   └── globals.css

├── components/             # shared UI — buttons, cards, shell

│   ├── ui/

│   └── layout/

├── features/               # business domains — colocated logic

│   ├── auth/

│   │   ├── components/

│   │   ├── hooks/

│   │   └── actions.ts

│   └── orders/

│       ├── components/

│       ├── api.ts

│       └── types.ts

├── lib/                    # server + shared utilities

│   ├── db.ts

│   └── env.ts

├── hooks/                  # truly global client hooks

├── types/                  # global TS types

├── data/                   # static data, blog posts list

└── public/

Routes live in app/. Business logic lives in features/. Generic design system pieces live in components/ui. That separation is the whole game.

Why each folder exists

Folder	Purpose	Do not put here
app/	URLs, layouts, loading.tsx	Fat business logic
features/	Domain modules (orders, auth)	Generic Button
components/ui	Reusable primitives	Order-specific tables
lib/	DB clients, env validation	React components
app/api	Webhooks, REST edge cases	Every form POST (prefer actions)

Thin pages — route files under 40 lines

// app/(dashboard)/orders/page.tsx — orchestration only

import { OrderTable } from "@/features/orders/components/OrderTable";

import { getOrders } from "@/features/orders/api";

export default async function OrdersPage() {

  const orders = await getOrders();

  return (

    <section>

      <h1>Orders</h1>

      <OrderTable rows={orders} />

    </section>

  );

}

If your page file exceeds a screen, extract to features. Pages should read like a table of contents.

Thin pages also make Server Component boundaries obvious: data fetching stays in api.ts or the page, UI in feature components, client interactivity in a single leaf with "use client". When a page mixes all three, reviews slow down and hydration bugs hide in the middle of a 200-line file.

The 10-second findability rule

The rule applies to you six months later, not only new hires. I have opened my own repos and lost minutes searching for a webhook handler buried under utils — that shame is why I enforce feature folders now.

Ask: "Where is the code that sends the password reset email?" If you cannot answer in ten seconds, the structure failed. Correct answer in my tree: features/auth/actions.ts or features/auth/emails.ts — not scattered across utils, hooks, and app/api.

// Naming convention that helps findability

features/orders/

  components/   → OrderTable.tsx, OrderFilters.tsx

  hooks/        → useOrderFilters.ts (client)

  api.ts        → getOrders, createOrder (server-safe)

  types.ts      → Order, OrderStatus

First project mistakes I made

components/ dump with 80 files and no subfolders. utils.ts at 1,200 lines. Duplicating fetch logic in every page instead of feature api modules. Putting Server Actions inside random page files instead of colocated actions.ts.

Another mistake: mirroring REST URLs in folder names under components — components/api/users/get.tsx — which fights App Router conventions. Routes belong in app/; business logic belongs in features/. Mixing them creates two sources of truth for the same URL.

// BEFORE — everything in components/

components/

  OrderTable.tsx

  UserAvatar.tsx

  pricing-card.tsx

  helper.ts

// AFTER — domain colocation

features/orders/components/OrderTable.tsx

features/users/components/UserAvatar.tsx

app/(marketing)/pricing/page.tsx  // thin

Route groups for different shells

// app/(marketing)/layout.tsx — public nav, footer

// app/(dashboard)/layout.tsx — sidebar, auth gate

// URL stays /pricing and /orders — parentheses omit segment

Pair with rendering choices from SSR vs SSG vs ISR guide — marketing group ISR, dashboard group client-heavy.

Path aliases and import direction

// tsconfig paths — "@/": ["./"]

// Allowed import flow:

// app → features → components/ui → lib

// features → lib

// Never: lib → features (inverts layers)

Enforce with ESLint import rules when the team grows past three people.

I also keep a single README.md at the repo root with a one-paragraph map: where routes live, where features live, how to run migrations. The tree in this article is the visual version of that map — new contractors read it before their first PR.

My production setup

In production on this portfolio and client sites: route groups for marketing vs app shells, features/ for blog and contact logic, components/ui for sparkles and buttons. TypeScript strict — see strict mode guide. New engineers onboard by reading features/ first, not app/ line by line.

At my day job, we added a CODEOWNERS file per feature folder — reviews stay scoped. Structure is team policy, not personal taste.

When a feature folder grows past ~15 files, split subdomains — features/orders/checkout/ vs features/orders/history/ — before you invent a second top-level folder that duplicates the domain name.

The single takeaway

Routes in app/, domains in features/, primitives in components/ui. If findability fails the 10-second test, refactor before adding the next feature.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

React useCallback vs useMemo — When You Actually Need Them

Safdar Ali — Wed, 08 Jul 2026 18:30:00 +0000

Junior PRs in my reviews often wrap every function in useCallback and every array in useMemo because a blog post said so. The React Profiler showed the opposite: more memoisation, more comparison work, slower interactions. This usecallback vs usememo guide is profiler-first — what each hook does, when it helps, and the over-memoising mistake I made on a real table.

What each hook actually does

useMemo caches a computed value between renders when dependencies are unchanged. useCallback caches a function reference — it is useMemo for functions.

import { useMemo, useCallback } from "react";

function Dashboard({ rows }: { rows: Row[] }) {

  const total = useMemo(() => rows.reduce((sum, r) => sum + r.amount, 0), [rows]);

const handleExport = useCallback(() => {

    downloadCsv(rows);

  }, [rows]);

return <Toolbar total={total} onExport={handleExport} />;

}

Neither hook prevents re-renders by itself. They only help when a child skips render because props are referentially equal — usually with React.memo.

A common confusion: developers think useMemo stops the parent re-rendering. It does not. The parent still runs its function body every time state changes — useMemo only skips recomputing one expression inside that run. useCallback is the same for function identity. If your performance problem is "the whole page re-renders on every keystroke," move state down or split context before touching memo hooks.

The over-memoising mistake I made

On a 500-row admin table I wrapped every cell formatter in useMemo and passed useCallback handlers to each row. Scroll jank got worse — dependency checks on every scroll event dominated.

// BEFORE — memo soup, slower scroll

const formatted = useMemo(

  () => rows.map((r) => formatCurrency(r.amount)),

  [rows]

);

const onRowClick = useCallback((id: string) => navigate("/row/" + id), []);

// AFTER — virtualise the list, drop per-row memo

import { useVirtualizer } from "@tanstack/react-virtual";

// Only memo expensive derived data used by memoised children

Fix was virtualisation + smaller components, not more hooks. Lesson: measure before memoising.

// BEFORE — unstable inline object recreates every parent render

<HeavyChart config={{ theme: "dark", showGrid: true }} />

// AFTER — stable reference only if HeavyChart is memoised

const config = useMemo(() => ({ theme: "dark", showGrid: true }), []);

<HeavyChart config={config} />

Without React.memo on HeavyChart, the AFTER snippet still re-renders the chart — you paid for useMemo and got nothing. That is the over-memoising pattern: hooks without a memoised consumer.

How I use the React Profiler

Chrome React DevTools → Profiler → record interaction → look for components with long render times and high render counts. Yellow bars mean wasted renders. I fix structure first (split context, move state down, virtual lists), then add memo where a memoised child still re-renders with stable props.

// Wrap only when Profiler shows child re-renders are expensive

import { memo } from "react";

const HeavyChart = memo(function HeavyChart({ data }: { data: Point[] }) {

  // expensive canvas draw

  return <canvas />;

});

// Parent must pass stable data reference

const data = useMemo(() => computePoints(raw), [raw]);

return <HeavyChart data={data} />;

On marketing sites built with Server Components, much of the tree never hydrates — memo hooks on the server branch are pointless. See RSC vs client components.

When to use which — table

Situation	useMemo	useCallback
Expensive calculation	Yes	No
Stable prop to memo child	For objects/arrays	For functions
useEffect dependency	Rarely needed	Sometimes
Primitive props to memo child	No	No
List without virtualisation	Fix list first	Fix list first
Context provider value	Often yes (object)	Callbacks inside value

useCallback — legitimate use with memoised child

"use client";

import { memo, useCallback, useState } from "react";

const SearchInput = memo(function SearchInput({

  onSearch,

}: {

  onSearch: (q: string) => void;

}) {

  console.log("SearchInput render");

  return <input onChange={(e) => onSearch(e.target.value)} />;

});

export function FilterBar() {

  const [query, setQuery] = useState("");

  const onSearch = useCallback((q: string) => setQuery(q), []);

  return <SearchInput onSearch={onSearch} />;

}

Without useCallback, SearchInput re-renders whenever FilterBar state unrelated to search changes — only worth fixing if Profiler proves SearchInput is costly.

useMemo — filtering large lists

const filtered = useMemo(

  () => products.filter((p) => p.name.toLowerCase().includes(query.toLowerCase())),

  [products, query]

);

If the filter runs in under a millisecond on your data size, skip useMemo — the hook overhead can cost more than the loop.

Rule of thumb I teach in reviews

Default: no memo hooks. Add when Profiler shows a problem. useMemo for expensive derived data consumed by memoised children. useCallback for stable handlers passed to those children. Never memoise to silence ESLint exhaustive-deps without understanding why deps change.

React 19 and the future compiler may auto-memoise — until then, stay boring. Performance wins on public sites still come from server rendering and smaller bundles — Next.js performance guide.

My production setup

In production I memoise chart components and heavy derived selectors in dashboards. Marketing pages: almost zero useCallback/useMemo. At my day job I comment why when memo is added — "Profiler: Chart 40ms → 8ms" — so the next dev does not delete it blindly.

When mentoring in Bengaluru, I ask juniors to screenshot Profiler flamegraphs in PRs that add memo hooks — not because I love process, but because it proves they measured. Copy-pasting useCallback from Stack Overflow without a memo child is the most common wasted line I delete in review.

The single takeaway

useCallback stabilises functions; useMemo stabilises values. Both only matter when referential equality blocks wasted work. Profile first, memo second.

Related: React 19 features. Contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Zustand vs Redux Toolkit — Which State Manager in 2026?

Safdar Ali — Tue, 07 Jul 2026 18:30:00 +0000

Global state still matters in 2026 — but most pages should not need it. When they do, the debate is zustand vs redux 2026: Redux Toolkit (RTK) is the enterprise default; Zustand is the minimal store juniors actually read. I have shipped both on dashboards in production. This article implements the same counter plus async user fetch in each, compares bundle size, and ends with what I pick for new repos.

Zustand — counter and async fetch

// store/useAppStore.ts

import { create } from "zustand";

type User = { id: string; name: string } | null;

type State = {

  count: number;

  user: User;

  loading: boolean;

  increment: () => void;

  fetchUser: () => Promise<void>;

};

export const useAppStore = create<State>((set) => ({

  count: 0,

  user: null,

  loading: false,

  increment: () => set((s) => ({ count: s.count + 1 })),

  fetchUser: async () => {

    set({ loading: true });

    const res = await fetch("/api/me");

    const user = await res.json();

    set({ user, loading: false });

  },

}));

// components/CounterPanel.tsx

"use client";

import { useAppStore } from "@/store/useAppStore";

export function CounterPanel() {

  const count = useAppStore((s) => s.count);

  const increment = useAppStore((s) => s.increment);

  return <button onClick={increment}>Count: {count}</button>;

}

No providers, no slices folder — one file, selective subscriptions via selectors. That is why Zustand spreads on small teams.

The async fetch above is intentionally boring — no thunk middleware, just async/await inside the store action. For error handling you extend with try/catch and an error field; for retries you either wrap fetch or move the request to TanStack Query. Zustand does not prescribe async patterns, which is freedom or chaos depending on team discipline.

Redux Toolkit — same features, more structure

// store/appSlice.ts

import { createSlice, createAsyncThunk } from "@reduxjs/toolkit";

export const fetchUser = createAsyncThunk("app/fetchUser", async () => {

  const res = await fetch("/api/me");

  return res.json();

});

const appSlice = createSlice({

  name: "app",

  initialState: { count: 0, user: null as null | { id: string; name: string }, loading: false },

  reducers: {

    increment: (state) => { state.count += 1; },

  },

  extraReducers: (builder) => {

    builder

      .addCase(fetchUser.pending, (state) => { state.loading = true; })

      .addCase(fetchUser.fulfilled, (state, action) => {

        state.user = action.payload;

        state.loading = false;

      });

  },

});

export const { increment } = appSlice.actions;

export default appSlice.reducer;

// app/providers.tsx + useSelector in components

RTK removes classic Redux boilerplate but still needs a store provider, typed hooks, and slice conventions — worth it when ten engineers touch the same state graph.

// components/UserPanel.tsx — RTK async usage

"use client";

import { useEffect } from "react";

import { useAppDispatch, useAppSelector } from "@/store/hooks";

import { fetchUser, increment } from "@/store/appSlice";

export function UserPanel() {

  const dispatch = useAppDispatch();

  const count = useAppSelector((s) => s.app.count);

  const user = useAppSelector((s) => s.app.user);

  const loading = useAppSelector((s) => s.app.loading);

useEffect(() => {

    dispatch(fetchUser());

  }, [dispatch]);

return (

    <div>

      <button onClick={() => dispatch(increment())}>Count: {count}</button>

      {loading ? <p>Loading…</p> : <p>{user?.name ?? "Guest"}</p>}

    </div>

  );

}

Same UX as the Zustand panel — more files, clearer audit trail in Redux DevTools when a bug report says "count jumped to 99 after refresh." That traceability is why enterprise codebases keep RTK despite smaller alternatives.

Bundle size comparison (approximate, gzipped)

// Measured on a minimal Next.js 15 client chunk (2026, rough)

// zustand@5 alone          ~ 1.2 kB gzip

// @reduxjs/toolkit + react-redux ~ 12–14 kB gzip

// Note: RTK buys DevTools, middleware patterns, large-team norms

Numbers vary with tree-shaking and what you import. For a marketing site with one modal flag, neither library may be necessary — React context or URL state is enough. For a data-heavy dashboard, 12 kB might be cheap compared to engineering consistency.

Before you optimise kilobytes, profile real user metrics — I document that workflow in Next.js performance case study. A 10 kB store library rarely matters next to an unvirtualised table or a chart library. Still, greenfield SPAs with tight mobile budgets in India often pick Zustand because every gram of JS counts on 4G.

10-criteria comparison table

Criteria	Zustand	Redux Toolkit
Learning curve	Low	Medium
Boilerplate	Minimal	Structured
DevTools	Plugin available	Excellent native
Middleware	Custom, light	Mature ecosystem
Async patterns	You write it	createAsyncThunk
Team scale	Small–medium	Medium–large
Next.js App Router	Client-only store	Client-only store
Selectors	Inline functions	reselect / createSelector
Testing	Easy store reset	Well-documented patterns
Hiring familiarity in India	Growing fast	Still very common

Before and after — prop drilling vs store

// BEFORE — theme passed through five layers

<Layout theme={theme} setTheme={setTheme}>

  <Sidebar theme={theme} setTheme={setTheme}>

    <Nav theme={theme} setTheme={setTheme} />

// AFTER — Zustand (or RTK) at leaves only

const theme = useAppStore((s) => s.theme);

const setTheme = useAppStore((s) => s.setTheme);

Do not reach for a global store because props are annoying once — reach when multiple distant trees share writable state that is not server data.

Server state is not Redux or Zustand

API lists, pagination, cache invalidation — use TanStack Query or Server Components + fetch with cache tags. I see teams stuff fetch results into Redux out of habit; that duplicates what Next.js already solves on public pages — see SSR vs SSG vs ISR.

My production setup

New dashboard in 2026: Zustand for UI chrome (sidebar, filters, wizard step). RTK when joining a legacy codebase that already exports slices and middleware. At my day job, the RTK codebase had time-travel debugging worth the bytes; greenfield internal tools get Zustand in under an hour.

Pair with RSC boundaries — stores are client-only; never import them into Server Components.

The single takeaway

Zustand for new small/medium apps; RTK for large coordinated teams. Measure bundle impact, but optimise for maintainability. Most state should stay local or on the server.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

Tailwind CSS vs CSS Modules — What I Use in Production

Safdar Ali — Mon, 06 Jul 2026 18:30:00 +0000

Every new project sparks the same debate: utility classes or scoped CSS files? I ship Tailwind CSS on most Next.js marketing sites — including safdarali.in — but I still reach for CSS Modules when design tokens, animations, or designer handoff demand real stylesheets. This tailwind vs css modules comparison uses the same profile card in both approaches so you judge ergonomics, not different UIs.

Same component — Tailwind version

// components/ProfileCard.tsx

type Props = { name: string; role: string; avatarUrl: string };

export function ProfileCardTailwind({ name, role, avatarUrl }: Props) {

  return (

    <article className="flex gap-4 rounded-2xl border border-neutral-200 bg-white p-5 shadow-sm dark:border-white/10 dark:bg-neutral-900">

      <img

        src={avatarUrl}

        alt=""

        className="h-14 w-14 rounded-full object-cover ring-2 ring-neutral-200 dark:ring-white/20"

      />

      <div>

        <h3 className="font-semibold text-neutral-950 dark:text-white">{name}</h3>

        <p className="text-sm text-neutral-600 dark:text-neutral-400">{role}</p>

      </div>

    </article>

  );

}

No context switch — layout, colour, and dark mode sit on the JSX. Colocation is excellent when you iterate alone. Class strings get long on complex grids; I break into smaller components instead of one 200-character line.

On a Bengaluru startup landing page last quarter, the designer changed card padding three times in one sprint. With Tailwind I adjusted utilities in the same PR as copy changes — no hunting a separate CSS file. That speed is why I default to utilities for marketing. The tradeoff is readability in code review: reviewers must know common class names or rely on preview deploys.

Same component — CSS Modules version

// components/ProfileCard.module.css

.card {

  display: flex;

  gap: 1rem;

  padding: 1.25rem;

  border-radius: 1rem;

  border: 1px solid var(--border);

  background: var(--surface);

  box-shadow: 0 1px 2px rgb(0 0 0 / 0.06);

}

.avatar {

  width: 3.5rem;

  height: 3.5rem;

  border-radius: 9999px;

  object-fit: cover;

}

.name { font-weight: 600; }

.role { font-size: 0.875rem; color: var(--muted); }

// components/ProfileCard.tsx

import styles from "./ProfileCard.module.css";

export function ProfileCardModules({ name, role, avatarUrl }: Props) {

  return (

    <article className={styles.card}>

      <img src={avatarUrl} alt="" className={styles.avatar} />

      <div>

        <h3 className={styles.name}>{name}</h3>

        <p className={styles.role}>{role}</p>

      </div>

    </article>

  );

}

Designers reading Figma specs often prefer this — class names map to a stylesheet they can search. Theme variables live in one CSS file instead of duplicating dark: prefixes.

CSS Modules shine when you inherit a brand system documented as SCSS or plain CSS. I once joined a project where every spacing token lived in variables — rewriting into Tailwind would have taken weeks for zero user benefit. Modules let us wrap legacy styles with scoped class names while new React components shipped.

8-criteria comparison table

Criteria	Tailwind CSS	CSS Modules
Colocation with JSX	Excellent	Split files
Design system tokens	tailwind.config theme	CSS variables
Bundle size	Purged utilities (small)	Only used classes ship
Complex animations	Verbose in utilities	Natural in CSS
Onboarding juniors	Learn utility names	Learn CSS + scoping
Readable diffs	Long class strings	Cleaner CSS diffs
Third-party overrides	@apply or arbitrary	:global() when needed
Next.js default vibe	Very common	Built-in support

When Tailwind loses

Tailwind is not weak — it is the wrong tool when the stylesheet is the product. Long-form editorial layouts, printable invoices, and white-label themes where each tenant ships different CSS files are easier to reason about in modules or global layers than in thousands of arbitrary utility strings.

Keyframe-heavy animations — staggered reveals and complex hover chains read better in a module file. Print stylesheets — Tailwind can do it; CSS is clearer. Legacy design systems already documented in SCSS variables — rewriting into utilities is waste. Highly bespoke art-directed pages where every section has unique spacing not in your token scale — fighting arbitrary values is slower than writing CSS.

/* ProfileCard.module.css — animation Tailwind would fight */

@keyframes riseIn {

  from { opacity: 0; transform: translateY(12px); }

  to { opacity: 1; transform: translateY(0); }

}

.cardAnimated {

  animation: riseIn 0.4s ease-out both;

}

Migrating styles — before and after

// BEFORE — global CSS leaked into production

.button {

  background: blue;

}

// Every <button> on the site turned blue

// AFTER — CSS Modules scope automatically

// Button.module.css

.root { background: var(--brand); }

// Only <button className={styles.root}>

Tailwind avoids global leakage differently — utilities are atomic. Both beat unstructured global CSS from 2018 Create React App projects.

The hybrid I use on client sites

In production: Tailwind for layout, spacing, typography, responsive grids. CSS Modules (or a single globals.css) for animations, rare third-party overrides, and print rules. On a recent marketing rebuild, that split kept Lighthouse CSS payload small while designers still got a module for the hero animation — details in performance case study.

My production setup

Default stack: Next.js + TypeScript strict + Tailwind + cn() helper for conditional classes. I add modules per feature folder when a component accrues more than ~15 lines of custom CSS. At my day job, we banned new global selectors except resets.

Neither choice fixes bad component architecture — see Next.js folder structure guide for how I colocate styles with features.

I also run Prettier with the Tailwind class sorter plugin on teams that use utilities — consistent order makes long class strings diff cleanly. CSS Module projects get stylelint for nesting and variable naming instead.

The single takeaway

Tailwind for speed; CSS Modules for complexity. Pick per component, not per religion. Same card, two implementations — choose the file you will actually maintain six months from now.

Interview tip I give juniors in India: neither answer is wrong in isolation. Ask what the team already uses, whether designers pair with you daily, and whether the page is marketing or a long-lived dashboard. Match the toolchain to the delivery cadence, not Twitter polls.

Related: Projects. Contact.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

React 19 Features — What Actually Changed and What I Use

Safdar Ali — Sun, 05 Jul 2026 18:30:00 +0000

React 19 shipped a laundry list of features. Twitter threads treated every hook like mandatory. In production on client sites and this portfolio, I adopted a subset — the ones that remove real bugs or UX jank — and ignored the rest until the ecosystem caught up. This is my honest react 19 features guide: what changed, code you can paste, and what I am still waiting on.

What actually changed at a high level

React 19 stabilised the Actions model (forms and mutations with pending state), added useOptimistic for instant UI feedback, introduced the use() hook for reading promises and context, improved hydration error messages, and made ref-as-prop cleaner. The compiler (React Forget) is separate — exciting, not required to upgrade.

Upgrade path: Next.js 15 projects already pin compatible React versions. Read RSC vs client components before mixing Actions with Server Components — boundaries still matter.

React 19 hooks and APIs — quick reference table

API	Purpose	Client / Server	I use in prod?
useOptimistic	Optimistic UI while mutation runs	Client	Yes
use()	Read promise or context	Both (with Suspense)	Yes (with RSC)
useActionState	Form action state	Client	Yes
useFormStatus	Pending from parent form	Client	Yes
ref as prop	No forwardRef boilerplate	Both	Gradual
Document metadata	title, meta in components	Client (limited)	Prefer Next.js metadata

useOptimistic — instant feedback without lying to the user forever

Cart quantity updates, like buttons, todo toggles — users expect instant UI. useOptimistic shows the next state while the server catches up, then reconciles on success or rolls back on error.

"use client";

import { useOptimistic, useTransition } from "react";

import { updateQuantity } from "./actions";

type Item = { id: string; qty: number };

export function CartLine({ item }: { item: Item }) {

  const [optimisticQty, setOptimisticQty] = useOptimistic(item.qty);

  const [isPending, startTransition] = useTransition();

function changeQty(next: number) {

    startTransition(async () => {

      setOptimisticQty(next);

      await updateQuantity(item.id, next);

    });

  }

return (

    <div>

      <button onClick={() => changeQty(optimisticQty + 1)} disabled={isPending}>

        +

      </button>

      <span>{optimisticQty}</span>

    </div>

  );

}

// BEFORE — manual optimistic state with footguns

const [qty, setQty] = useState(item.qty);

const [pending, setPending] = useState(false);

async function bump() {

  const prev = qty;

  setQty(qty + 1); // optimistic

  setPending(true);

  try {

    await updateQuantity(item.id, qty + 1);

  } catch {

    setQty(prev); // easy to forget rollback paths

  } finally {

    setPending(false);

  }

}

// AFTER — useOptimistic + transition: rollback wired correctly

use() — promises and context without useEffect hacks

// Server Component passes a promise to client child

import { use } from "react";

type Product = { id: string; name: string };

function ProductList({ productsPromise }: { productsPromise: Promise<Product[]> }) {

  const products = use(productsPromise); // suspends until resolved

  return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name}</li>

      ))}

    </ul>

  );

}

// Parent (Server Component) creates the promise once

export default function Page() {

  const productsPromise = getProducts(); // do not await here

  return (

    <Suspense fallback={<p>Loading products…</p>}>

      <ProductList productsPromise={productsPromise} />

    </Suspense>

  );

}

In production I use use() with Server Components streaming data — same mental model as async server fetch, less client useEffect spaghetti.

Actions and forms — less boilerplate than manual fetch

"use client";

import { useActionState } from "react";

import { subscribe } from "./actions";

export function NewsletterForm() {

  const [state, formAction, pending] = useActionState(subscribe, { ok: false, message: "" });

return (

    <form action={formAction}>

      <input name="email" type="email" required />

      <button disabled={pending}>{pending ? "Sending…" : "Subscribe"}</button>

      {state.message && <p>{state.message}</p>}

    </form>

  );

}

Pair with Next.js Server Actions for mutations without a separate API route file — still validate on the server, still treat client state as untrusted.

What I immediately adopted

useOptimistic on any user-facing mutation where latency is felt on Indian mobile networks. useActionState / useFormStatus on marketing forms — fewer lines than custom pending flags. use() with Suspense boundaries on catalog sections fed from server promises. Better hydration errors — saved me an hour debugging a client-only chart imported into a Server Component (fixed by splitting the leaf).

// ref as prop — dropped forwardRef on new components

type ButtonProps = React.ComponentProps<"button"> & { ref?: React.Ref<HTMLButtonElement> };

export function Button({ ref, ...props }: ButtonProps) {

  return <button ref={ref} {...props} />;

}

What I'm waiting on

React Compiler (Forget) — I will enable it per-route after stable Next.js integration docs, not on day one of React 19. Document metadata in client trees — I still use Next.js generateMetadata for SEO. Full ecosystem typings — some third-party libs lagged React 19 types for weeks; I pinned versions until they caught up.

I am also not rewriting every forwardRef component overnight — new code uses ref-as-prop; old code migrates on touch.

Waiting is a strategy, not laziness. The compiler will change how much manual memo we write — see my useCallback vs useMemo guide for why I am not adding more memo hooks while the ecosystem catches up.

My production setup

In production: React 19 + Next.js 15, Server Components by default, React 19 Actions on forms that need pending UX, optimistic updates on commerce interactions. Performance work still lives in caching and bundle size — see Next.js performance case study.

When experimenting, I use the workflow in Cursor + Claude for React — AI suggests React 19 APIs quickly, but I verify against official release notes before merge.

The single takeaway

React 19 is not a rewrite mandate. Adopt optimistic UI, Actions, and use() where they solve problems you already have. Wait on compiler and metadata experiments until your stack documents them.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

SSR vs SSG vs ISR in Next.js — Plain English Explanation

Safdar Ali — Sun, 05 Jul 2026 15:42:29 +0000

I'm Safdar Ali. For six months I treated every Next.js page like SSR because "server" sounded safest. Marketing pages were slower than they needed to be; dashboard pages were over-cached. SSR vs SSG in Next.js is not a popularity contest — it is a delivery choice: when HTML is built, how often it refreshes, and who pays the compute bill. This article is the plain-English map I wish I had, with code for all three modes and a flowchart you can screenshot.

Three acronyms, one question: when is HTML built?

SSR (Server-Side Rendering) builds HTML on each request (or per-request cache miss). Fresh data, higher server load.

SSG (Static Site Generation) builds HTML at deploy time. Fastest CDN delivery; stale until you redeploy unless you add revalidation.

ISR (Incremental Static Regeneration) is SSG plus background refresh — static speed with a TTL. In App Router this is mostly fetch with next.revalidate.

// Mental model — same page, three delivery timings

// SSG:  HTML built at deploy ──────────────────► CDN serves file

// ISR:  HTML built at deploy ──► stale ──► regen in background after N sec

// SSR:  HTML built when user hits URL ─────────► server sends fresh HTML

None of these replace React. They describe when your React tree becomes HTML the browser can paint before hydration.

Decision flowchart — which mode to pick

                    START: New Next.js page

                              |

                              v

                    Does Google need HTML

                    with real content on

                    first request?

                         /        \

                       NO          YES

                       |            |

                       v            v

              Authenticated      Is data identical

              dashboard / SPA?   for all users?

                    |                 /      \

                   YES               NO      YES

                    |                |        |

                    v                v        v

            "use client" +       SSR or      Changes

            client fetch         per-user    every hour+

            (no SSR win)         data?          /    \

                                /    \        NO    YES

                              YES    NO        |      |

                               |      |        v      v

                               v      v       SSG    ISR

                              SSR   ISR      (rare) (revalidate)

                                    or SSG

                                    + short

                                    revalidate

Print that flowchart. When you are unsure, default marketing to ISR with a sensible revalidate, default logged-in dashboards to client rendering.

SSG — build once, serve from the edge

Use SSG for pages where data changes only when you deploy — legal pages, about pages, rarely updated landing heroes.

// app/about/page.tsx — static by default (no fetch cache opts)

export default function AboutPage() {

  return (

    <main>

      <h1>About Safdar Ali</h1>

      <p>Frontend engineer, Bengaluru — available for React / Next.js work.</p>

    </main>

  );

}

// Dynamic routes can still be SSG if you export generateStaticParams

export async function generateStaticParams() {

  const slugs = await getAllBlogSlugs();

  return slugs.map((slug) => ({ slug }));

}

Tradeoff: a price change on an e-commerce SKU list will not appear until redeploy or ISR kicks in. For truly static content, that is a feature — zero origin load.

ISR — static speed, controlled freshness

// app/products/page.tsx — ISR via fetch revalidate (App Router)

type Product = { id: string; name: string; price: number };

async function getProducts(): Promise<Product[]> {

  const res = await fetch("https://api.example.com/products", {

    next: { revalidate: 3600 }, // ISR: refresh at most every hour

  });

  if (!res.ok) throw new Error("Failed to load products");

  return res.json();

}

export default async function ProductsPage() {

  const products = await getProducts();

  return (

    <ul>

      {products.map((p) => (

        <li key={p.id}>{p.name} — ₹{p.price}</li>

      ))}

    </ul>

  );

}

First visitor after TTL might still see stale HTML while regeneration runs — acceptable for catalog pages, unacceptable for live stock tickers. Know your freshness requirement before picking ISR.

SSR — per-request HTML when data must be fresh

// app/dashboard/summary/page.tsx — SSR: no cache on fetch

async function getSummary(userId: string) {

  const res = await fetch("https://api.example.com/summary/" + userId, {

    cache: "no-store", // SSR — always fresh for this user

  });

  return res.json();

}

export default async function SummaryPage() {

  const session = await getSession();

  const summary = await getSummary(session.userId);

  return <SummaryClient data={summary} />;

}

SSR costs more at scale. Use it when personalisation or real-time correctness beats CDN economics — not because "server sounds professional."

SSR vs SSG vs ISR — comparison table

Criteria	SSG	ISR	SSR
When HTML is built	Deploy time	Deploy + periodic regen	Each request
TTFB on CDN	Fastest	Fast (often cached)	Slower
Data freshness	Stale until deploy	TTL-based	Real-time
Server cost	Lowest	Low–medium	Highest
SEO	Excellent	Excellent	Excellent
Per-user data	Poor fit	Poor fit	Good fit
App Router signal	Default static page	revalidate: N	cache: no-store

Marketing site vs dashboard — what I actually ship

Marketing site (public, SEO, shared content): ISR for blog and product listings, SSG for about/legal, Server Components for HTML. On a client rebuild I moved the blog to revalidate: 86400 and saw origin requests drop 70% — part of the story in my Next.js performance case study.

Dashboard (authenticated, personal): client components, SWR or WebSockets, no ISR fantasy. Trying to ISR user-specific charts is how teams waste a sprint.

// BEFORE — marketing page forced to SSR "just because"

export default async function PricingPage() {

  const plans = await fetch("https://api.example.com/plans", { cache: "no-store" });

  // Every visitor hits origin — same JSON for everyone

}

// AFTER — ISR: shared plans, CDN-friendly

export default async function PricingPage() {

  const res = await fetch("https://api.example.com/plans", { next: { revalidate: 3600 } });

  const plans = await res.json();

  // ...

}

My production setup

In production I label routes in file comments — ISR 1h or SSR session — so the next developer does not "optimise" a dashboard into ISR by accident. Pair this with RSC vs client components — rendering mode and component boundary are two separate decisions.

At my day job, the mistake I see most is SSR everywhere because the team learned Pages Router getServerSideProps first. App Router caching is more granular — use it.

The single takeaway

Pick rendering by freshness and audience, not acronym prestige. Marketing: ISR + SSG. Dashboards: client. Personalised SSR only when you mean it.

If this helped you

I publish free tutorials and write-ups like this in my spare time — no paywall on the guides. If it saved you an afternoon of trial and error, you can support the work:

→ Buy me a coffee at buymeacoffee.com/safdarali
👉 Subscribe to my YouTube channel — it's free; 70+ React & Next.js tutorials

More guides on safdarali.in — same author, production-focused.

DEV Community: Safdar Ali

Prisma + PostgreSQL + Next.js — Full Stack Setup Guide

Prerequisites and project bootstrap

.env

Schema design — models that match your UI

Migrations — dev flow vs production

Generate client after schema changes

Production (CI script)

Prisma client singleton — avoid connection exhaustion

Server queries in App Router — read path

Mutations — Server Actions with Prisma

BEFORE / AFTER — raw SQL vs Prisma in a Next.js route

Seeding local data — realistic dev without production dumps

Run after migrate dev

Deploy checklist — connection pooling on serverless

.env.production — pooled URL example (Neon)

Production habits that save you on call

PHP2Shell: what the two critical PHP RCE CVEs actually mean for your stack

What to actually do today

A stopgap, not a fix

If you manage sites for other people

How AI Changed the Way I Write React Code — 2 Years In

What actually changed in my daily work

What did not change — and probably never will

Skills that matter more now — ranked honestly

Before and after — same feature, two eras

What this means if you are learning React in India

Mistakes I made adopting AI too fast

My weekly rhythm with AI in 2026

Where ai react development goes from here

The single takeaway

Related reading

Vibe Coding in 2026 — Is It Real or Just a Trend?

Free Video Thumbnail Generator Online — No Upload

Jev Is Not an LLM. That Is the Point.

What you are actually calling

Put the question on the type, not in the prompt

Confidence is the part you branch on

Where it fits, and where it does not

A small architecture, not a new model in every slot

☕ If This Helped You

Next.js App Router Complete Beginner Guide 2026

Mental model — folders are routes

Step 1 — Root layout (HTML shell once)

Step 2 — First page

Step 3 — loading.tsx for perceived speed

Step 4 — Server Component fetch (no useEffect)

App Router files — quick comparison table

Step 5 — Add client components only as leaves

Step 6 — Dynamic routes and params

Learning path after this guide

My production setup

The single takeaway

Related reading

Free Video Thumbnail Generator Online — No Upload

Why Your Next.js 15 App is Still Slow (And How to Fix the React 19 Hydration Lag)

WCAG 2.2 Accessibility for React Developers — Practical Guide

How I Structure Large Next.js Projects — Folder Architecture Guide

Real folder tree — production-shaped layout

Why each folder exists

Thin pages — route files under 40 lines

The 10-second findability rule

First project mistakes I made

Route groups for different shells

Path aliases and import direction

My production setup

The single takeaway

Related reading

How to Build a Frontend Developer Portfolio That Stands Out

React Server Components vs Client Components — When to Use Which

React useCallback vs useMemo — When You Actually Need Them

What each hook actually does

The over-memoising mistake I made

How I use the React Profiler

When to use which — table

useCallback — legitimate use with memoised child

useMemo — filtering large lists

Rule of thumb I teach in reviews

My production setup

The single takeaway