Clarify SSE Architectural Trade-offs and Add WS Comparison

[raipankaj]

The original description of the SSE app used the term "bidirectional," which, while functionally accurate for the user experience, can be technically misleading as the implementation uses two distinct, unidirectional protocols (SSE for output, HTTP POST for input).

Changes Introduced

1. Refined Terminology: Clarified the app's architecture as "hybrid bidirectional" in the document.
2. Added Comparison Note: Introduced a new section, "Performance and Latency Note (SSE vs. WebSockets)," to explicitly outline the trade-offs of using this hybrid approach versus a true WebSocket connection.

Key Points Clarified

1. Upstream Overhead: Explained that the HTTP POST method for client input introduces higher overhead and latency compared to WebSocket framing.
2. Downstream Simplicity: Highlighted that SSE offers simplicity and is often easier to deploy behind proxies/load balancers.

Latency Preference: Recommended WebSockets for scenarios where low-latency input is mission-critical.

This ensures that developers understand the performance implications when choosing between the SSE/POST hybrid and the pure WebSocket implementation.