Backend Integration
The chart is a browser component. Every price it draws and every order it submits comes from infrastructure you own. That infrastructure has three jobs: expose the surfaces the chart calls, map each kind of market data onto an SDK contract, and reach real venues over FIX, vendor APIs, or a broker.
Nothing here requires a specific language, cloud, or broker. The SDK defines three contracts; how you satisfy them is yours.
The architectural rule
The browser never holds a venue session or a broker credential. FIX runs over raw TCP with sequenced, stateful sessions — a browser cannot open one, and it should not be trusted with one even if it could. Your backend terminates every upstream session and re-publishes normalized data over transports a browser can use.
Everything inside the trusted box is code you write. The SDK only ever talks to the gateway.
The three contracts
| Contract | Backend responsibility | Reference |
|---|---|---|
MarketDataFeed | Serve bars, and optionally quotes, depth, tape, events, and news | Data types |
TradingBrokerAdapter | Report accounts, orders, positions, executions; accept order intents | Broker integration |
| Storage backend | Persist chart layouts, drawings, templates, user settings, and replay state | Backend integration |
Only loadBars and placeOrder are structurally required by their contracts. A
chart backed by nothing but a bars endpoint is a complete, supported
integration — add the rest when the product needs it.
Pick a topology
Firm size changes the topology far more than it changes the code. The SDK contracts are identical in all three columns below.
| Individual / solo trader | Emerging fund, 2–20 seats | Established fund / prop desk | |
|---|---|---|---|
| Market data | Broker-supplied or one vendor API | One vendor, cached server-side | Direct venue feeds plus a vendor for reference data |
| Execution | Broker REST/WS (IBKR, TradeZero) | Broker API, possibly two brokers | FIX to broker or venue, with drop copy |
| Gateway | Single process next to the app | Dedicated service, horizontally scaled | Colocated session layer plus a regional gateway tier |
| Entitlements | Personal subscription | Per-seat, enforced at the gateway | Per-seat and per-feed, audited |
| Latency target | Seconds | Sub-second | Microseconds at the session layer |
The migration path is additive. A gateway written for one broker's REST API keeps its shape when a FIX session replaces the broker behind it, because the chart-facing contract never changed.
Choosing a data source
Brokers and data vendors are independent choices. TradeZero, for example, executes orders but publishes no market data at all, so a TradeZero chart always pairs a data vendor with a TradeZero execution adapter. See TradeZero.
Next steps
- Market data types — every data type the chart renders, its exact SDK method, and the normalization rules that keep the chart correct.
- Build the data gateway — REST history plus one multiplexed WebSocket, with sequence-gap and resync handling.
- FIX protocol — session and application layers, market data and order routing, tag-by-tag mapping to SDK types.
- Market data vendors — Databento, Alpaca, and Massive mapped onto
MarketDataFeed. - Interactive Brokers — desktop-app authorization, IB Gateway, Web API, FIX CTCI, and the pacing limits that shape your cache.
- TradeZero — execution-only integration and the split-backend architecture it forces.
- Fund deployment playbook — day one to production for a desk that has to run this itself.