I’ve been thinking about this a lot lately. Every time I build a form in Next.js, I find myself writing the same boilerplate—API routes, validation logic, error handling. It feels like I’m repeating myself. Then Next.js 14 introduced Server Actions, and everything changed. I want to show you how I’ve been using them to build production-ready features without all that repetitive code.
Server Actions let you write server-side code that runs when called from your components. Think of them as functions that live on the server but can be triggered from the browser. No more creating separate API routes for every little operation.
Why does this matter? Because it simplifies your codebase dramatically. You write less code, get better type safety, and your forms work even when JavaScript fails. That last point is crucial for accessibility and reliability.
Let me show you how I set things up. First, I create a validation schema using Zod. This ensures data is correct before it even reaches my database.
// lib/validations/user.ts
import { z } from 'zod';
export const userSchema = z.object({
email: z.string().email('Please enter a valid email'),
name: z.string().min(2, 'Name must be at least 2 characters'),
age: z.number().min(18, 'You must be at least 18 years old')
});This schema does more than just check types. It provides clear error messages when validation fails. Notice how specific each rule is? That’s intentional. Good error messages make for better user experiences.
Now, here’s where things get interesting. I create a Server Action that uses this schema.
// app/actions/user.ts
'use server';
import { userSchema } from '@/lib/validations/user';
export async function createUser(formData: FormData) {
const rawData = {
email: formData.get('email'),
name: formData.get('name'),
age: Number(formData.get('age'))
};
const result = userSchema.safeParse(rawData);
if (!result.success) {
return {
errors: result.error.flatten().fieldErrors
};
}
// Database logic here
console.log('Valid data:', result.data);
return { success: true };
}Did you notice the 'use server' directive at the top? This tells Next.js this function should only run on the server. It’s a security feature that prevents client-side execution.
Here’s a question for you: What happens when validation fails in your current forms? Do users get clear feedback, or do they see generic error messages?
The safeParse method is key here. Instead of throwing an error immediately, it returns an object telling us whether validation passed or failed. This gives us control over how we handle errors.
Now let’s look at how I use this action in a component.
// app/components/user-form.tsx
'use client';
import { createUser } from '@/app/actions/user';
import { useActionState } from 'react';
export function UserForm() {
const [state, formAction, isPending] = useActionState(createUser, null);
return (
<form action={formAction}>
<div>
<label htmlFor="email">Email</label>
<input type="email" id="email" name="email" required />
{state?.errors?.email && (
<p className="error">{state.errors.email[0]}</p>
)}
</div>
<button type="submit" disabled={isPending}>
{isPending ? 'Creating...' : 'Create User'}
</button>
</form>
);
}The useActionState hook gives us three things: the action’s return value, a function to call the action, and a loading state. This pattern feels familiar if you’ve used React’s useState, but it’s specifically designed for Server Actions.
Notice how the form works without any JavaScript? That’s progressive enhancement in action. The form will submit normally, then the page will refresh with results. If JavaScript loads, we get the enhanced experience with instant validation and no page refresh.
But what about more complex scenarios? Let’s say you need to update data after an action completes. That’s where revalidation comes in.
// app/actions/user.ts
'use server';
import { revalidatePath } from 'next/cache';
import { userSchema } from '@/lib/validations/user';
export async function updateUser(id: string, formData: FormData) {
// Validation logic here
// Update database here
revalidatePath('/users');
revalidatePath(`/users/${id}`);
return { success: true };
}The revalidatePath function tells Next.js which pages need fresh data. When you update a user, you want both the user list and the individual user page to show the latest information. This keeps your UI in sync with your database.
Here’s something I struggled with at first: error handling. Server Actions can fail for many reasons—validation errors, database errors, network issues. I needed a consistent way to handle all these cases.
// lib/errors.ts
export class ActionError extends Error {
constructor(
message: string,
public code: string,
public status: number = 400
) {
super(message);
}
}
export function handleError(error: unknown) {
if (error instanceof ActionError) {
return {
error: error.message,
code: error.code,
status: error.status
};
}
if (error instanceof Error) {
console.error('Unexpected error:', error);
return {
error: 'Something went wrong',
code: 'UNKNOWN_ERROR',
status: 500
};
}
return {
error: 'An unknown error occurred',
code: 'UNKNOWN_ERROR',
status: 500
};
}This error handling approach gives me consistency across all my Server Actions. Every error has a message, a code for debugging, and a status code. The code is particularly useful for testing and logging.
Speaking of testing, how do you test Server Actions? They’re server-side functions, so you can test them like any other function.
// tests/actions/user.test.ts
import { createUser } from '@/app/actions/user';
import { ActionError } from '@/lib/errors';
describe('createUser', () => {
it('validates email format', async () => {
const formData = new FormData();
formData.set('email', 'not-an-email');
formData.set('name', 'Test User');
formData.set('age', '25');
const result = await createUser(formData);
expect(result.errors?.email).toBeDefined();
});
it('throws for duplicate emails', async () => {
// Mock database to return existing user
const formData = new FormData();
formData.set('email', '[email protected]');
formData.set('name', 'Test User');
formData.set('age', '25');
await expect(createUser(formData))
.rejects
.toThrow(ActionError);
});
});Testing Server Actions is straightforward because they’re just functions. You pass them input and check their output or errors. The key is mocking any external dependencies like databases or APIs.
Now, here’s a practical consideration: file uploads. How do you handle them with Server Actions?
// app/actions/upload.ts
'use server';
import { writeFile } from 'fs/promises';
import { join } from 'path';
export async function uploadFile(formData: FormData) {
const file = formData.get('file') as File;
if (!file) {
return { error: 'No file provided' };
}
const bytes = await file.arrayBuffer();
const buffer = Buffer.from(bytes);
const path = join(process.cwd(), 'public', 'uploads', file.name);
await writeFile(path, buffer);
return { success: true, path: `/uploads/${file.name}` };
}File handling works similarly to other form data. You get the file from the FormData, convert it to a buffer, and save it wherever you need. The File API is standard web platform stuff, so it feels familiar.
But wait—what about security? Server Actions run on the server, but they’re called from the client. How do you prevent unauthorized access?
// app/actions/admin.ts
'use server';
import { cookies } from 'next/headers';
import { verifySession } from '@/lib/auth';
export async function adminAction(formData: FormData) {
const cookieStore = cookies();
const session = cookieStore.get('session');
if (!session || !verifySession(session.value)) {
return { error: 'Unauthorized' };
}
// Proceed with admin action
return { success: true };
}You check authentication the same way you would in any server-side code. Read cookies, verify sessions, check permissions. The server context is available to Server Actions, so you have access to all the usual server-side APIs.
Here’s something that took me a while to understand: Server Actions work with both Client and Server Components. In Server Components, you can import and call them directly. In Client Components, you need to pass them as props or use them with form actions.
// app/page.tsx (Server Component)
import { getUsers } from '@/app/actions/user';
import { UserTable } from '@/app/components/user-table';
export default async function Home() {
const users = await getUsers();
return <UserTable users={users} />;
}The getUsers action runs on the server when the page renders. No client-side JavaScript is involved. This is perfect for data that doesn’t change often or doesn’t need interactivity.
But what if you need real-time updates? That’s where things get interesting. You can combine Server Actions with other patterns.
// app/components/real-time-form.tsx
'use client';
import { updateUser } from '@/app/actions/user';
import { useOptimistic } from 'react';
export function RealTimeForm({ user }) {
const [optimisticUser, setOptimisticUser] = useOptimistic(
user,
(current, updates) => ({ ...current, ...updates })
);
async function handleSubmit(formData: FormData) {
setOptimisticUser({ name: formData.get('name') });
await updateUser(user.id, formData);
}
return (
<form action={handleSubmit}>
<input
name="name"
defaultValue={optimisticUser.name}
/>
<button type="submit">Update</button>
</form>
);
}The useOptimistic hook lets you show immediate UI updates while the Server Action runs in the background. Users see changes right away, then the server confirms them. If the server action fails, you can roll back the optimistic update.
This pattern makes your app feel fast and responsive. Users don’t wait for server responses to see changes. Have you noticed how modern apps feel instant, even when they’re making network requests? This is how they do it.
Let me share one more pattern I find useful: batching related actions.
// app/actions/batch.ts
'use server';
import { revalidatePath } from 'next/cache';
export async function batchUpdate(updates: Array<{id: string, data: FormData}>) {
const results = [];
for (const update of updates) {
// Process each update
results.push(await processUpdate(update));
}
revalidatePath('/items');
return { success: true, results };
}Sometimes you need to update multiple items at once. Instead of making separate requests for each, you batch them together. This reduces network overhead and keeps things atomic—either all updates succeed or none do.
Server Actions have changed how I think about full-stack development. They remove so much of the friction between frontend and backend code. I write a function, and it just works—on the server, with type safety, good error handling, and progressive enhancement.
The best part? This is all built into Next.js. No extra libraries, no complicated setup. Just good patterns that make your code better.
I’m curious—how would you use Server Actions in your current project? What repetitive code could they replace? Share your thoughts in the comments below. If you found this helpful, please like and share it with other developers who might benefit from these patterns.
As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!
101 Books
101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.
Check out our book Golang Clean Code available on Amazon.
Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!
📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!
Our Creations
Be sure to check out our creations:
Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
