// app/actions.ts (Server Action curat cu validare)
'use-server';
import { z } from 'zod';
const schema = z.object({
email: z.string().email(),
message: z.string().min(10),
});
export async function submitFeedback(formData: FormData) {
const validatedFields = schema.safeParse({
email: formData.get('email'),
message: formData.get('message'),
});
if (!validatedFields.success) {
return { error: 'Date invalide' };
}
// Salvare în DB direct, fără fetch intermediar
await db.feedback.create({
data: validatedFields.data,
});
return { success: true };
}Discuția asta cu Server Actions versus API Routes apare la fiecare refactoring pe care îl facem în echipă. Ambele rezolvă cam aceleași probleme la prima vedere, dar dacă le încurci, te trezești cu cod greu de întreținut sau cu timeout-uri în producție. Am trecut prin ambele tabere și am tras câteva concluzii clare după ce am migrat un proiect destul de măricel.
Form Submit: Unde Server Actions sunt pur și simplu geniale
Dacă ai de făcut un formular clasic, Server Actions sunt sfinte. Am avut de implementat un sistem de feedback pe un proiect cu 8.000 de utilizatori activi. Înainte, scriam o rută de API, făceam fetch din client, gestionam stările de loading și error cu useState și validam manual pe ambele părți. O tonă de boilerplate.
Cu Server Actions, legi acțiunea direct de formular. Next.js se ocupă de tot ce înseamnă transport. Reduci codul cu aproape 40% și ai siguranță pe tipuri (type safety) de la client la server fără efort.
Dar există un trade-off major de care m-am lovit. Dacă ai nevoie să expui acea funcționalitate și către o aplicație de mobil sau un serviciu extern, Server Actions nu te ajută. Ele folosesc un format intern de request-response (un fel de RPC mascat) destinat exclusiv clientului tău web. Pentru aplicații mobile, tot rutele clasice de API rămân baza.
File Upload: Atenție la limitele de memorie
Aici am văzut cele mai multe greșeli. Tehnic, poți trimite FormData cu un fișier direct într-un Server Action. Pentru un avatar mic, de sub 2MB, funcționează brici.
Problema apare când utilizatorii încep să urce imagini necomprimate sau PDF-uri mari. Am pățit asta la o platformă de HR unde utilizatorii încărcau CV-uri scanate direct prin Server Actions. Serverless-ul de pe Vercel (care are o limită de execuție de 15 secunde pe planul Pro și limite stricte de memorie) a început să dea timeout-uri în lanț.
Dacă ai fișiere mari, soluția corectă este un Route Handler (API Route) care generează un URL presemnat pentru AWS S3 sau Cloudflare R2. Clientul ia acel URL și face upload-ul direct în cloud, ocolind complet serverul tău Next.js. Astfel, economisești resurse și eviți blocarea serverului.
Webhook-uri: Cazul în care Server Actions sunt complet inutile
Am văzut developeri la început de drum care încercau să configureze webhook-ul de la Stripe folosind Server Actions. Nu faceți asta.
Webhooks de la servicii terțe (Stripe, Shopify, Lemon Squeezy) trimit cereri HTTP POST standard către o adresă URL specifică. Server Actions necesită headere speciale din partea clientului Next.js și nu pot fi apelate direct de aplicații externe. În plus, pentru a valida signătura Stripe, ai nevoie de acces la body-ul brut (raw body) al cererii HTTP, lucru imposibil de obținut curat într-un Server Action.
Pentru orice integrare externă, webhook sau API public, folosește Route Handlers. Ai control total asupra headerelor, metodelor HTTP (GET, POST, PUT) și a răspunsurilor de status (200 OK, 401 Unauthorized).
Concluzia mea
Folosesc Server Actions pentru interacțiuni strânse între UI-ul meu și baza de date (formulare, mutații simple, toggles). Las API Routes pentru integrări cu terți, upload de fișiere mari și atunci când am nevoie de un API REST curat care să poată fi consumat și de alte aplicații. Voi ce abordare folosiți cel mai des în proiectele voastre?