Live quote ticker in the browser¶
Goal: a lightweight top-of-book ticker (bid / ask / last per symbol) that lives outside the Web UI in your own web page, updating in place as the market moves.
This is the canonical WebSocket example: subscribe to a table, build the initial state, then apply live updates.
Prerequisites¶
- The WebSocket server is enabled (
ami.websocket.port=3410): see Configuration. - A
QUOTEStable (SYM,bid,ask,last) with rows updating; the Quickstart creates it.
The client¶
The pattern is: keep a map keyed by objectId, apply each update, and re-render. On subscribe you receive a status frame and a subscribed ack, in either order, then the current rows as add updates, then a snapshot marker; after that you receive only changes. (objectId is a row id, not the SYM: use it as your map key, but don't try to look rows up by symbol.) See WebSocket API → First messages on connect.
Why merge instead of replace¶
An update frame carries only the changed columns, not the whole row. Merging the update's row onto the row you already hold ({ ...cur, ...u.row }) is what keeps SYM and the unchanged prices intact when only bid changes. Replacing the row wholesale would blank the untouched fields.
What you will see¶
- On connect: a
statusframe and asubscribedack, in either order, then anupdatesframe carrying oneaddper existing symbol, then asnapshotmarker: the ticker is populated. - Continuously:
updatesframes as prices change, coalesced to roughly one flush per 100 ms (see conflation). Fast markets are smoothed, not dropped mid-render.
Notes¶
- Authentication. If the server requires it, connect as
ws://user:pass@localhost:3410/center(browsers can't set an auth header on the handshake). The browser sends these credentials after the server challenges the first attempt with401. - Filter server-side. To watch a subset, add a
WHEREin AMI syntax:SELECT SYM,bid,ask,last FROM QUOTES WHERE SYM == "IBM". To keep a filtered set accurate as membership changes, see focus filtering. - Reconnects. If the socket drops, reopen it and re-subscribe; you'll get a fresh snapshot.
- First-connect warm-up. The very first connection after a server restart can take ~2 seconds before the
statusframe; warm connections are near-instant. Give the initial connect a generous timeout instead of reconnect-looping on a short one (see WebSocket streaming API → First-connection warm-up).