import { NextRequest, NextResponse } from 'next/server';
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
// Webhook-urile necesită acces la raw body și response custom
export async function POST(req: NextRequest) {
const body = await req.text();
const signature = req.headers.get('stripe-signature');
if (!signature) {
return NextResponse.json({ error: 'Missing signature' }, { status: 400 });
}
try {
const event = stripe.webhooks.constructEvent(
body,
signature,
process.env.STRIPE_WEBHOOK_SECRET!
);
if (event.type === 'checkout.session.completed') {
// Mutația ta în DB
}
return NextResponse.json({ received: true }, { status: 200 });
} catch (err: any) {
return NextResponse.json({ error: err.message }, { status: 400 });
}
}Am refăcut recent arhitectura la o platformă SaaS cu ~12k useri activi zilnic și ne-am lovit direct de dilema asta. Echipa voia să arunce totul pe Server Actions că "e mai nou și scriem mai puțin cod", dar pe parcurs ne-am furat-o la vreo două cazuri de margine. Dacă încă ești nedumerit când să faci un Route Handler și când să dai Directivei "use server", îți zic mai jos cum am stabilit noi regulile de joc.
Formulare și mutații UI: Server Actions fără ezitare
Dacă ai un formular de login, un buton de "Add to Cart" sau o bifă de setări în dashboard, Server Actions sunt o binecuvântare. Am eliminat vreo 30% din codul de glue pe frontend. Am scăpat de fetch() scris manual, de state-uri inutile de loading gestionate prin useState peste tot și de DTO-uri duplicate pentru request/response.
Cu useActionState și useFormStatus, UX-ul e foarte curat. În plus, revalidatePath și revalidateTag își fac treaba direct din acțiune, fără să mai dai tu refetch la date pe client. Merge brici pentru 80% din tot ce înseamnă interacțiune user-interfață.
File Uploads: De ce Server Actions ne-au dat timeout-uri
Aici ne-am luat prima oară plasă. Am zis că e simplu să trecem un FormData cu un fișier de 10-15MB printr-un Server Action. În local pe Node.js a mers totul unse, dar când am urcat în staging pe Vercel ne-am lovit direct cu capul de prag: limita de 4.5MB pe request payload la Serverless Functions.
Server Actions încearcă să serializeze și să proceseze tot payload-ul prin pachetul de acțiuni React. Când userul urcă o imagine mai mare, crește brusc consumul de memorie și îți sar instanțele în aer. Soluția sănătoasă pe care am aplicat-o a fost un API Route (Route Handler) scurt care generează un presigned URL de S3 sau Cloudflare R2. Clientul ia acel URL și face upload-ul direct în storage, bypassând complet serverul nostru de Next.js.
Webhook-uri third-party: API Routes sunt singura opțiune
Pentru webhook-uri de la Stripe, Postmark, Twilio sau Shopify, Server Actions nici măcar nu sunt o opțiune validă. Webhook-urile au nevoie de două lucruri pe care acțiunile de server nu ți le pot oferi prin design:
- Acces direct la raw request body și la header-e specifice pentru verificarea semnăturilor criptografice (cum e header-ul
stripe-signature). - Control total asupra răspunsului HTTP (să poți trimite un cod 200 OK explicit sau un 400 Bad Request dacă semnătura e invalidă).
Server Actions sunt făcute strict pentru RPC (Remote Procedure Call) între clientul tău de React și serverul tău. Webhook-urile sunt apeluri server-to-server venite de la un terț. Pentru asta, un Route Handler clasic în app/api/stripe/route.ts rămâne singura cale corectă.
Concluzia scurtă
Server Actions câștigă detașat pe mutații din interfață și formulare interne. API Routes câștigă pe webhook-uri, endpoint-uri publice consumate de o aplicație mobilă și upload-uri unde ai nevoie de streaming sau control pe headers. Atât.
Voi cum ați împărțit proiectul? Ați migrat totul pe Server Actions sau păstrați o structură hibridă?