Charting - trdrs Engine API

Quick Charts is the chart library the trdrs platform itself runs: a datafeed-driven chart with drawings, indicators, multi-chart layouts, bar replay and saved resources, drawn over the data and storage your host supplies. It is open source (Apache-2.0) at github.com/Trdrsco/quick-charts; the npm package name is quickcharts. The repository README is the doctested authority for every type this page names — each code block there type-checks against the shipped exports. This page covers one integration: feeding the chart from this engine’s market-data API. The chart consumes interfaces, never a concrete backend, so the same wiring works against your own feed.

Install

The package is not yet published to npm (the staged version is 0.0.0-staging): install from the repository until the first npm release.

git clone https://github.com/Trdrsco/quick-charts
cd quick-charts && npm install && npm run build && npm pack
# then, in your app:
npm install ../quick-charts/quickcharts-0.0.0-staging.tgz lightweight-charts

lightweight-charts (^5.0.0) is a peer dependency: your app owns the renderer version and the chart layers on top of it. Both packages are ESM-only. The stylesheet import is not optional — it carries the chart’s layout as well as its look, and without it the chart has no size and paints nothing:

import 'quickcharts/styles.css'
import { createChart, createUdfDatafeed } from 'quickcharts'

const widget = createChart({
  container,
  datafeed: createUdfDatafeed({ baseUrl: 'https://feed.example.com/udf' }),
})
await widget.ready()

That is a complete charting product: candles and volume, indicators, drawings with persistence, bar replay, session bands, and the legend chrome. createUdfDatafeed is the on-ramp for a UDF-style feed; implementing ChartDatafeed directly is the general path, below.

The two seams

The chart takes two host adapters. Everything else — drawings, indicators, panes, scale modes, the legend, replay — needs no adapter at all.

Seam	Interface	What you supply	What the chart owns
Market data	`ChartDatafeed`	`search`, `resolve`, `history`, `subscribeBars`; optional `serverTime` and `config`	paging, gap handling, session bands, indicator compute over bars, rendering
Saved resources	`ChartSaveLoadAdapter`	list/read/write/delete for charts, layouts, drawing documents and templates	the Save/Load UI, autosave, naming, conflicts

Trading is deliberately not a chart seam. The chart includes no orders, accounts or executions; an application that trades composes those beside the chart through the extension seam (ChartExtension) — host code that draws on the chart, contributes menu rows and commands, and keeps its state inside the chart’s own save blob, taken down completely at teardown.

The datafeed over this API

ChartDatafeed maps onto the engine’s market-data routes nearly one to one. Your server calls them with your firm’s API key; a chart on your own domain consumes them directly once your origin is allowlisted at onboarding. A key never ships to a browser.

Datafeed method	Engine route
`search`	`GET /api/market/symbols` — `hasMore` is exact, so the symbol dialog pages cleanly
`resolve`	`GET /api/market/symbol-info` — the response carries the `SymbolInfo` facts: identity, session, and the price `format`
`history`	`GET /api/market/history` — `countBack` outranks `from`; an empty countBack answer carries `noData: true`
`subscribeBars`	`GET /api/market/stream`, or `GET /api/market/streams` for many charts on one connection
`serverTime`	`GET /api/market/time` — fetch once to compute clock skew
`config`	`GET /api/market/config` — the timeframe format and the request caps

The bar rules the chart relies on are the engine’s own rules, which is why the mapping is direct: bars are ascending and unique with bucket-open times in epoch seconds; a countBack answer is an obligation to reach back across closed sessions; noData: true appears only on a countBack ask; and the stream replays a full snapshot on every connect and reconnect, so there is nothing to recover client-side. The repository README states the full contract with compile-tested examples.

Saved charts and layouts

Saved charts, layouts, drawing documents and templates are entities behind one small adapter. memorySaveLoadAdapter serves a demo; if your saved resources live behind HTTP, createRestSaveLoadAdapter implements the same contract over five routes per resource family:

import { createRestSaveLoadAdapter } from 'quickcharts/adapters/rest'

const saves = createRestSaveLoadAdapter({ baseUrl: 'https://api.example.com/chart-storage', request: fetch })

The exact wire contract ships with the package as dist/rest-openapi.json, an OpenAPI document generated from the typed contract the adapter implements, so your backend can be built and tested against a schema rather than prose. A saved entity’s content is opaque to your store: pass it through unchanged.

Trading beside the chart

For a turnkey build, the commercial Trading Platform tier composes trading around the chart: a reference ChartDatafeed over this API, plus the trading surfaces — trade lines, an order ticket, an account manager — over the engine’s account and order routes, the same idempotent order machinery, risk locks and account streams the trdrs product itself runs on. Those packages are delivered with onboarding under a commercial license. A host with its own backend implements the quickcharts interfaces instead and never needs them.

Versioning

Semantic versioning, enforced at the library’s own gate: every exported name is pinned by an API-surface test, new seam capabilities arrive as optional methods (absence reads as “unconstrained”), and a deprecated export keeps working for the remainder of its major with the replacement named in the types. An integration keeps compiling by standing still within a major.

​Install

​The two seams

​The datafeed over this API

​Saved charts and layouts

​Trading beside the chart

​Versioning