import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';
export const runtime = 'edge';
export async function POST(req: Request) {
const { messages } = await req.json();
const result = streamText({
model: openai('gpt-4o-mini'),
messages,
});
return result.toDataStreamResponse();
}Dacă aștepți ca un model gen GPT-4o sau Claude să-ți genereze tot răspunsul înainte să trimiți ceva către client, utilizatorii tăi vor pleca din aplicație. Am trecut recent un modul dintr-un SaaS cu 12k query-uri zilnice pe un workflow bazat pe streaming, iar Time-To-First-Byte (TTFB) a scăzut de la 4.2 secunde la sub 180ms. Iată ce am învățat implementând Server-Sent Events (SSE) cu useChat din Vercel AI SDK pe Next.js App Router.
De ce SSE și nu WebSockets pentru LLM-uri?
Când începi să construiești o interfață de chat, prima tentație este să arunci un WebSocket. Am făcut și eu greșeala asta acum câțiva ani. Pentru un LLM, fluxul de date este în proporție de 95% unidirecțional: clientul trimite un prompt, iar serverul transmite un stream de jetoane (tokens).
Server-Sent Events (SSE) este mult mai potrivit aici. Funcționează peste HTTP standard, nu necesită un server dedicat de WebSockets și trece fără probleme prin proxy-uri corporative sau firewall-uri rigide. Pe lângă asta, la un volum de 8k utilizatori activi, am economisit în jur de 35% la resursele de infrastructură trecând de la WS la SSE pe Edge Functions, pentru că nu mai menținem conexiuni bidirecționale grele stocate în memorie.
Vercel AI SDK și magiile din useChat
Dacă în trecut trebuia să decodezi manual un ReadableStream cu TextDecoder și să gestionezi stările de UI, acum Vercel AI SDK rezolvă aproape tot boilerplate-ul. În client folosești hook-ul useChat, iar în backend un Route Handler simplu.
O chestie de care m-am lovit pe pielea mea: evitați Server Actions pentru streaming dacă aveți răspunsuri lungi. Deși Next.js susține că Server Actions pot face streaming, am observat episoade de buffering ciudat pe Vercel în funcție de regiunea unde rulează Lambda-ul. Un Route Handler clasic (/api/chat) configurat pe Edge Runtime rămâne soluția cea mai stabilă.
Trade-off-uri reale și capcane
Streaming-ul arată fabulos pentru UI-uri de chat text, dar vine cu costuri de complexitate pe care documentația le trece rapid cu vederea:
- Parsing de JSON structurat: Dacă îi ceri LLM-ului să-ți returneze un JSON și vrei să randezi componente UI în timp ce acesta generează (de exemplu, un card de produs),
JSON.parseva arunca erori la fiecare token primit până când obiectul e complet. Ai nevoie de librării precumpartial-jsonca să reconstruiești arborele pe parcurs. - Gestionarea AbortController: Dacă userul închide tab-ul sau apasă "Stop", request-ul HTTP trebuie întrerupt imediat pe backend. Altfel, API-ul OpenAI sau Anthropic va continua să genereze jetoane în fundal, iar tu vei plăti factura întreagă de tokeni fără ca cineva să citească rezultatul.
- Markdown render lagging: Randarea în timp real a unui text Markdown lung poate bloca thread-ul principal de React (UI jank) dacă faci re-render la fiecare token. O tehnică bună e să faci throttle la UI re-render la fiecare 50-100ms.
Cod de start pe backend
Iată cum arată setup-ul minimal într-un Route Handler (app/api/chat/route.ts) folosind funcția streamText din SDK-ul recent de la Vercel.
Concluzie
Efortul de a trece pe streaming merită fiecare minut, mai ales pentru percepția de viteză pe care o primește utilizatorul. Totuși, fiți atenți la anularea conexiunilor nefolosite pentru a nu arunca bani pe tokeni generați în gol.
Voi ce folosiți pentru cazurile complexe în care aveți nevoie de streaming structurat (Tool Calling)? Folosiți abstracțiile de la Vercel sau preferați un pipeline custom scos din Python/FastAPI?