๐๐ผ๐ ๐ ๐๐ถ๐ ๐ฒ๐ฑ ๐ ๐ ๐๐ ๐๐ต๐ฎ๐๐ฏ๐ผ๐ ๐๐ฎ๐ด ๐ช๐ถ๐๐ต ๐ฆ๐ฆ๐
I built an AI chatbot for my developer blog.
The goal was simple. Users ask questions and the bot answers using my content.
The first version failed. Users typed a question and waited ten seconds. They saw a loading spinner and then a huge block of text appeared all at once. It felt slow and broken. My bounce rate went up by 50%.
I tried three ways to fix it:
- Plain fetch: I waited for the full JSON response. This caused long hangs and high latency.
- Polling: I checked the server every second for updates. This hammered my server and felt janky.
- WebSockets: This felt too complex. I had to manage connection states and heavy overhead for a simple widget.
Then I found Server-Sent Events (SSE).
SSE allows the server to push text tokens to the client one by one. It uses a standard HTTP connection. It is lightweight and easy to implement.
I switched my backend to an Express server. I set the header to text/event-stream. Now the server flushes each token as it arrives.
On the frontend, I used the Fetch API with a reader. This allows the browser to process the stream as it comes in.
The result changed everything. The response appears token by token. It creates a real-time typing effect. Users no longer stare at a loading spinner.
You should know the trade-offs:
- SSE is one-way. Data flows from the server to the client only.
- You must manage your own retry logic if you use Fetch streams instead of the EventSource API.
- Keeping many connections open uses server resources.
If you build real-time tools like live logs or AI chats, do not overcomplicate your stack. You might not need WebSockets. SSE often solves the problem.
How do you handle streaming data in your apps? Let me know in the comments.
Optional learning community: https://t.me/GyaanSetuAi