eduardweb.
Server ActionsIntermediar#server-actions#nextjs#typescript#react#api-routes

Server Actions vs API Routes în Next.js: Când folosești fiecare fără să-ți prinzi urechile

De Delia Petre, 22 iul. 2026 · 6 vizualizări · 2 like-uri

Postat 22 iul. 2026
typescript
import { headers } from 'next/headers';
import { NextResponse } from 'next/server';
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, { apiVersion: '2023-10-16' });

// Webhook-urile au nevoie neapărat de API Routes pentru raw body verification
export async function POST(req: Request) {
  const body = await req.text();
  const signature = headers().get('stripe-signature')!;

  try {
    const event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );

    if (event.type === 'checkout.session.completed') {
      const session = event.data.object as Stripe.Checkout.Session;
      // Update order status in DB
    }

    return NextResponse.json({ received: true });
  } catch (err: any) {
    return NextResponse.json({ error: `Webhook Error: ${err.message}` }, { status: 400 });
  }
}

De când au apărut Server Actions în Next.js, am văzut mulți colegi care au șters folderul app/api definitiv. E o greșeală pe care am făcut-o și eu pe un proiect și am regretat-o rapid.

Deși Server Actions sunt excelente pentru mutațiile declanșate din interfață, API Routes rămân indispensabile în stack-ul de producție. Hai să le luăm pe rând, pe cazuri reale.

Form Submit și mutații din UI: Server Actions fără discuție

Dacă ai un formular de editat profilul, adăugat un produs în coș sau un simplu toggle de status, Server Actions sunt genial de comode. Scapi de boilerplate-ul obositor: fără stări manuale de loading scrise de mână, fără fetch('/api/user'), fără re-export de tipuri TypeScript între client și server.

Anul trecut am refăcut o aplicație SaaS cu vreo 12k utilizatori activi lunar. Am migrat formularele clasice pe Server Actions folosind useActionState și useOptimistic. Rezultatul? Am tăiat cam 38KB de JavaScript inutil trimis în browser și am scăzut timpul de răspuns perceput de user cu peste 30% datorită update-urilor optimiste.

Third-party Webhooks: Aici API Routes sunt obligatorii

Aici se rupe filmul cu Server Actions. Dacă integrezi Stripe, Clerk, Supabase sau orice alt serviciu terț care îți trimite webhook-uri, nu ai cum să folosești Server Actions.

Un webhook are nevoie de o cale HTTP REST clasică, predictibilă (ex: /api/webhooks/stripe), care primește un request POST standard și oferă acces direct la request-ul brut (raw body) pentru validarea semnăturii criptografice.

Server Actions sunt practic apeluri RPC (Remote Procedure Call) abstractizate de framework, făcute prin POST cu header-e specifice Next.js. Un server de la Stripe n-are nicio idee cum să apeleze o acțiune de server din Next.js.

File Uploads și streaming: Depinde de mărime

Pentru un avatar mic de 1-2MB trimis într-un FormData, o Server Action își face treaba perfect. În schimb, dacă vrei upload de fișiere mari, video-uri sau ai nevoie de un progress bar precis pe client, o acțiune de server devine rapid un cosmar.

Server Actions nu oferă API pentru upload progress events nativ. De asemenea, au o limită de body payload setată global în next.config.js. Pentru fișiere mari, abordarea corectă e un API Route care generează un Pre-signed URL (de S3/Cloudflare R2), iar clientul urcă fișierul direct în storage, ocolind serverul tău de Node.

Regula mea simplă de decizie

  • Server Actions: Interacțiune directă Om-Aplicație (UI-driven, formulare, mutații rapide cu optimisitic UI).
  • API Routes: Machine-to-Machine (Webhook-uri, API public pentru aplicația de mobil, streaming complex, integrare de microservicii).

Voi ce abordare folosiți pe proiectele curente? Mai aveți foldere /api în proiecte noi de Next.js sau ați mutat tot pe acțiuni?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.