๐๐ผ๐ ๐ ๐๐ถ๐ ๐ฒ๐ฑ ๐ ๐ ๐๐ ๐๐ต๐ฎ๐๐ฏ๐ผ๐ ๐๐ฎ๐ด ๐ช๐ถ๐๐ต ๐ฆ๐ฆ๐
I built an AI chatbot for my developer blog. It was a disaster at first.
Users would ask a question. They would see a loading spinner for 30 seconds. Then the whole answer would appear at once. It felt slow and broken. My bounce rate went up by 50%.
I tried three things before finding a fix.
Plain Fetch I sent a request and waited for a full JSON response. This caused long delays for long answers. The connection would often hang.
Polling I sent a request and then asked the server for updates every second. This worked, but it put too much load on my server. The user experience still felt clunky.
WebSockets This sounded good for real-time data. However, it was too complex. I had to manage connection states and handle reconnections. It was overkill for a simple chat widget.
Then I used Server-Sent Events (SSE).
SSE is a lightweight way to push data from a server to a client. The server sends text tokens one by one. The client listens and displays them immediately.
I switched my backend to an Express server. I set the header to text/event-stream. This allows the server to flush each token as it arrives.
On the frontend, I used the Fetch API with a reader. Now, the text appears word by word as the AI generates it. It looks like the AI is typing in real time.
There are some trade-offs to consider:
โข One-way communication: SSE only sends data from the server to the user. โข Reconnection: If you use the Fetch API instead of the EventSource API, you must write your own retry logic. โข Server load: Keeping many connections open uses server resources.
SSE solved my problem without adding complex tools to my stack. If you build tools that need real-time updates like AI responses or live logs, check if SSE works for you before choosing WebSockets.
How do you handle streaming data in your apps?