// 1. SERVER ACTION: Ideal pentru mutații rapide din UI
// app/actions.ts
'use server';
import { revalidatePath } from 'next/cache';
import { db } from '@/lib/db';
export async function updateBio(formData: FormData) {
const bio = formData.get('bio') as string;
await db.user.update({ where: { id: 1 }, data: { bio } });
revalidatePath('/profile');
}
// 2. API ROUTE: Necesar pentru Presigned URLs, Webhooks sau API Public
// app/api/upload/route.ts
import { NextResponse } from 'next/server';
import { getS3PresignedUrl } from '@/lib/s3';
export async function POST(req: Request) {
const { fileName, fileType } = await req.json();
const uploadUrl = await getS3PresignedUrl(fileName, fileType);
return NextResponse.json({ uploadUrl });
}Salutare. Văd tot mai mulți dev juniori și mid care aruncă API route-urile la gunoi imediat ce trec pe App Router, de parcă Server Actions ar fi un glonte de argint pentru absolut orice. Am făcut și eu greșeala asta anul trecut pe un proiect de SaaS cu vreo 12.000 de useri activi și am plătit prețul când au început să vină cazurile de margine.
Hai să trecem prin trei scenarii reale unde decizia asta îți poate salva sau strica ziua.
1. Form Submit: Unde strălucesc Server Actions
Dacă ai de mutat date dintr-un formular direct în baza de date, Server Actions sunt minunate. Am scos cam 35% din codul de boilerplate doar pentru că nu mai trebuia să creez un endpoint /api/users/profile, să fac fetch manual pe client, să gestionez isSubmitting cu state-uri locale și să sincronizez tipurile TypeScript.
Câștigi validare directă, gestionare automată de cookie-uri și revalidare instantă de cache cu revalidatePath().
Trade-off-ul? Dacă vrei feedback ultra-granular pe client în timp ce se execută acțiunea (un progress bar fin sau opțiuni avansate de optimistic UI complexe), Server Actions pot deveni puțin rigide comparat cu un request fetch tradițional orchestrat de TanStack Query.
2. File Upload: Iluzia simplității
Aici mi-am luat-o cel mai tare. Am zis "ce mare lucru, trimit FormData direct într-un Server Action". Pentru avatare de utilizator de 1-2 MB, totul a mers brici.
Apoi un client a încercat să încarce un fișier PDF de 20 MB. Poc! Crash direct pe Vercel. De ce? Pentru că un Server Action trece prin Serverless Functions, iar Vercel are o limită strictă de 4.5 MB pe payload-ul de request/response.
Dacă ai upload-uri mari sau fișiere multiple, arhitectura corectă este un API Route dedicat care generează un Presigned URL (pentru AWS S3 sau Cloudflare R2). Browserul urcă fișierul direct în storage bucket, fără să treacă prin Node.js-ul tău și fără să-ți blocheze serverul.
3. Webhooks de la terți: Exclusiv API Routes
Am văzut recent pe un grup pe cineva care încerca să prindă un webhook de la Stripe folosind Server Actions. Nu faceți asta.
Server Actions sunt construite specific pentru ecosistemul React și App Router. Ele așteaptă headere specifice Next.js, context de RSC (React Server Components) și un anumit format de date. Un server Stripe, Typeform sau SendGrid n-are nicio treabă cu React; el doar trimite un POST HTTP standard cu un payload JSON și o semnătură HMAC în header.
Pentru orice webhook extern, soluția unică și corectă este un API Route (app/api/stripe/route.ts), unde poți citi request.text() nealterat pentru a valida semnătura Stripe.
Concluzia mea
Nu tratați Server Actions ca pe un înlocuitor de API routes, ci ca pe un mecanism de RPC (Remote Procedure Call) dedicat pentru UI.
Dacă apelul pleacă dintr-o componentă React și modifică starea aplicației tale: folosește Server Action. Dacă apelul vine din afara aplicației (webhooks, microservicii) sau implică streaming de fișiere mari: folosește API Route.
Voi ce abordare aveți în aplicațiile de producție, ați renunțat complet la API Routes sau le combinați?