04 · Server Actions ("use server")

• Server Actions are the mutation boundary callable from the UI.
• They orchestrate: validate → authorize → call entity action → revalidate.
• No Prisma here; data authority stays in entity actions.

"use server";


import { createProject } from "./actions/createProject";

import { getSession } from "@/auth";

import { revalidatePath, revalidateTag } from "next/cache";


export async function createProjectAction(formData: FormData) {

  const session = await getSession();

  if (!session) throw new Error("Unauthorized"); // security


  await createProject(formData, session.user.id);

  revalidatePath("/projects"); // re-render route

  revalidateTag("projects"); // bust cache tag

}

• Server Action: callable by UI, no Prisma, orchestrates + revalidates.
• Entity Action: owns Prisma, validation, authorization; not called by UI directly.
• Keep mutations thin at server-action layer; keep rules/DB in entity actions.

• Every Server Action is automatically exposed as a POST endpoint — externally callable if the route is known.
• Implication: always authorize at the top of every action. Do not rely on UI-only guards.
• Use session checks (getSession()), role gates (requireAdmin()), and input validation (Zod.parse()) on every action.
• Server Actions are for UI-triggered mutations only. For webhooks/external integrations, use Route Handlers with signature verification.
• revalidateTag() is finer-grained than revalidatePath() — prefer tagged cache invalidation for data-dependent routes.