Server Actions
All Next.js topics∙ Next.js
Server Actions are server functions that can be invoked from forms or client transitions to perform mutations. This lesson explains how it works, when to use it, how to implement it safely, and how to verify the result.
Syntax
'use server';
export async function createTask(formData: FormData) {}Example
// Topic: Server Actions
'use server';
export async function createTask(formData: FormData) {
const title = String(formData.get('title') ?? '').trim();
if (!title) return { error: 'Title is required' };
await db.task.create({ data: { title } });
revalidatePath('/tasks');
}Expected Output
The task is saved and /tasks is refreshed.Line-by-line
| Line | Meaning |
|---|---|
'use server'; | Restricts exported action functions in this module to server execution. |
export async function createTask(formData: FormData) { | Forms part of the component, server operation, or configuration shown above. |
const title = String(formData.get('title') ?? '').trim(); | Stores a value used later in the example. |
if (!title) return { error: 'Title is required' }; | Checks a required condition before continuing. |
await db.task.create({ data: { title } }); | Forms part of the component, server operation, or configuration shown above. |
revalidatePath('/tasks'); | Invalidates cached output so the updated data appears. |
} | Forms part of the component, server operation, or configuration shown above. |
Real-World Uses
- 1Server Actions is useful for dashboards, forms, search, APIs, database-backed pages, and server-side mutations.
- 2Next.js sends the action request to the server, where code can validate input, check permission, update data, and revalidate affected routes.
- 3A team should use it when the requirement matches its responsibility in data handling.
- 4It should fit the surrounding route, data, security, and deployment design instead of being added in isolation.
- 5A successful implementation is visible through correct data, clear failure states, safe mutations, and efficient requests.
Common Mistakes
- 1The "use server" directive does not automatically make a mutation authorized or validated.
- 2Copying an example without identifying which code runs on the server and which code reaches the browser.
- 3Handling only the happy path and forgetting loading, empty, invalid, unauthorized, and failed states.
- 4Adding client state or third-party libraries before confirming that built-in Next.js and browser features are insufficient.
- 5Skipping verification in a production build, where caching and runtime behavior can differ from development.
Best Practices
- 1Treat every action as a public server endpoint: authenticate, authorize, validate, handle duplicate submission, and return safe errors.
- 2Keep the owning route, component, server function, and validation responsibility easy to identify.
- 3Use server-side code for trusted data and secrets; send only the data required by interactive browser components.
- 4Make loading, empty, success, and error states explicit for the user.
- 5Test valid input, invalid input, an unauthorized user, duplicate submission, failure recovery, and cache refresh after success.
What it means
- 1Server Actions are server functions that can be invoked from forms or client transitions to perform mutations.
- 2The important question is not only what syntax to write, but what responsibility this feature owns.
- 3Its behavior should be understood in development, during a production build, and after deployment.
- 4Before implementing it, decide what input it receives, what result it produces, and how failure is shown.
How it works
- 1Next.js sends the action request to the server, where code can validate input, check permission, update data, and revalidate affected routes.
- 2Next.js uses file and component boundaries to decide routing, server execution, browser execution, and caching.
- 3Data should cross each boundary in a small, serializable, and validated form.
- 4The final result should remain understandable when a user refreshes the page or opens the URL directly.
Step-by-step approach
- 1Create the smallest route or component that demonstrates Server Actions.
- 2Add one realistic input or data source and show the successful result.
- 3Add the most likely failure case and display a useful response.
- 4Run this check: Test valid input, invalid input, an unauthorized user, duplicate submission, failure recovery, and cache refresh after success.
Production checklist
- 1Confirm server-only values and secrets never enter the browser bundle.
- 2Confirm direct URLs, refreshes, loading states, and errors behave correctly.
- 3Confirm caching and revalidation match the required data freshness.
- 4Measure the result using correct data, clear failure states, safe mutations, and efficient requests.
Quick Summary
- Server Actions are server functions that can be invoked from forms or client transitions to perform mutations.
- Next.js sends the action request to the server, where code can validate input, check permission, update data, and revalidate affected routes.
- Recommended approach: Treat every action as a public server endpoint: authenticate, authorize, validate, handle duplicate submission, and return safe errors.
- Main mistake to avoid: The "use server" directive does not automatically make a mutation authorized or validated.
- Verify it by doing the following: Test valid input, invalid input, an unauthorized user, duplicate submission, failure recovery, and cache refresh after success.
Interview Questions
Q1. What is Server Actions?
Answer: Server Actions are server functions that can be invoked from forms or client transitions to perform mutations.
Q2. How does Server Actions work in Next.js?
Answer: Next.js sends the action request to the server, where code can validate input, check permission, update data, and revalidate affected routes.
Q3. When should you use Server Actions?
Answer: Use it for dashboards, forms, search, APIs, database-backed pages, and server-side mutations, when that responsibility belongs inside the Next.js application.
Q4. What is a common mistake with Server Actions?
Answer: The "use server" directive does not automatically make a mutation authorized or validated.
Q5. How would you test Server Actions?
Answer: Test valid input, invalid input, an unauthorized user, duplicate submission, failure recovery, and cache refresh after success. The result should demonstrate correct data, clear failure states, safe mutations, and efficient requests.
Quiz
Which approach is best when implementing Server Actions?