// Exemplu de Server Action securizat pentru un form submit
'use server';
import { db } from '@/lib/db';
import { auth } from '@/lib/auth';
import { revalidatePath } from 'next/cache';
export async function updateUsername(formData: FormData) {
const session = await auth();
if (!session?.user) {
throw new Error('Neautorizat');
}
const username = formData.get('username') as string;
if (!username || username.length < 3) {
return { error: 'Numele e prea scurt' };
}
await db.user.update({
where: { id: session.user.id },
data: { username },
});
revalidatePath('/profile');
return { success: true };
}Salutare! De când Next.js a tot împins Server Actions în față, văd multă lume confuză care încearcă să înghesuie absolut toată logica de backend acolo. Am trecut prin tranziția asta pe un proiect cu vreo 12.000 de utilizatori activi și am învățat pe pielea mea unde strălucesc acțiunile și unde te lasă în drum.
Nu există „argint viu” aici. Ambele unelte sunt bune, dar rezolvă probleme complet diferite în arhitectura aplicației tale.
Formularele simple: Server Actions sunt rege
Săptămâna trecută am refăcut un flow de onboarding. Înainte aveam clasicul onSubmit care apela un API route prin fetch, gestionam manual stările de loading, error și success, plus validarea cu Zod pe ambele părți.
Trecând la Server Actions, am eliminat cam 30% din codul de boilerplate. Pur și simplu legi acțiunea direct de atributul action al formularului. Primești validare out-of-the-box și, cel mai mișto lucru, funcționează chiar și dacă userul are o conexiune proastă și JS-ul nu s-a descărcat complet încă (progressive enhancement).
Merge brici pentru mutații simple: adăugat în baza de date, trimis un mail de confirmare sau șters un rând dintr-un tabel.
Upload-ul de fișiere: Aici m-am fript
Am încercat să folosesc Server Actions pentru un modul unde userii urcau imagini de profil de 5-10MB. Mare greșeală.
Când trimiți un fișier printr-o acțiune de server, Next.js serializează tot payload-ul. Asta înseamnă că fișierul tău este convertit în Base64 sau trecut prin stream-uri interne care consumă enorm de multă memorie pe serverele serverless (cum e Vercel). M-am trezit rapid cu erori de tip Body exceeded 4.5MB limit și timeout-uri.
Soluția mea: Pentru upload de fișiere mari, rămâi la API Routes clasice unde poți folosi librării dedicate precum busboy sau, și mai bine, folosește API-ul doar ca să generezi un URL pre-semnat (presigned URL) din S3/Cloudflare R2 și lasă clientul să facă upload-ul direct acolo.
Webhook-urile de la terți: API Routes fără discuție
Dacă integrezi Stripe, Shopify sau un serviciu de SMS-uri care îți trimite statusul livrării înapoi prin POST, Server Actions sunt inutile.
De ce? Pentru că o acțiune de server este o chestie internă, un endpoint generat dinamic de Next.js pe care doar clientul tău de React știe cum să-l apeleze corect, trimițând headere specifice de request. Stripe nu știe să apeleze o acțiune de server. Are nevoie de un URL public, stabil și standardizat (de exemplu, /api/webhooks/stripe).
Aici ai nevoie de un API Route clasic unde poți valida semnatura webhook-ului direct pe request-ul brut (raw body), lucru destul de complicat de făcut într-o acțiune de server.
Trade-off-ul de securitate și decizia finală
Server Actions rulează exclusiv pe server, ceea ce e super pentru că poți interoga baza de date direct fără să expui chei API. Totuși, ai grijă la autorizare. Doar pentru că o funcție e definită cu 'use server' nu înseamnă că e privată; ea devine un endpoint public sub capotă. Trebuie să verifici sesiunea utilizatorului în interiorul fiecărei acțiuni.
Pe scurt: folosește Server Actions pentru interacțiuni strânse între UI-ul tău și baza de date (formulare, butoane de switch, acțiuni rapide). Păstrează API Routes pentru tot ce înseamnă integrări externe, upload de fișiere mari și cazuri unde ai nevoie de control total asupra headerelor de răspuns.
Voi ce folosiți mai des în ultima vreme? Ați renunțat complet la folderul /api?