'use server'
import { revalidatePath } from 'next/cache';
import { db } from '@/lib/db';
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ă minim 3 caractere.' };
}
await db.user.update({
where: { id: 'user_123' },
data: { name, bio }
});
revalidatePath('/profile');
return { success: true };
}Am tot văzut hype-ul cu Server Actions în Next.js și, recunosc, la început am vrut să le pun peste tot. După ce am migrat un proiect cu vreo 12.000 de utilizatori activi de pe API Routes clasice, mi-am luat câteva palme de la realitate. Nu tot ce zboară se mănâncă, iar Server Actions nu vin să înlocuiască complet rutele de API, chiar dacă așa pare din tutoriale.
Cazul fericit: Formularul clasic (Server Actions câștigă detașat)
Dacă ai de făcut un formular simplu de contact, un update de profil sau un sistem de comentarii, Server Actions sunt geniale. Am economisit cam 30% din codul de boilerplate pe care îl scriam înainte cu fetch, useState pentru loading și gestionarea manuală a erorilor.
Pur și simplu pui 'use server' în capul funcției, o legi de action-ul formularului și Next.js se ocupă de restul. Primești progres out-of-the-box prin useFormStatus și poți folosi useOptimistic pentru o experiență instantanee. Nu mai ai nevoie de rute separate, nu mai expui URL-uri de API inutile. E curat și rapid.
Cazul gri: Upload-ul de fișiere (Aici m-am ars)
Am încercat să folosesc o acțiune de server pentru a uploada imagini direct într-un bucket S3. Toate bune în development, dar în producție, pe serverless, ne-am lovit rapid de timeout-ul de 15 secunde și de limitările de payload (pe Vercel limita e de 4.5MB pe funcțiile serverless).
Când un user a încercat să urce o poză de 10MB direct de pe telefon, funcția a crăpat spectaculos. Pentru fișiere, recomandarea mea e clară: folosește un API Route care doar generează un URL presemnat (presigned URL) de S3, iar upload-ul efectiv fă-l direct din browser (client-side) către storage. Economisești resurse pe server și eviți blocajele.
Cazul în care n-ai de ales: Webhook-uri de la terți
Aici e simplu: dacă Stripe, Shopify sau orice alt serviciu extern trebuie să-ți trimită un webhook (de exemplu, când se confirmă o plată), Server Actions sunt complet inutile. Ele sunt proiectate exclusiv pentru interacțiunea client-server din interiorul aplicației tale Next.js. Au nevoie de headere specifice și de contextul aplicației.
Pentru orice request care vine din exterior, ai nevoie de API Routes (/api/webhooks/stripe). Acolo poți citi request-ul brut (raw body) pentru a valida semnătura Stripe, lucru imposibil de făcut curat într-o acțiune de server.
Trade-off-ul de care nu vorbește nimeni
Server Actions folosesc request-uri de tip POST sub capotă. Dacă userul are o conexiune slabă la internet (3G prin tren), o acțiune de server poate să pară extrem de lentă deoarece Next.js face automat revalidation pe layout-uri și pagini după rularea acțiunii. Te trezești că o simplă salvare de text re-randează componente pe server și trimite tone de JSON înapoi în rețea.
Voi ce folosiți cel mai des în proiectele voastre actuale de Next.js? Ați renunțat complet la API routes sau le păstrați ca fallback?