charting-library-tutorial: a Binance datafeed behind TradingView charts

Two routes, because there are two TradingView products

The project demonstrates a Binance-backed TradingView datafeed, and the thing to understand first is that it demonstrates two different TradingView products at once.

The free one is Free Advanced Charts from the tradingview/charting_library repository. The paid one is the Trading Platform from tradingview/trading_platform. The readme is explicit that you only need the package for the page you want to test, and that if both packages are present, both routes work in the same checkout.

That framing matters because the two routes are not two demos of the same thing. Advanced Charts is the charting component on its own, and it is free. The Trading Platform is the larger product that includes the charting library plus the surrounding application pieces, and it is the paid tier. The tutorial's job is to show you how to connect data to either.

The two URLs the server exposes make the difference visible. The root path is a minimal Advanced Charts example with a chart datafeed, a theme toggle and a documentation button. The /trading path is the Trading Platform example, with a broker sample, the DOM, an account manager, alerts, save and load, a watchlist, quotes, CoinDesk news, toolbar controls and multi-chart support.

The last tested configuration is stated precisely, which is the kind of detail a tutorial should have: June 2026, with TradingView Advanced Charts 31.2.0, Trading Platform 31.2.0, the Binance public Spot REST and WebSocket APIs, CoinDesk RSS, and the npm dependencies from package-lock.json.

The project is JavaScript, MIT licensed, and the last push was on 2026-08-11.

Getting it running, and the part you cannot get from the repository

The setup sequence is short, and there is one step that will stop you if you do not know about it in advance.

For a fresh clone you install the npm dependencies first, then download the TradingView runtime you want to use, then start the server:

npm install
npm run tv:install:tp -- 31.2.0 # tested version
npm run start

And for the free Advanced Charts page only, the install command differs:

npm install
npm run tv:install:ac -- 31.2.0
npm run start

Then you open the server on port 3000, at the root for Advanced Charts and at /trading for the Trading Platform route.

The catch is that the TradingView runtime is not in this repository. You need GitHub SSH access to the TradingView repositories for the install helper to download and place the package for you. If you omit the version argument, the script downloads master, which is a reasonable default for a developer following a tutorial and a poor default for anything you intend to keep running, because master moves.

The two install scripts differ in scope. tv:install:ac installs only the Advanced Charts runtime, into vendor/tradingview/advanced_charts. tv:install:tp installs Advanced Charts and Trading Platform into vendor/tradingview, so the homepage still works as well as the trading route. The readme also notes that for Trading Platform broker features the tp script additionally installs the BrokerDemo bundle, checking the installed package first and then falling back to fetching it from the Trading Platform repository using the same version or git ref. If you place the packages by hand instead, you have to copy the bundle yourself into third_party/tradingview/broker-sample/dist/bundle.js.

The expected directory layout is given, with the package folders at the project root and a charting_library directory inside each holding charting_library.js. The rule that follows from it is simple: use charting_library-master for the free page and trading_platform-master for the trading page, and if only one of them exists, only the matching route is expected to work.

Keeping the runtime in step with the source

There is a specific workflow problem in this project and the readme addresses it directly, which is more useful than leaving you to work it out.

The issue is that the TradingView runtime lives in a separate repository while the example code lives in this one, so they can drift. The sync script exists to reconcile them. If you manually placed charting_library-master or trading_platform-master in the project root, you run:

npm run tv:sync
npm run start

And the readme adds the instruction that catches people out: hard refresh the browser after package changes so old TradingView chunks are not reused. That is a browser caching issue rather than a server one, and the symptom is a page that stubbornly shows the previous version of the runtime.

There is a more specific variant of the same command, tv:sync:ac and tv:sync:tp, which do the same thing for one product or the other, mirroring the two install commands.

The useful notes section collects the operational details in one place, and it is worth reading as a summary of the design. tv:sync copies package assets into vendor/tradingview/. tv:install:ac installs only the Advanced Charts runtime into vendor/tradingview/advanced_charts. tv:install:tp installs Advanced Charts and Trading Platform into vendor/tradingview/. If only charting_library-master exists, only the root route is expected to work, and if only trading_platform-master exists, only the trading route is. npm run start serves the clean routes and the CoinDesk RSS proxy used by the trading route, while npm run start:static is only a static fallback and the Trading Platform CoinDesk news will not load there.

That last distinction is a small example of the difference between the two modes. The static fallback serves files, and the server mode serves routes, which is why the news feed needs the server.

What a datafeed has to answer, and where Binance fits

The reason this example exists is that a charting library is only half of a chart application, and the other half is a datafeed contract that the library expects you to satisfy.

The data source here is the Binance public Spot REST and WebSocket APIs, which is a deliberate choice for a tutorial because they need no account and no key. The public market data endpoints give you the symbol list, the historical candles and the current price, and the WebSocket stream gives you updates without polling, so the example can demonstrate the two halves of a real integration rather than a mock.

That choice also shapes what you should take from it. A production chart application usually has a different data source with different semantics, an account model and a much larger symbol universe, and the part of the work that transfers is the datafeed interface rather than the Binance specifics. The tutorial exists to show the shape of that interface and how it is wired, and the readme points to INTEGRATION_DETAILS.md for the implementation detail.

The other external service in the project is the CoinDesk RSS feed, which supplies the news panel on the trading route. The readme notes that npm run start serves the clean routes and the CoinDesk RSS proxy used by the trading route, and that the static fallback does not serve the news, which tells you the news is fetched server side rather than by the browser, and therefore needs the server process rather than a file server.

Taken together, the pieces a chart application needs are visible in the two routes: a datafeed with history and realtime updates, a symbol and search surface, a server that can reach third party APIs, and a client that renders the result. The tutorial wires all four against a real exchange.

The server, the routes and the pieces of a datafeed

The implementation is in a small number of files, and the repository layout reflects the split between the tutorial's own code and the vendored runtime.

There is a server.mjs that npm run start executes, an index.html for the Advanced Charts page, a trading.html for the Trading Platform page, a src directory with the example implementation, a scripts directory holding the three install and sync helpers, an INTEGRATION_DETAILS.md for implementation detail, a .gitmodules file, and a package.json that is almost entirely scripts.

The manifest is worth looking at because it is unusually small for a project of this size. There are no runtime dependencies at all. The only devDependencies are serve at 14.2.5 and serve-handler at 6.1.7, and both belong to the static fallback. The real work, the HTTP server that serves the routes and proxies the RSS feed, is written directly on the Node standard library.

That is a deliberate choice for a tutorial, and it has a side effect worth noting. Because there is no framework and no HTTP client library, the datafeed code talks to the Binance APIs directly, which means what you are reading is the actual protocol handling rather than a thin wrapper around a client. When you take this into your own project you are likely to replace that with a proper HTTP client, and at that point the example stops being a template for that part.

The manifest is also a good summary of the operational model. Every task is a node script: start runs server.mjs, start:static uses serve, and the four tv tasks call scripts/install-tradingview-package.mjs and scripts/sync-tradingview-assets.mjs with the ac or tp argument.

Editorial conclusion

Adopt this repository as a reference if you are building a chart application on the TradingView Charting Library and want to see a complete datafeed implementation rather than a fragment, since the example wires history, realtime updates, search and symbol resolution against a real exchange API. Do not adopt it as a starting point if you do not have GitHub access to the TradingView repositories, because the runtime is downloaded from there and cannot be vendored from this repository. Before you commit, read INTEGRATION_DETAILS.md, pin the TradingView version you test against rather than tracking master, and expect to replace the Binance backend with your own data source.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. tradingview/charting-library-tutorial on GitHub