TL;DR

WebSocket keeps one always-open connection so client and server can message each other instantly; Eloqra deliberately uses HTTP polling instead to stay simple and serverless-friendly.

Key Points

✓

A WebSocket connection starts as an ordinary HTTP request that asks to Upgrade, and on success the server replies 101 Switching Protocols and the socket stays open. [1][2]

✓

Once open it is full-duplex: client and server each send frames whenever they want, with far less per-message overhead than repeated HTTP requests. [1][3]

✓

It was standardized by the IETF as RFC 6455 in 2011 and is the lower-overhead alternative to half-duplex approaches like [[http-polling]]. [2][3]

✓

Persistent sockets scale to many concurrent users but add operational weight, load balancers, sticky sessions, and a coordination layer to fan messages across servers. [4]

✓

Eloqra does NOT use WebSocket: the [[live-chat-widget]] refreshes a [[conversation]] by polling for new messages every few seconds, which is simpler to host. [4]

✓

Operator replies still feel near real-time because they arrive through Eloqra's [[telegram-integration]] via a [[webhook]], then surface in the widget on its next poll.

How WebSocket works

A WebSocket connection begins as a normal HTTP/1.1 GET request carrying an `Upgrade: websocket` header and a `Sec-WebSocket-Key`. If the server agrees it answers `101 Switching Protocols`, and the same TCP connection is then repurposed as a persistent, full-duplex channel. ^[1]^[2] From that point either side can send framed messages, text, binary, or control frames, at will, without the request/response ceremony of plain HTTP. ^[3] Standardized by the IETF as RFC 6455 in 2011, WebSocket carries much lower per-message overhead than half-duplex alternatives such as HTTP Polling, because headers and connection setup are not repeated for every update. ^[2]^[3] This makes it a common transport for chat, multiplayer, and live dashboards where latency matters.

Why Eloqra uses polling instead

Despite WebSocket's strengths, Eloqra runs its real-time layer over HTTP Polling rather than a socket. The JavaScript Widget mounted in a Shadow DOM simply re-requests new Chat Message data roughly every four to five seconds and pings a typing endpoint to drive the Typing Indicator. Persistent sockets scale well but bring real operational cost, upgraded load balancers, sticky sessions, and a shared layer (often Redis) to broadcast messages across server instances. ^[4] Polling sidesteps all of that: any stateless HTTP host or serverless function can answer a poll, which suits Eloqra's lightweight, easy-to-self-host design and its audience of indie founders. For a support Conversation that turns over in seconds rather than milliseconds, a short poll interval feels effectively instant. ^[4]

Where real-time still happens

Choosing polling does not make Eloqra feel slow. A Website Visitor message is stored and immediately forwarded to the project owner on Telegram, so operators are notified in real time even though no socket is involved. When an operator replies, from a Telegram reply or the Mini App inbox, the answer flows back through the Telegram Integration over a Webhook and is waiting for the widget on its very next poll. The same loop drives a two-way Typing Indicator and unread counters. The result approximates the responsiveness users expect from a WebSocket-backed Live Chat product, while keeping Eloqra's infrastructure to a handful of plain HTTP endpoints rather than a stateful socket fleet. ^[4]

Sources & References

WebSockets API (WebSockets) - MDN Web Docs ↗

WebSocket - Wikipedia ↗

The WebSocket Protocol: RFC 6455 Handshake, Frames & More - WebSocket.org ↗

Long Polling vs WebSockets: What's best for realtime at scale? - Ably ↗

Last updated: June 25, 2026

Related Terms

HTTP Polling

HTTP polling is a real-time technique where the client repeatedly sends HTTP requests on a fixed interval to ask the server whether new data is available, instead of holding a persistent connection. Eloqra's chat widget uses short polling roughly every 4-5 seconds to fetch new messages and typing state.

Webhook

A webhook is a user-defined HTTP callback: instead of polling for data, an application registers a URL that a source service calls with an HTTP POST request the moment a specific event happens. [1] In Eloqra, a webhook is how an operator's Telegram reply travels back into the chat widget.

Telegram Integration

Telegram Integration is the mechanism by which Eloqra routes every website chat into the project owner's Telegram, forwarding visitor messages to a Telegram bot and flowing operator replies back to the widget. It turns Telegram into the operator inbox, so there is no separate agent console to keep open.

Live Chat Widget

A live chat widget is the embeddable, in-browser chat interface a website loads from a small script so visitors can message a business in real time without leaving the page. In Eloqra it is a floating launcher and chat panel that boots from a single <script> tag and renders inside a Shadow DOM.

Shadow DOM

Shadow DOM is a browser API that attaches a hidden, self-contained DOM subtree to an element, with its own scoped styles that neither leak out to the host page nor get overwritten by it. [1] Eloqra renders its entire chat widget inside a shadow root so the host site's CSS can never break the widget, and the widget's CSS can never alter the host site.

Typing Indicator

A typing indicator is a real-time visual cue, usually an animated three-dot ellipsis, that tells one side of a chat that the other side is actively composing a message [3]. In Eloqra it works both ways: the visitor sees an operator is typing, and the operator sees the visitor is typing.

Collect testimonials that build trust

Eloqra gives you a lightweight live chat widget that routes every visitor message to your Telegram — free while in early access.

Get Started Free