Yuzu is a new kind of market data API that takes the work out of building using stock market data. Traditional REST-based APIs aren't good fits for frontend apps, as they require developers to make 10s of API calls to render one screen, or to preload gigabytes of the data into their own databases ahead of time.
Yuzu is different. We believe that you should be able to architect your system with a minimum of commodity data in your own database, and rely on us for the rest.
Why is storing my own cache of market data a bad practice?
There are a few reasons why you wouldn't want to store your own copy of market data in your own database. The biggest is that there is a huge data maintenance burden to doing so. Imagine even a basic a relational data model that includes:
Securities (name, type, ticker symbol)Security Prices (time, open, high, low, close, volume, security_id)Crypto Trading Pairs (name, ticker symbol, quote asset, base asset)Crypto Prices (time, open, high, low, close, volume, pair_id)You ingest a bunch of data using traditional REST APIs, and set up jobs to do so on a recurring basis. Great! You're done.
Well, it's not that simple. The stock and crypto markets are ever-evolving landscapes that will require you to be constantly on top of your dataset to detect changes and make sure every market change is accounted for.
Corporate actions like stock splits, IPOs, mergers, SPAC deal closings, and events in the crypto world like listings, delistings, depeggings, and halvenings will all conspire to make your database out of date, and your product quality will suffer. Access to all of the data required to make sure you're tracking every stock split, every divident, every ticker change is traditionally expensive and difficult to manage.
The first problem that you'll run into almost immediately into is that stocks split frequently. In the U.S., there's almost 1 stock split per day among the ~9000 public companies and ETFs that trade on exchanges.
Mutual funds can split too! It hasn't happened too many times, but it can happen, and this too will affect your data quality
When a split happens, all of the previous prices for that security have to be split-adjusted backward in time.
Here's an example: when AAPL splits 7:1, seven new shares are created for each one that previously existed. That means that in order to display prices accurately, adjusted for the split, you'd need to recalculate all the prices in your database before the split date to normalize for the new shares in the market. Otherwise, it would appear as if AAPL dropped 85% on the day of the split.
In the U.S., a stock ticker is changed about once per day. This happens most frequently at SPAC deal closings, where the blank check company will change its ticker symbol to reflect the brand of the company it has acquired. However, tickers can also be reused 90 days after the previous company exited business or went private.
This happened most famously in 2021 when Coinbase took on the ticker symbol of a now-defunct company during its IPO. This resulted in many stock apps displaying COIN as belonging to "Converted Organics" instead of "Coinbase".
Managing these frequent data changes can be a massive headache, especially for small teams lacking time and resources to dedicate to heavy-duty data engineering required to solve these problems.
Crypto is a rapidly evolving set of markets with dozens of new tokens being created every day, and more being delisted. What happens when ETH finally merges and goes to proof of stake? How do you handle the aftermath of Terra, with the mass delisting of UST, Terra becoming Terra Classic, and a new token taking its place? These are all questions you should never find yourself asking.
The reason that everyone ends up building up their own database of market data, and thus runs into these problems, is that the APIs they're using to pull all this data into their databases aren't designed to be used on the frontend. They're designed for the mass moving of data from one server to another (and at that, they're great), but they're often designed in such a way that many API calls would be required to get many varied pieces of data into your UI. Well, this is slow, and so the obvious solution becomes to cache the data at the server level. But there's a better way.
We built a GraphQL API to make fetching data fast and flexible, allowing you to render any screen with just one API call. We then uncapped our streaming API, allowing you to stream data directly to your frontend, without having to proxy it through your own infrastructure.
Yuzu makes opinionated choices about which identifiers we use per asset type. For Securities, we use the FIGI Composite identifier, which won't change through ticker symbol changes. When you look up BBG000B9XRY4, it will always correspond to Apple Inc Common Stock, even if the ticker symbol changes.
We can't wait to see what you'll build with Yuzu!