import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';
// Important: definim durata maximă pentru a preveni timeout-ul serverless
export const maxDuration = 30;
export async function POST(req: Request) {
const { messages } = await req.json();
const result = await streamText({
model: openai('gpt-4o'),
messages,
system: 'Ești un asistent tehnic util și concis.',
});
return result.toDataStreamResponse();
}Dacă încă îți pui userii să aștepte 10-15 secunde cu un spinner până când OpenAI termină de generat tot textul, ai o mare problemă de UX. Streaming-ul prin Server-Sent Events (SSE) nu mai este un moft, ci o necesitate absolută ca aplicația ta să se simtă rapidă. Am implementat asta recent pe un proiect intern cu peste 3.000 de interogări zilnice și vreau să povestim despre cum scurtezi timpul de livrare folosind Vercel AI SDK, dar și unde dai de pereți.
De ce Vercel AI SDK și nu fetch manual?
La primele mele experimente cu GPT-3.5 acum doi ani, am încercat să scriu manual parsarea de stream. Cine a făcut asta știe despre ce vorbesc: te chinui cu ReadableStream, pui un TextDecoder, prinzi chunk-urile în buclă, încerci să le lipești, gestionezi manual stările de eroare și ai grijă să nu crăpe JSON-ul dacă un chunk se rupe la mijloc. Era un coșmar de vreo 150 de linii de cod pline de potențiale bug-uri.
Vercel AI SDK rezolvă exact această frustrare. Pe client, hook-ul useChat se ocupă de tot: păstrează istoricul conversației, trimite automat mesajul nou la API, face append la textul primit în timp real și îți dă flag-uri curate precum isLoading. Am economisit cam 40% din boilerplate code trecând la el.
Server-Sent Events la cheie
Pe partea de server (în Next.js Route Handlers), treaba e incredibil de simplă. Folosești funcția streamText combinată cu providerul dorit (OpenAI, Anthropic, Cohere etc.) și returnezi un stream specializat pe care clientul îl înțelege nativ.
Codul de pe server devine extrem de curat, dar magia mare este că useChat pe frontend știe să asculte exact acest stream fără ca tu să scrii vreun socket sau cod de reconectare. Userul vede primul cuvânt generat în sub 300ms, chiar dacă răspunsul final durează 8 secunde.
Trade-off-uri de care te lovești în producție
Sună prea frumos ca să fie perfect, nu? Ei bine, în producție apar problemele reale de arhitectură de care nu scrie pe prima pagină a documentației.
1. Limitările de timeout pe Serverless
Dacă rulezi Next.js pe Vercel Hobby sau chiar pe planul Pro, ai un timeout la funcțiile serverless (de la 10 la 60 de secunde în funcție de plan). Dacă LLM-ul tău are o zi proastă și latența e mare, conexiunea se poate tăia la jumătate. Soluția este să folosești Edge Runtime (adăugând export const runtime = 'edge'), dar asta înseamnă că pierzi accesul la anumite librării de Node.js (cum ar fi unele drivere de bază de date vechi sau utilitare de criptare) în acea rută.
2. Sincronizarea metadatelor (RAG)
Cea mai mare bătaie de cap am avut-o când a trebuit să trimit înapoi nu doar textul generat, ci și sursele (documentele din baza de date vectorială pe care le-a citit asistentul). Cum trimiți JSON structurat în timp ce faci stream de text brut?
SDK-ul are o chestie numită StreamData. Funcționează, dar codul devine rapid destul de greu de citit pentru că trebuie să adaugi manual chunk-uri de date în stream și să le interceptezi pe client în callback-ul onFinish sau prin proprietatea data oferită de hook. Dacă ai nevoie de o logică ultra-personalizată pentru UI, s-ar putea ca flexibilitatea oferită implicit de useChat să devină o colivie de aur și să fii nevoit să revii la un fetch custom.
Voi cum gestionați streaming-ul de date complexe pe lângă textul din LLM? Mergeți pe Vercel SDK sau v-ați scris propriile wrappere peste SSE?