import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';
// Permite rularea pe Edge pentru latență minimă
export const runtime = 'edge';
export async function POST(req: Request) {
const { messages } = await req.json();
const result = await streamText({
model: openai('gpt-4o-mini'),
messages,
onFinish({ text }) {
// Aici poți salva asincron în DB printr-un fetch HTTP extern
console.log('Stream terminat. Răspuns:', text);
},
});
return result.toDataStreamResponse();
}Salutare! Am lucrat recent la o integrare de chat cu GPT-4 pentru un startup de analytics și clientul voia neapărat acel efect de "typing" în timp real. Dacă aștepți ca LLM-ul să genereze tot răspunsul înainte de a-l trimite, utilizatorul dă refresh crezând că s-a blocat aplicația. Am trecut de la un timp de răspuns de peste 3 secunde la sub 150ms pentru primul token prin streaming.
De la SSE custom la Vercel AI SDK
La început, acum vreo doi ani, făceam asta „la mână” cu Server-Sent Events (SSE) clasice și ReadableStream. Era un chin infernal cu headerele, encoding-ul în UTF-8 și gestionarea reconectărilor pe client. Trebuia să scrii parser de stream în React, să te asiguri că nu pierzi caractere pe drum și să gestionezi manual starea UI-ului.
Între timp, băieții de la Vercel au scos biblioteca ai (Vercel AI SDK) și viața a devenit mult mai simplă. SDK-ul lor abstractizează tot boilerplate-ul de stream. Pe backend, tot ce faci este să folosești funcția streamText din providerul ales (OpenAI, Anthropic etc.) și să returnezi un toDataStreamResponse().
Pe frontend, hook-ul useChat din aceeași librărie se ocupă de tot ce înseamnă state management. Îți dă direct array-ul de messages, funcția handleSubmit, starea de isLoading și valoarea din input. Se ocupă singur de apelul POST către /api/chat și face append la tokeni pe măsură ce vin din rețea.
Problema cu Edge Runtime și baza de date
Arată minunat în demo-uri, dar în producție dai de pereți destul de repede. Cel mai mare trade-off apare când vrei latență minimă. Pentru streaming rapid, e recomandat să rulezi endpoint-ul de API pe Edge Runtime (de exemplu Cloudflare Workers sau Vercel Edge).
Problema e că în Edge Runtime nu ai un mediu Node.js complet. Dacă vrei să salvezi istoricul conversației direct în baza ta de date SQL clasică (Postgres/MySQL) chiar în timpul request-ului, o să te lovești de faptul că driverele clasice de DB nu funcționează pe Edge din cauza lipsei suportului pentru TCP sockets.
Am pățit asta la un proiect cu 8k utilizatori activi. Am încercat să facem insert în DB direct în ruta de API, iar Edge Runtime-ul crăpa constant sub sarcină mare din cauza pool-ului de conexiuni. Soluția? A trebuit să folosim un serviciu HTTP-based pentru baza de date (cum e Neon sau Upstash Redis pentru sesiune) sau să mutăm salvarea istoricului pe client, printr-un webhook asincron declanșat după ce stream-ul s-a terminat, folosind callback-ul onFinish oferit de SDK.
Când merită și când nu?
Vercel AI SDK e incredibil de bun dacă vrei să livrezi rapid un feature de chat sau text generation și folosești Next.js. Îți salvează lejer 20-30 de ore de muncă brută pe care le-ai fi pierdut scriind parsere de stream-uri de text.
Totuși, dacă ai nevoie de un protocol de comunicare bidirecțional complex (de exemplu, vrei ca utilizatorul să poată întrerupe stream-ul și să trimită date noi pe aceeași conexiune), WebSocket-urile clasice rămân sfinte. Vercel AI SDK e gândit pe modelul request-response unidirecțional (de la server la client via SSE). Pentru chestii extrem de customizate sau enterprise unde nu vrei vendor lock-in în ecosistemul Vercel, s-ar putea ca un backend separat în Python (FastAPI) sau Go care expune un stream SSE curat să fie o alegere mai sănătoasă pe termen lung.
Voi cum gestionați salvarea istoricului de chat când folosiți Edge Runtimes? Mergeți pe callback-uri asincrone sau ați mutat complet logica de LLM pe un backend separat?