mattsta
commented
4 days ago The primary problem is IBKR is a fairly bad bulk data service. Fetching more than one option chain per minute slows down to blocking for 20 seconds to 90 seconds each time where no other data requests can happen due to IBKR's "data pacing limits" (there is no practical reason for slow data retrieval other than IBKR still acts like it's the 1970s in some of their APIs).
Services with usable data APIs like Tradier or Polygon.io provide better loading of the same data in milliseconds instead of 90 seconds through IBKR.
Also, since option chains don't change during the day (they can only add new strikes overnight between market sessions), fetched chains should be cached for the remainder of the day after their first request.
The real problems with option chain fetching all just on the user:
- figuring out the expiration dates per instrument
- deciding when requesting too many strikes at once blocks your client for too much time
- deciding what to cache and for how long (then how to integrate the cache into your application)
We don't have an additional utility library for extra non-network-API usage like that, but feel free to sponsor additional work.
Practically, ib_async should probably remain a simple dependency-light IBKR-API-only library, but we could make an additional higher level utility library package including things like transparent caching, automatic market date discovery, data pacing awareness, etc.
Many people are building the option chain on their own. It could be nice having a built function that builds the option chain based on multiple params like: symbol,day to expiration, right range of strike/delta and more