Understanding SSE(Server-Sent Events) and Its Benefits
SSE (Server-Sent Events) is a unidirectional communication protocol between clients and servers based on the HTTP protocol. It enables servers to push data to clients in real-time using event streams without requiring explicit requests from clients. Built upon the standard HTTP protocol, SSE utilizes unidirectional persistent connections, allowing servers to actively send events and data to clients.
In essence, it is implemented using a streaming approach, where the client initiates a connection request to the server and keeps the connection open. The server then actively pushes messages to the client. The data sent from the server to the client using Server-Sent Events (SSE) must be UTF-8 encoded, and the content type returned is
text/event-stream. For example, when using ChatGPT, when you ask it a question, you will see it displaying the answer word by word. In reality, ChatGPT proactively 'pushes' the pre-computed data to you, using SSE technology to return data while calculating, thus avoiding long interface waiting times that could lead to direct page closure.
Benefits of SSE
Real-Time Communication: SSE offers a real-time communication mechanism, allowing servers to push data to clients actively. This real-time capability makes SSE particularly suitable for applications requiring immediate updates, such as real-time chat, online collaboration tools, real-time data display, and notification delivery.
Reduced Network Load: Compared to traditional polling methods, SSE utilizes long-lived connections. Through a single HTTP connection, servers can push multiple events to clients, avoiding frequent HTTP requests and reducing network load.
Lightweight: SSE is based on the HTTP protocol, supported by existing server software, and simpler to use compared to WebSocket.
Automatic Reconnection: SSE can automatically attempt to reconnect after a connection interruption without requiring additional code. This automatic reconnection mechanism enhances system stability, ensuring continuous communication even in unstable network conditions.
Proxying SSE Services Using API7 Enterprise
In practical applications, leveraging an API gateway to proxy SSE services contributes to enhancing service stability, resolving security and cross-origin issues, and is suitable for handling complex application scenarios. NGINX, as one of the most popular reverse proxy servers, holds a considerable market share.
When proxying SSE services on NGINX, it is necessary to disable
proxy_buffering. However, this configuration must be closed at least at the location level, implying that if there are multiple locations in the system and only a few need to disable caching to support SSE services, it may affect the performance of other non-SSE APIs. Additionally, NGINX's
proxy_buffering configuration lacks flexibility as it cannot be dynamically enabled or disabled at runtime, requiring a configuration reload to take effect, which may lead to service interruption.
API7 Enterprise provides the proxy-buffering plugin, allowing you to more flexibly proxy SSE upstream services. By enabling this plugin in the corresponding routes, you can easily control the caching without the need to reload the entire configuration. This flexibility meets the requirements of SSE service proxying while also addressing performance and dynamic configuration needs.
Testing as below confirms successful proxying of SSE services.
curl "http://127.0.0.1:9080/.sse" -H "Accept: text/event-stream"
data: GET /.sse HTTP/1.1
data: Host: 127.0.0.1:9080
data: Accept: text/event-stream
data: User-Agent: curl/8.1.2
data: X-Forwarded-For: 192.168.65.1
data: X-Forwarded-Host: 127.0.0.1
data: X-Forwarded-Port: 9080
data: X-Forwarded-Proto: http
data: X-Real-Ip: 192.168.65.1
In summary, SSE is suitable for scenarios requiring real-time communication and updates, providing a simple and effective means to achieve this. However, it's important to note that SSE is a unidirectional channel, allowing only servers to send messages to clients. Therefore, SSE may not be suitable for all types of real-time communication needs. For more complex bidirectional communication scenarios, WebSocket or other technologies may be more appropriate.