// Exemplu de Server Action curat pentru Form Submit
// app/actions.ts
'use server'
import { z } from 'zod'
const schema = z.object({
email: z.string().email(),
})
export async function subscribeNewsletter(formData: FormData) {
const validatedFields = schema.safeParse({
email: formData.get('email'),
})
if (!validatedFields.success) {
return { error: 'Email invalid.' }
}
// Salvare în baza de date direct aici
// await db.subscribe(validatedFields.data.email)
return { success: true }
}Salutare! Discuția asta despre Server Actions versus vechile API Routes tot apare pe forum și cred că e momentul să o tranșăm. Am mutat recent o aplicație cu vreo 12.000 de utilizatori activi pe Next.js 14 și m-am lovit direct de limitările ambelor abordări. Nu tot ce strălucește în documentația oficială funcționează perfect când ai trafic real.
Server Actions nu sunt un înlocuitor universal pentru API Routes. Cine zice asta, probabil n-a scris destul cod de producție. Hai să vedem exact când să folosești una sau alta, pe baza a trei scenarii concrete cu care ne lovim zilnic.
1. Form Submit (The Sweet Spot pentru Server Actions)
Pentru formulare simple de tipul creării unui comentariu sau actualizării profilului, Server Actions sunt aur curat. Am scăpat de tone de cod de tipul useState, loading states scrise manual și fetch-uri plictisitoare.
Pur și simplu legi funcția direct de proprietatea action a formularului. Marele avantaj? Merge instant și ai suport nativ pentru validări cu Zod direct pe server. La proiectul menționat mai sus, am redus dimensiunea bundle-ului pe client cu vreo 18% doar eliminând librăriile inutile de management al formularelor și fetch-urile repetitive.
2. File Uploads (Zona gri)
Aici m-am ars cel mai tare. Am încercat inițial să trimit imagini de profil de 5-10MB prin Server Actions direct în S3. Tehnic, se poate, dar în realitate este o idee foarte proastă.
Server Actions folosesc apeluri POST de tip RPC (Remote Procedure Call) sub capotă. Când trimiți fișiere mari prin ele, serializezi datele binare, iar pe serverless (cum e Vercel) te lovești rapid de limita corpului cererii (payload limit) și de timeout-uri de 10-15 secunde pe planurile ieftine.
Soluția corectă: Pentru upload de fișiere mari, folosește în continuare un API Route dedicat care generează un presigned URL de S3, iar clientul face upload direct în storage-ul tău, ocolind complet serverul de Next.js. Alternativ, folosește un API Route clasic dacă ai nevoie de procesare locală (de exemplu, resize cu Sharp).
3. Webhook-uri de la terți (Fără discuție: API Routes)
Am văzut pe cineva pe Reddit încercând să proceseze un webhook de Stripe folosind un Server Action. Nu faceți asta.
Serviciile externe (Stripe, Shopify, Lemon Squeezy) trimit cereri HTTP POST standard către o adresă URL fixă din aplicația ta. Ele au nevoie de un endpoint clasic care să răspundă cu un status 200 rapid și unde să poți valida semnătura din headere (de exemplu, stripe-signature).
Server Actions funcționează doar în interiorul ecosistemului React/Next.js. Nu au un URL public stabil pe care să îl poți oferi unui serviciu terț. Pentru orice integrare externă, API Routes (Route Handlers în App Router) rămân singura opțiune viabilă.
Trade-off-uri și concluzia mea
Ca regulă generală pe care o aplic acum în echipă: dacă acțiunea este inițiată direct de utilizatorul tău din interfață (un click, un submit), mergi pe Server Actions. Câștigi viteză de dezvoltare și un cod mult mai curat.
Dacă acțiunea vine de la un script extern (cron job, webhook) sau implică transfer masiv de date (export-uri uriașe, upload de fișiere mari), API Routes sunt sfinte.
Cum gestionați voi dilema asta în proiectele voastre? Ați trecut complet pe Server Actions sau încă preferați controlul total oferit de API Routes?