Next.js (App Router) + Server Actions: Breaking Free from API Routes to Elevate Your Development Experience

"Are you still writing API Routes?"

Take a moment to look back at your codebase. Have you ever asked yourself that question? Although the Next.js App Router has been in wide use for some time, many projects are still accumulating technical debt—such as redundant type definitions and unnecessary fetch logic—simply because "API Routes feel familiar" or "Server Actions seem unstable."

Server Actions are not just a convenient feature. By connecting the frontend and backend through the unit of a "function," they fundamentally overhaul long-standing hurdles in web development, such as communication overhead and the lack of type safety. In this article, based on my own experiences, I will discuss the essential design considerations for implementing Server Actions and how to clearly distinguish when to use them versus API Routes.

---

1. Why You Should Move Away from "API Routes"

Traditional API Route development often carries the risk of "fragmented type safety." To share types between the frontend and backend, developers are often forced to manually synchronize `trpc` or `zod` schemas and run type checks in CI. While these methods are valid, they represent a significant cost just to maintain the "ritual" of network communication.

With Server Actions, that ritual disappears. You call functions on the server directly from the client. Arguments are serialized, and return values are automatically type-inferred. This "direct connection" is the key to dramatically accelerating development speed.

---

2. Implementation Best Practices: Separating Domain Logic

Hard-coding business logic directly into Server Actions is a shortcut that compromises your project's longevity. To avoid tightly coupling components with logic, I strongly recommend implementing a Service Layer.

Recommended Directory Structure

src/
├── actions/         # UI event handlers (Server Actions)
│   └── todo.ts
├── services/        # Pure business logic (DB operations, etc.)
│   └── todo.service.ts
└── lib/             # Shared configurations (Prisma, Zod, Auth.js)

Implementation Example: Clean Architecture via Service Layer

// services/todo.service.ts
import { prisma } from '@/lib/prisma';

export const createTodoItem = async (title: string) => {
  // Consolidate complex validation and external integrations here
  return await prisma.todo.create({ data: { title } });
};

// actions/todo.ts
'use server'

import { createTodoItem } from '@/services/todo.service';
import { revalidatePath } from 'next/cache';
import { z } from 'zod';

const TodoSchema = z.object({ title: z.string().min(1).max(100) });

export async function createTodoAction(prevState: any, formData: FormData) {
  const result = TodoSchema.safeParse(Object.fromEntries(formData));
  if (!result.success) return { error: result.error.flatten().fieldErrors };

  try {
    await createTodoItem(result.data.title);
    revalidatePath('/dashboard');
    return { success: true };
  } catch {
    return { error: 'An internal server error occurred.' };
  }
}

With this structure, Server Actions can focus solely on "receiving input" and "handling results," while the domain logic is isolated as pure functions that are easy to unit test.

---

3. The Cache Trap and the Depths of Revalidation

The most common hurdle for engineers using Server Actions is managing cache after data updates. Simply calling `revalidatePath` at random will not suffice for complex applications.

• `revalidatePath(path)`: Invalidates the cache for a specific path. This is sufficient for basic use cases, but excessive revalidation can degrade performance.
• `revalidateTag(tag)`: Invalidates tags associated with specific data sources. By setting `next: { tags: ['todo'] }` during a `fetch`, you can achieve much finer control over cache invalidation.
• `unstable_cache`: Use this for frequently called, computationally expensive functions. This can drastically reduce the frequency of database queries.

---

4. Clear Distinction Between API Routes and Server Actions

You don't need to replace everything with Server Actions. In the following cases, you should still opt for traditional API Routes or Route Handlers:

---

5. Conclusion: Don't Let Tools Dictate Your Architecture

Server Actions are a powerful tool designed to help you focus on the "essence" of web development. By removing the intermediate step of an API Route, you reduce the amount of boilerplate code and lower the cost of maintaining type safety.

However, before jumping onto the latest trends, remember this: if you neglect "designing for loose coupling" and a "deep understanding of caching," even the most advanced technology will eventually become nothing more than "unstable debt."

Are you ready to break free from the shackles of API Routes? Start small: extract one service layer and migrate it to a Server Action. Beyond that, you will find an entirely new level of developer experience.

---

🤖 Developer Blog & Content

The author's personal blog is also available; feel free to check it out! 👉 muttyan.com (Developer Blog)