'use server';
import { z } from 'zod';
import { revalidatePath } from 'next/cache';
import { db } from '@/lib/db';
const ProfileSchema = z.object({
name: z.string().min(2, 'Numele trebuie să aibă minim 2 caractere'),
bio: z.string().max(160, 'Bio-ul depășește 160 de caractere'),
});
export async function updateProfile(prevState: any, formData: FormData) {
const validatedFields = ProfileSchema.safeParse({
name: formData.get('name'),
bio: formData.get('bio'),
});
if (!validatedFields.success) {
return { errors: validatedFields.error.flatten().fieldErrors };
}
await db.user.update({
where: { id: 'usr_123' },
data: validatedFields.data,
});
revalidatePath('/profile');
return { success: true, errors: {} };
}Trecerea de la API Routes la Server Actions în Next.js pare simplă la prima vedere, dar mulți le încurcă sau le folosesc fix unde nu trebuie. Anul trecut, pe un proiect cu 15k utilizatori activi lunari, am migrat jumătate din endpoint-uri la Server Actions și am dat cu capul de câteva praguri de sus. În postarea asta îți spun exact ce am învățat și când e mai bine să rămâi la clasicele Route Handlers (app/api/.../route.ts).
Form submit și mutații rapide: Câștigă Server Actions
Pentru orice înseamnă form submit, schimbat un status în bază de date sau o mutație simplă declanșată de utilizator în interfață, Server Actions sunt absolut excelente. Am scos din proiect aproape 30% din codul de boilerplate pentru că am scăpat de endpoints dedicate în /api, de gestionarea manuală a stărilor de loading scrise peste tot și de fetch-uri repetitive.
Folosești useActionState (sau vechiul useFormState), validezi cu Zod pe server și returnezi erorile direct în UI. În plus, cel mai mare avantaj e că te integrezi nativ cu cache-ul din Next.js. Apelezi revalidatePath('/dashboard') direct în acțiune și pagina se actualizează instant fără să mai configurezi React Query sau SWR pentru chestii banale.
Upload-ul de fișiere: Depinde de dimensiune
Aici am pățit-o la un build. Dacă ai un upload mic (un avatar de 300KB sau un fișier text), poți trimite liniștit un FormData într-o Server Action. Merge brici și e super rapid de implementat.
Dar dacă utilizatorii tăi urcă imagini hi-res sau PDF-uri de 20-50MB, lucrurile se schimbă. Server Actions au o limită implicită de body size (1MB default în Next.js) pe care trebuie să o mărești din next.config.js. Mai mult, trimiterea fișierelor mari prin Server Actions poate bloca thread-ul serverului de Node.js și crește memoria consumată inutil pe instanță.
Soluția mea pentru fișiere mari? Folosesc o Server Action (sau API Route) doar ca să generez un S3 Presigned URL, iar din browser fac PUT direct către AWS S3 sau Cloudflare R2. Serverul meu de Next.js nici nu simte traficul greu.
Webhooks și API-uri publice: Exclusiv API Routes
Aici nu există dezbatere. Server Actions sunt concepute strict pentru comunicarea dintre aplicația ta frontend (React) și serverul tău de Next.js. Ele depind de contextul de React și de header-ele interne din Next.
Dacă trebuie să primești un webhook de la Stripe, Twilio sau Resend, Server Actions nu funcționează. Ai nevoie de un endpoint HTTP standard care poate primi un request extern POST, citește raw body-ul pentru validarea semnăturii criptografice (ex: stripe-signature) și returnează un status code HTTP clar (200 OK, 400 Bad Request). Același lucru e valabil dacă construiești un API public pe care îl va consuma o aplicație mobilă de iOS/Android. Rămâi 100% pe API Routes (route.ts).
Regula mea de aur
Trade-off-ul e clar: Server Actions îți dau o viteză uriașă de dezvoltare și o integrare strânsă cu UI-ul, dar te leagă de ecosistemul aplicației web. API Routes îți oferă decuplare, control total pe răspunsurile HTTP și compatibilitate cu servicii externe.
Voi cum le-ați împărțit în proiectele voastre recente? Mai folosiți API Routes pentru formulare din inerție sau ați trecut complet pe Server Actions?