Vaadin Flow Push Transport: WebSocket vs Long-Polling for Latency‑Constrained Deployments

Goal

Determine whether to rely on Vaadin Flow’s server‑side WebSocket push with automatic fallback to long‑polling, or to configure long‑polling as the primary transport when network latency is unpredictable and servlet container WebSocket support is limited.

Constraints and Uncertainty

• Vaadin Flow 14+ uses WebSocket push by default when @Push is present, falling back to long‑polling only after a failed WebSocket handshake if the client reconnects.
• Long‑polling works with any Servlet 3.0+ container, uses fewer server resources per connection, but introduces higher latency and extra HTTP overhead.
• Documentation does not clarify whether the client automatically attempts a fallback transport without a full page reload or explicit reconnect after a WebSocket failure.

1. Does Vaadin Flow automatically switch from WebSocket to long‑polling on the same client connection after a handshake failure, or must the client page be reloaded/reconnected?
2. If automatic fallback is not guaranteed, what configuration (e.g., @Push(transport = Transport.WEBSOCKET_XHR) combined with a heartbeat) ensures the UI recovers without a full reload?
3. Under what latency and container‑support conditions is it preferable to disable WebSocket push entirely and use long‑polling from the start?