Part 01
Architecture
Shell Architecture
User Browser
|-- lightweight-charts (candlestick rendering)
|-- React components (symbol selector, timeframe tabs)
|-- Indicator overlays (SMA, BB lines on chart)
|-- Separate indicator panels (RSI, MACD below chart)
|-- Market Summary sidebar
|
v
Your Backend (optional caching layer)
|
v
TickAtlas API
- GET /v1/ohlc (candlestick data)
- GET /v1/indicator (individual indicators)
- GET /v1/multi (batch indicators)
- GET /v1/summary (rule-based market analysis)Reference
Feature Comparison
| Feature | TradingView | Your Platform |
|---|---|---|
| Candlestick charts | Yes | Yes (lightweight-charts) |
| 42 indicators | Yes (built-in) | Yes (via API) |
| Rule-based market summary | No | Yes (/v1/summary) |
| Custom alerts | Paid plans only | Full control |
| White-label | Enterprise only | Yours to brand |
| Monthly cost | $15-60/user | API usage only |
Patterns
Why Build Your Own?
Full Control Custom indicators, layouts, and UX tailored to your trading style
No Subscription Pay only for API calls, not per-seat licensing fees
Embed Anywhere Integrate charts into your app, dashboard, or client portal
Market Summaries Add rule-based market summaries — something TradingView doesn't offer
Production checklist
Tech Stack
1
lightweight-charts — TradingView's open-source charting library (MIT license)
2
TickAtlas API — OHLCV data + 42 indicators + rule-based market summaries
3
React / Next.js — Frontend framework
4
Tailwind CSS — Dark-mode styling
Before you go live
Production hardening
The code above is the happy path. These are the concerns that decide whether it survives contact with a real deployment.
1
Keep the key server-side. The API key authenticates with the X-API-Key header and must never reach a browser bundle. Proxy it, or use a public widget key, which is domain-scoped and revocable. Authentication
2
Handle 429 before you need to. Rate limits are per key and per minute. Back off on 429 rather than retrying immediately, and read the X-RateLimit-* headers on every response. Rate limits
3
Branch on the error code, not the message. Errors carry a stable machine-readable code; the human-readable text can change. Codes were unified in v3.15. Error handling
4
Expect gaps, and do not invent values. Markets close, feeds stall, and a retention window can reject a request outright. Surface an explicit unavailable state rather than substituting a zero or the last known price. Troubleshooting
5
Cache what you poll. Responses are already cached briefly upstream, so polling faster than the data changes spends credits without improving freshness. Cache on your side and poll on the cadence your timeframe actually updates. Pricing and credits
6
Watch retention per timeframe. History depth is set per timeframe, never per plan, so a request that works on D1 can fall outside the window on M1. Check the published windows before backfilling. Timeframes
7
Rotate keys and scope them. Issue a separate key per deployment so one can be revoked without taking the others down, and rotate on a schedule rather than after an incident. Authentication
8
Log the request, not the key. Record endpoint, parameters, status and latency so a failure is reproducible. Never log the key itself, and scrub it from error reports.
Reference map
Related Guides
Everything this guide touches, linked directly — so it never dead-ends.