/* app/actions.ts */
'use server';
import { revalidatePath } from 'next/cache';
import { z } from 'zod';
const schema = z.object({
email: z.string().email('Email invalid!'),
});
export async function subscribeNewsletter(prevState: any, formData: FormData) {
const validatedFields = schema.safeParse({
email: formData.get('email'),
});
if (!validatedFields.success) {
return { error: validatedFields.error.flatten().fieldErrors.email?.[0] };
}
try {
// db.newsletter.create({ data: { email: validatedFields.data.email } });
revalidatePath('/');
return { success: true };
} catch (err) {
return { error: 'Eroare la salvarea în baza de date.' };
}
}Salutare! Văd tot mai des dilema asta pe grupuri: când naiba folosim Server Actions și când rămânem la clasicele API Routes în Next.js? Am trecut prin tranziția asta pe un proiect cu vreo 12.000 de utilizatori activi și am adunat câteva cicatrici care sper să vă scutească de rescrieri inutile.
Formularul clasic: Server Actions sunt rege
Pentru chestii simple, gen formulare de contact, update de profil sau adăugat un comentariu în baza de date, Server Actions sunt absolut geniale. Scapi de tot boilerplate-ul de API. Nu mai scrii fetch('/api/profile', { method: 'POST' }), nu mai definești rute separate și nu te mai chinui cu tipizarea pe ambele capete.
Totul e o simplă funcție asincronă marcată cu 'use server' pe care o apelezi direct în proprietatea action a formularului. Am refăcut un modul de onboarding în stilul ăsta și am eliminat cam 40% din codul de legătură (glue-code).
Cel mai mare avantaj? Progressive enhancement. Dacă userul are o conexiune proastă și JS-ul încă se descarcă pe client, formularul tot funcționează prin fallback-ul nativ de HTML.
Trade-off-ul: Dacă ai nevoie de rate limiting foarte agresiv pe acel endpoint sau vrei să expui acțiunea și către o aplicație mobilă nativă, Server Actions te încurcă. Ele sunt strâns legate de clientul web de Next.js. Pentru o aplicație de mobil va trebui oricum să scrii un API separat.
File Upload: Unde se rupe filmul
Aici e o capcană mare în care am picat și eu. La început, am zis că e simplu: trimit un FormData cu fișierul selectat direct printr-un Server Action. Și merge excelent pentru un avatar de 500KB.
Dar când am dat drumul în producție la upload de PDF-uri de 15-20MB, serverul a început să dea timeout-uri grele. Pe serverless (cum e Vercel), ai limita aia nesuferită de execution time de 10-15 secunde pe planurile basic. Server Actions serializează tot corpul cererii și îl trec prin layer-ul de Next.js, consumând memorie aiurea.
Pentru fișiere mari, varianta corectă rămâne un API Route clasic care generează un presigned URL (pentru S3 sau Cloudflare R2), iar clientul face upload-ul direct în storage, ocolind complet serverul tău de Next.js.
Webhook-uri terțe (Stripe, GitHub): API Routes fără discuție
Aici nu există loc de dezbatere. Dacă ai un webhook de la Stripe, Shopify sau orice alt serviciu extern, trebuie să folosești API Routes (Route Handlers în App Router).
De ce? Pentru că Server Actions sunt create exclusiv pentru interacțiunea browser-server din interiorul aplicației tale. Ele folosesc un header special (Next-Action) și un format de request/response pe care Stripe nu are cum să-l știe sau să-l respecte. Stripe vrea un endpoint POST standard, curat, unde trimite un JSON brut și așteaptă un status HTTP 200 înapoi.
Ca regulă simplă pe care o aplic acum: folosesc Server Actions pentru mutări rapide de date în interiorul UI-ului meu (mutări strânse de starea paginii) și API Routes pentru orice înseamnă integrare externă, upload masiv de fișiere sau când am nevoie de un endpoint public.
Voi ce probleme ați întâmpinat la migrarea spre Server Actions? Ați dat de limitări pe partea de caching sau sesiuni?