Server Components, Server Actions & Route Handlers: where code runs

In the Next.js 16 App Router, every file you write is one of four kinds, and the kind decides where it runs and who can call it:

One page uses three of them:

// app/posts/[id]/page.tsx — Server Component: async, reads the database directly
import { getPost } from "@/data/posts";
import { LikeButton } from "./like-button";

export default async function Page({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const post = await getPost(id); // the query runs on the server and never ships to the browser
  return (
    <article>
      <h1>{post.title}</h1>
      <LikeButton postId={id} initialLikes={post.likes} />
    </article>
  );
}

// app/posts/[id]/like-button.tsx — Client Component: state and a click handler
"use client";
import { useState } from "react";
import { likePost } from "./actions";

export function LikeButton({ postId, initialLikes }: { postId: string; initialLikes: number }) {
  const [likes, setLikes] = useState(initialLikes);
  return <button onClick={async () => setLikes(await likePost(postId))}>Like ({likes})</button>;
}

// app/posts/[id]/actions.ts — Server Action: the click becomes a network request
"use server";
export async function likePost(postId: string): Promise<number> {
  // check who is asking, write the like, return the new count
}

The split follows from what each environment has. A Server Component runs once to produce output: there is no "later" on the server, so no useState, no useEffect, no onClick. In exchange it can be async, await a query, and read secrets from process.env. Anything that needs to react to the user lives behind 'use client'.

params is a Promise: since Next 15 route params are async, and Next 16 removed the old synchronous access.

A realistic edit screen in Next.js 16: a Server Component loads the post, a Client Component renders the form, and a Server Action saves it.

// app/posts/[id]/edit/page.tsx
import { notFound } from "next/navigation";
import { getPostForEditing } from "@/data/posts"; // server-only: checks session + ownership
import { EditForm } from "./edit-form";
import { updatePost } from "./actions";

export default async function EditPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const post = await getPostForEditing(id); // null when missing or not yours
  if (!post) notFound();
  return <EditForm post={{ id: post.id, title: post.title }} action={updatePost} />;
}

// app/posts/[id]/edit/edit-form.tsx
"use client";
import { useActionState } from "react";

type State = { error?: string };
type Props = {
  post: { id: string; title: string };
  action: (prev: State, data: FormData) => Promise<State>;
};

export function EditForm({ post, action }: Props) {
  const [state, formAction, pending] = useActionState(action, {});
  return (
    <form action={formAction}>
      <input type="hidden" name="id" value={post.id} />
      <input name="title" defaultValue={post.title} />
      <button disabled={pending}>{pending ? "Saving…" : "Save"}</button>
      {state.error && <p role="alert">{state.error}</p>}
    </form>
  );
}

// app/posts/[id]/edit/actions.ts
"use server";
import { redirect } from "next/navigation";
import { revalidatePath } from "next/cache";
import { auth } from "@/lib/auth";
import { db } from "@/lib/db";

export async function updatePost(_prev: { error?: string }, formData: FormData) {
  const session = await auth();
  if (!session) return { error: "Please sign in again." };

  const id = String(formData.get("id"));
  const title = String(formData.get("title") ?? "").trim();
  if (title.length < 1 || title.length > 120) return { error: "Title must be 1–120 characters." };

  const post = await db.post.findUnique({ where: { id } });
  if (!post || post.authorId !== session.user.id) return { error: "Not allowed." };

  await db.post.update({ where: { id }, data: { title } });
  revalidatePath(`/posts/${id}`);
  redirect(`/posts/${id}`);
}

Why each piece is the way it is:

• post={{ id, title }}, not post={post}. Props are serialised into the page; the whole row would put every column in the browser. Pass what the form renders.
• action={updatePost}. A Server Function is the one kind of function allowed to cross the client boundary as a prop.
• useActionState(action, {}) returns [state, formAction, pending], and the action is called as (previousState, formData). Returning { error } puts the message on screen without throwing.
• The action checks the session and the owner again. The page's check in getPostForEditing decided what to render. The action is a separate entry point: anyone can POST any id to it, so without the authorId check this is an IDOR hole.
• String(formData.get(...)) and the length check. Form values arrive as strings typed by the client. Validate before they reach the database.
• revalidatePath before redirect. redirect() throws, so nothing after it runs. In a Server Action the action's POST answers 303 See Other, the status meant for "POST done, now GET this". Before hydration (a native form post) it carries Location and the browser follows it; after hydration it carries an x-action-redirect header instead, and the client router navigates (Next 16.2).

When the browser calls a Server Action, Next's client sends POST to the current page's URL with a Next-Action header naming the action. There is no /api/actions/updatePost route. Three production consequences follow from that one fact.

1. It is reachable without your UI. Anyone can replay that POST with different arguments. Next makes action IDs hard to guess (encrypted, regenerated between builds) and drops unused actions from the build, and the docs still say: treat every action as a public endpoint.

export default async function AdminPage() {
  const session = await auth();
  if (!session?.user.isAdmin) redirect("/login"); // decides what to RENDER

  async function deleteAll() {
    "use server";
    // ❌ no check here: the page's redirect can't stop a direct call
    await db.record.deleteMany();
  }
  return <form action={deleteAll}><button>Delete all</button></form>;
}

The page-level redirect gates the HTML. The action is a separate entry point, so it needs its own auth() check, and an ownership check whenever it touches one record (post.authorId === session.user.id), or any signed-in user can edit anyone's data by changing an id.

2. proxy.ts runs for it — and can eat it. Proxy (Next 16's name for middleware.ts) sees the action as a POST to the page's path. A redirect written for page visits answers the action too:

// proxy.ts — "signed-in users don't need the sign-up page"
if (pathname === "/signup" && request.cookies.has("session")) {
  return NextResponse.redirect(new URL("/", request.url)); // also hits POST /signup
}

If the browser-side sign-up sets the session cookie and the page then calls createProfile(), that POST to /signup now carries the cookie, gets a 307, and the action never runs. The page looks fine; the profile row is simply never written. The fix is to redirect only page visits:

const isPageVisit = request.method === "GET" || request.method === "HEAD";
if (isPageVisit && pathname === "/signup" && request.cookies.has("session")) { … }

The reverse also holds: the docs warn that a matcher which excludes a path also skips every action on that path, so a refactor can silently remove proxy coverage. Another reason the auth check belongs inside the action.

3. The origin is checked. Next compares the request's Origin with Host (or X-Forwarded-Host) and aborts a mismatch. Behind a reverse proxy with a different public host, list it in experimental.serverActions.allowedOrigins. (CSRF itself is the Web Security track's subject.)