Zbudowałem klienta czatu AI ze streamingiem i nie oszalałem

Chciałem zbudować interfejs czatu, w którym AI odpowiada w czasie rzeczywistym. Zależało mi na tym płynnym efekcie maszyny do pisania.

Było to trudniejsze, niż myślałem. Problemem nie było AI. Problemem był potok danych (pipeline) między API a przeglądarką.

Wypróbowałem trzy różne sposoby, aby to rozwiązać.

  1. Metoda oczekiwania Wywoływałem API i czekałem na pełną odpowiedź, zanim ją wyświetliłem. To działało, ale interfejs użytkownika (UI) zamarzał na kilka sekund. Użytkownicy myśleli, że aplikacja się zepsuła. Wielokrotnie klikali „Wyślij”. To było złe doświadczenie użytkownika (UX).

  2. Metoda odpytywania (Polling) Myślałem o tym, aby serwer wysyłał identyfikator zadania (job ID). Następnie klient co sekundę pytałby o aktualizacje. Wymagało to ciężkiego zarządzania serwerem. Aktualizacje pojawiały się w losowych fragmentach. Nie było to płynne.

  3. Metoda WebSocket Wypróbowałem Socket.IO. To dodało ogromną złożoność. Musiałem zarządzać ponownym nawiązywaniem połączeń, sygnałami heartbeat i synchronizacją stanu. Jak na prostą aplikację czatową, WebSockets były przesadą.

Rozwiązanie było prostsze: Server-Sent Events (SSE).

Większość API AI już teraz wysyła odpowiedzi za pomocą SSE przez HTTP. Przestałem szukać skomplikowanych narzędzi i użyłem natywnego fetch API.

Korzystając z response.body.getReader(), czytałem strumień bajtów bezpośrednio. Sam sparsowałem protokół SSE. To podejście sprawia, że UI pozostaje responsywne i korzysta ze standardowego HTTP.

Dlaczego to działa:

  • Nie potrzeba serwera WebSocket.
  • Brak skomplikowanej logiki ponownego nawiązywania połączeń.
  • Działa z każdym API, które obsługuje SSE.
  • Możesz łatwo zatrzymać strumień, używając AbortController.

Istnieją pewne kompromisy.

  • Nie możesz przesyłać aktualizacji do klienta bez zapytania.
  • Jeśli połączenie zostanie przerwane, tracisz częściową odpowiedź.

Jeśli budujesz aplikację czatową, unikaj WebSocketów, chyba że potrzebujesz dwukierunkowej komunikacji. Trzymaj się streamingu HTTP. Jest prostszy i bardziej niezawodny.

Jaka jest Twoja strategia streamingu? Używasz WebSocketów czy SSE? Daj znać w komentarzach.

Źródło: https://dev.to/__c1b9e06dc90a7e0a676b/i-built-a-streaming-ai-chat-client-without-losing-my-mind-3gi0