If you are building a UI that needs to show progress, logs, or live updates, you do not need to jump straight to WebSockets. In many cases, SSE is the simpler and more appropriate choice.It is a browser-friendly way for the server to push events to the client over HTTP. Think of it as a one-way live stream: the server sends updates, and the browser listens.
SSE is a great option when you need server → client streaming and want to keep the implementation simple.
What is SSE?
SSE stands for Server-Sent Events.
It is a browser-native way for the server to push updates to the client over HTTP.
When to use SSE
| Use SSE when | Avoid SSE when |
|---|---|
| The communication is one-way | You need bidirectional chat |
| You want to avoid polling | You need low-latency command/control flows |
| You want a lightweight HTTP-based stream | You need binary transport |
| You want the browser to handle the connection natively |
Examples:
- progress updates
- live logs
- status feeds
- task completion notifications
Why use SSE instead of polling?
Polling means the browser repeatedly asks the server for new data.That creates extra traffic and awkward timing.
SSE is better because:
- the browser opens a single connection
- the server sends events as they happen
- the client gets updates immediately
- you avoid repeated polling requests For a small streaming UI, SSE is often the simplest option.
The backend exposes a stream of chunks and the frontend listens with EventSource. The flow is straightforward:
- the backend writes each chunk as an SSE event
- the frontend receives each chunk in real time
- the UI renders the updates as they arrive
- the app treats stream completion as a normal end state, not an error
This is especially useful for progress UIs, logs, and status updates.
Reference
Full code is available here:
What this sample does
Backend
An ASP.NET endpoint sends streaming chunks as SSE.
Frontend
An Angular service creates an EventSource and exposes the stream to a component.