Друзі привіт - як ваш день?) Сподіваюсь ви та ваші близькі в безпеці.

Ну шо, продовжимо нашу тему

Протоколи для QA. - SSE

Сьогодні поговоримо про SSE (Server-Sent Events). І я майже впевнений, що багато хто з вас уже з цим працював, навіть не знаючи його назви)

Так що я маю вам сказать. Ви ж користуєтесь умовно чатом гпт?? Помічали, як відповідь з'являється поступово, а не вся одразу? так от, один зі способів реалізувати таку поведінку це саме SSE.

Тобто SSE це механізм передачі подій від сервера до клієнта через HTTP. На відміну від WebSocket, тут комунікація одностороння: сервер → клієнт.

І тут для КУА починається цікаве) Уявімо: ви тестуєте якись то аі-чат. Відповідь почала приходити, але на половині тексту зупинилась. Або після reconnect частина повідомлення дублюється. Або сервер відправляє події, але в UI вони з'являються всі разом через 20 секунд.

І це не обов'язково баг ШІ чи фронтенду. Проблема може бути в HTTP-з'єднанні, proxy buffering або обробці reconnect.

І звісно цеж можно перевірити))
Відкриваємо DevTools → Network і шукаємо запит із Content-Type: text/event-stream.

Або ще краще через термінал:
curl -N -H "Accept: text/event-stream" https://your-server/events

І дивимось, чи реально події надходять поступово.

Ще цікаво перевірити, що буде, якщо обірвати мережу посеред відповіді, відновити з'єднання або залишити його відкритим на декілька хвилин.

Мій Поінт до вас простий: HTTP 200 OK ще не означає, що streaming працює правильно. З'єднання може бути успішним, а користувач так і не отримати повну відповідь.

Тому коли тестуєте чати, live notifications або будь-який streaming перевіряйте не тільки результат, а й сам процес доставки даних.

Сильні 💛
Обняв 🤗