Client architecture

The diagram shows a client integration pattern that separates public connections, data processing and presentation. Exact decimal handling supports both input validation and display.

Commands. Initial reads and explicit actions use the product API.

Live state. Validated WebSocket updates feed the state observed by account, order and market views.

Presentation. Charts, tables and order entry consume consistent account and market data. Affected values remain visibly stale until their source has been reconciled.

The Edel terminal uses React and TypeScript, with Rsbuild/Rspack for its single-page application. Navigation and interface state are separate from high-frequency market data. Dedicated data processing and subscription-based stores let the interface observe updates without making every incoming message a component render.

For your own client, separate the product API connection, data validation and state updates from presentation. Use REST for initial state and explicit commands, and WebSockets for supported ongoing market and account updates.

A trading client translates user intent into commands, maintains market and account state, handles exact financial values, and renders charts and tables. Clear interfaces between these responsibilities let multiple views share the same data and validation rules.

Generate API types from the published schemas and centralize command and subscription handling. Use public product fields for trading operations. When owner onboarding or funding requires ledger identifiers, keep that handling within its dedicated integration layer.

The terminal uses a dedicated Web Worker to parse and reduce public market frames. The browser connection controller bounds incoming work, while store publication is coordinated with browser frame scheduling. Achievable frame rate depends on workload and device capacity.

Large account tables use virtualization, and charts load through an adapter. When building another client, separate chart rendering from data acquisition and load expensive chart features only when needed. Keep connection and stale-data states visible even when the interface is under load.

Bind each preview to the order draft and account context that produced it. A change to the instrument, side, amount, price or relevant account state can invalidate that preview. Recalculate through the supported preview flow before treating an estimate as current.

Submit commands through one consistent path that preserves client identity and idempotency. Show pending, accepted, rejected or unresolved feedback from the command result, then use authoritative account updates to confirm fills and position changes. See Order API and Account streams.