// 1. SERVER ACTION: Ideal pentru Form Submissions
// app/actions.ts
'use server';
import { revalidatePath } from 'next/cache';
export async function updateUsername(prevState: any, formData: FormData) {
const name = formData.get('username') as string;
if (!name || name.length < 3) return { error: 'Nume prea scurt' };
await db.user.update({ where: { id: 1 }, data: { name } });
revalidatePath('/profile');
return { success: true, error: null };
}
// 2. API ROUTE: Obligatoriu pentru Webhooks (ex: Stripe)
// app/api/webhooks/stripe/route.ts
import { NextResponse } from 'next/server';
export async function POST(req: Request) {
const body = await req.text(); // Raw body necesar pentru validare
const signature = req.headers.get('stripe-signature');
if (!signature) {
return new NextResponse('Missing signature', { status: 400 });
}
// Process webhook payload...
return NextResponse.json({ received: true });
}De când a lansat Vercel Server Actions, am văzut mulți colegi din echipă încercând să șteargă complet folderul app/api. E o greșeală pe care și eu era să o fac acum un an, la o refactorizare pentru o platformă cu vreo 12k useri activi pe lună. În postarea asta vă zic exact ce a mers uns și unde ne-am lovit direct de zid.
Form Submit: Câștigul masiv pe UX și bundle size
Dacă ai un formular de profil, un checkout simplu sau un flux de setări, Server Actions sunt fantastice. Am scăpat de useState pentru fiecare input, de boilerplat-ul cu axios sau react-query pentru mutații simple și am eliminat vreo 35KB de JavaScript trimis inutil în browser.
Formularul funcționează direct cu atributul action pe <form>, iar pe server primești obiectul FormData. Cu revalidatePath sau revalidateTag faci update la UI instant, fără să-ți mai bătăi capul cu refetching manual.
Trade-off-ul? Dificultatea crește considerabil dacă ai formulare ultra-complexe pe client, cu validare live la fiecare keystroke pe 20 de câmpuri interconectate. Dacă trimiți request-uri la fiecare tastă prin Server Actions, îți omori serverul cu RTT-uri (Round Trip Times) inutile.
File Upload: Capcana din bodySizeLimit
Aici ne-am luat prima țeapă în producție. Un utilizator încerca să urce un PDF de 8MB pentru un contract și primea eroare 413 Payload Too Large instant.
Next.js are o limită implicită de 1MB pentru Server Actions. O poți crește din next.config.js, dar dacă procesezi fișiere mari direct în Node.js, îți blochezi event loop-ul și consumi memoria instanței degeaba.
Pentru poze de profil (sub 1MB), un Server Action e perfect. Dar pentru fișiere mari sau video-uri, un API Route clasic e mult mai indicat. Prin el generezi un presigned URL de S3 sau Cloudflare R2, iar clientul face upload-ul direct în bucket-ul de stocare, bypassing complet serverul tău de Next.js.
Webhooks & Integrări Externe: Zona unde Server Actions eșuează
Aici nu există cale de mijloc: Server Actions NU pot înlocui API Routes. Doriți să primiți un webhook de la Stripe, Typeform sau Shopify? Ai nevoie obligatoriu de o rută API clasică (app/api/webhooks/...).
Un webhook extern necesită un URL public stabil, cu o metodă POST explicită care poate citi request.text() în stare brută (raw body) pentru a verifica semnătura criptografică. Server Actions sunt apeluri RPC interne gestionate de Next.js prin POST-uri cu headere speciale (Next-Action). Niciun furnizor de plăți nu va putea trimite un webhook valid către o acțiune de server.
Regula mea de bază
Dacă acțiunea e declanșată direct de un utilizator din UI (editare profil, adăugare în coș, toggle de setări), folosesc Server Actions în 90% din cazuri. Dacă e vorba de webhooks, integrări cu aplicații mobile, cron jobs sau upload-uri mari, API Routes rămân sfânte.
Voi ce abordare aveți în proiectele curente? Mai păstrați rute de API pentru mutații interne sau ați trecut complet pe Server Actions?