Comparison of Web Push Technologies and Practical Implementation for Real‑Time Order Notifications

When a project requires real‑time notification of online orders, keeping the client and server synchronized is essential. This article reviews several widely used web push methods to help developers choose an appropriate solution.

1. Common Push Techniques

1.1 Short Polling – The front end uses setInterval or setTimeout to send periodic HTTP requests. It works in all browsers but can cause “fake freeze” when the page is busy and generates unnecessary network traffic.

1.2 Long Polling – The client sends a request that the server holds open until data is available or a timeout occurs, then the client immediately issues a new request. It reduces wasted requests but still consumes server resources and may time out.

1.3 Iframe Streaming – A hidden iframe is created with its src pointing to a data endpoint. The server pushes JavaScript snippets into the iframe, which call a parent‑page function to update the UI. Steps include hiding the iframe, setting the source URL, defining a parent callback, and reloading the iframe after a timeout. Advantages are broad browser compatibility; disadvantages include loading indicators in IE/Firefox and extra server overhead.

println("<script>父级函数('" + 数据 + "<br>')</script>")

1.4 WebSocket – A full‑duplex protocol built on TCP, upgraded from HTTP via the 101 status code. After the handshake, both sides can send frames asynchronously. It offers low latency, binary support, and high performance, but requires server redeployment and may need additional parsing logic.

1.5 Server‑Sent Events (SSE) – Similar to long polling but the server keeps the connection open and streams events to the client. It uses the text/event-stream MIME type, works only in modern browsers, and automatically reconnects on disconnection. It is simple to implement and has low development cost, though it lacks binary support and is not IE‑compatible.

2. Comparison Table

Short polling: excellent compatibility, simple, but high memory and request overhead.

Long polling: similar drawbacks to short polling.

WebSocket: full‑duplex, low overhead, higher security, but requires extra parsing and server changes.

SSE: easy to use, low cost, but limited to modern browsers.

3. Project Selection

Our project runs in a modern‑browser environment and only needs server‑to‑client one‑way pushes, so SSE was chosen over WebSocket (which needs server redeployment) and polling methods.

4. Practical Implementation

Order messages are placed into a Redis cache by application A. Application B polls Redis; when a new order appears, it pushes the message to the front end via the selected SSE channel. Diagrams illustrate the backend flow, client onmessage handling, and server configuration (setting produces="text/event-stream" ).

Common Issues and Solutions

Identifying new messages: a local cache compares the latest Redis data with the previous snapshot.

Message loss on page refresh: a random num value is added to the cache key to differentiate sessions.

Container timeout: backend containers have a 2‑minute connection timeout; the service polls Redis every 3 seconds and pushes a marker after 20 attempts.

Preventing request flooding: the backend tracks request counts per num and returns HTTP 204 when a threshold is exceeded.

Conclusion

For simple push requirements without legacy‑browser support, Server‑Sent Events are recommended; for bidirectional real‑time data or binary transmission, use WebSocket; and for environments that must support older browsers, fallback to polling.