'use server';
import { z } from 'zod';
const schema = z.object({
email: z.string().email('Email invalid'),
message: z.string().min(10, 'Mesajul e prea scurt'),
});
export async function submitContactForm(prevState: any, formData: FormData) {
const validatedFields = schema.safeParse({
email: formData.get('email'),
message: formData.get('message'),
});
if (!validatedFields.success) {
return {
success: false,
errors: validatedFields.error.flatten().fieldErrors,
};
}
try {
// DB operation here (e.g. db.insert...)
return { success: true, errors: null };
} catch (e) {
return {
success: false,
errors: { global: 'Eroare de conexiune la baza de date' }
};
}
}Salutare. Văd des pe forumuri și pe Slack aceeași dilemă: mai are sens să scriem API routes în Next.js sau mutăm totul pe Server Actions? După ce am migrat o aplicație cu peste 12.000 de utilizatori activi la App Router, mi-am dat seama că entuziasmul inițial pentru Server Actions trebuie temperat. Sunt excelente pentru anumite scenarii, dar devin un coșmar dacă le folosești orbește.
Hai să le luăm la bani mărunți pe trei cazuri concrete pe care le întâlnești în orice proiect real.
1. Form Submit: Locul unde Server Actions strălucesc
Dacă ai de făcut un formular simplu de contact, un update de profil sau un sistem de comentarii, Server Actions sunt absolut geniale. Economisești cam 30% din codul pe care l-ai fi scris înainte pentru gestionarea stării de loading, erori și fetch-uri manuale.
Marele avantaj este integrarea nativă cu useActionState și validarea directă pe server. Nu mai ai nevoie de un endpoint public pe care să îl expui. Totul se întâmplă printr-un POST securizat generat automat de Next.js sub capotă.
Trade-off-ul sincer? Dacă ai nevoie de un progres precis în UI (gen „se încarcă 45%”), Server Actions nu te ajută nativ, fiindcă folosesc fetch-uri abstractizate pe care nu le poți intercepta ușor pentru progres.
2. File Upload: Zona gri unde poți da de belele
Aici am pățit-o direct la un proiect unde aveam upload de fișiere PDF mari (facturi și contracte de 5-10MB). Prima tentativă a fost cu Server Actions, trimițând un FormData clasic.
Pe local a mers brici. În producție, pe Vercel, ne-am lovit de limita de timeout de 10 secunde pe serverless functions și de faptul că Server Actions serializează datele într-un mod destul de ineficient pentru payload-uri mari. Dacă userul are o conexiune mobilă slabă, request-ul crapă înainte ca fișierul să fie complet uploadat.
Pentru upload-uri, recomandarea mea fermă este să folosești API Routes clasice sau, și mai bine, să generezi un presigned URL din S3 printr-o rută de API și să uploadezi direct din browser. UI-ul rămâne responsiv, poți pune un progress bar real și nu blochezi serverul de Next.
3. Webhook-uri de la terți (Stripe, Shopify): Doar API Routes
Aici nu există dezbatere. Dacă ai nevoie de un endpoint pe care să îl apeleze Stripe după ce s-a efectuat o plată, trebuie să folosești Route Handlers (API Routes în /app/api/).
Server Actions sunt gândite exclusiv pentru interacțiunea client-server din interiorul aplicației tale Next.js. Ele necesită headere specifice de Next.js și un context de execuție pe care Stripe nu are cum să le trimită. Pentru orice integrare externă unde un alt server îți trimite un POST, creează o rută clasică în app/api/webhook/route.ts și validează semnatura webhook-ului acolo.
Concluzia mea simplă
Regula mea de aur este așa: folosesc Server Actions pentru mutații rapide declanșate de utilizator în UI (formular, toggle, ștergere rapidă). Pentru orice înseamnă transfer de fișiere mari, integrări cu terți (webhooks) sau dacă am nevoie de un API public pe care să îl folosească și o viitoare aplicație de mobil, scriu API Routes clasice.
Voi cum procedați? Ați mutat complet formularele pe Server Actions sau ați rămas fani API-uri clasice cu React Query?