'use server';
import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';
export async function updateProfile(formData: FormData) {
const name = formData.get('name') as string;
const bio = formData.get('bio') as string;
if (!name || name.length < 3) {
return { error: 'Numele trebuie să aibă cel puțin 3 caractere.' };
}
try {
await db.user.update({
where: { id: 'user_123' },
data: { name, bio }
});
revalidatePath('/profile');
return { success: true };
} catch (err) {
return { error: 'Eroare la salvarea în baza de date.' };
}
}Salutare tuturor. Văd pe grup tot mai des hype-ul ăsta cu „Server Actions înlocuiesc complet API routes”. Să fim serioși, am trecut de faza în care credem că o tehnologie nouă le rezolvă pe toate. La un proiect recent cu vreo 15.000 de utilizatori activi, am făcut greșeala să migrăm totul pe Server Actions. Ne-am lovit rapid de limitări pe care nu le-am anticipat la început.
Hai să facem ordine și să vedem exact când merită să folosești Server Actions și când API-urile clasice (/api/route.ts) rămân sfinte.
Form Submit: Câștigătorul clar este Server Actions
Dacă ai un formular clasic (creare cont, editare profil, adăugare comentariu), Server Actions sunt geniale. Am redus codul de boiler-plate cu vreo 40% la formularele de setări.
Nu mai ai nevoie de fetch, de stări de loading gestionate manual prin useState (folosești useActionState sau useTransition) și scapi de definirea unei rute API separate doar ca să muți niște date dintr-un input în baza de date. Totul e complet tipizat din start.
File Upload: Zona gri unde te poți frige
Aici am avut prima surpriză neplăcută. Trebuia să urcăm imagini de profil de până la 10MB direct în S3.
Dacă trimiți fișiere mari prin Server Actions, Next.js serializează totul în request-ul de POST ca multipart form data, dar comportamentul pe servere serverless (cum e Vercel) poate fi extrem de instabil din cauza limitărilor de payload (10MB limită pe Vercel hobby/pro) și a timeout-urilor.
Pentru upload de fișiere mari, recomand în continuare un API Route clasic unde poți folosi stream-uri sau, și mai bine, generezi un presigned URL din API și urci fișierul direct din browser în S3 sau Cloudinary. Evită Server Actions pentru fișiere mari dacă nu vrei să ai surprize cu memoria pe server.
Webhooks: API Routes sunt obligatorii
Aici nu există loc de dezbatere. Dacă integrezi Stripe, Clerk sau orice alt serviciu third-party care îți trimite un webhook când se întâmplă un eveniment, trebuie să folosești API Routes.
De ce? Pentru că Server Actions sunt concepute strict pentru interacțiunea utilizator-browser din interiorul aplicației tale Next.js. Ele folosesc un header special (Next-Action) și un format de payload pe care Stripe nu are cum să le trimită. Un API Route clasic îți oferă control total asupra headerelor, metodelor HTTP (POST, GET) și îți permite să validezi semnătura webhook-ului direct pe request-ul brut (raw body).
Cum facem alegerea?
Regula mea de aur e simplă:
- E o acțiune declanșată direct de utilizator din UI care modifică starea bazei de date? -> Server Action.
- E un serviciu extern care trebuie să vorbească cu aplicația ta, sau ai nevoie de un endpoint public pentru o aplicație mobilă? -> API Route.
Voi cum ați împărțit logica în ultimele proiecte? Ați avut probleme cu timeout-urile pe Server Actions?