Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Feature Request Poll #243

Open
Olshansk opened this issue Dec 16, 2020 · 0 comments
Open

Feature Request Poll #243

Olshansk opened this issue Dec 16, 2020 · 0 comments

Comments

@Olshansk
Copy link
Collaborator

Olshansk commented Dec 16, 2020

I wanted to get the community’s opinion on your most requested features!

The poll is mainly focused on get_historical_data message count optimizations since there have been a lot of requests and comments related to it in the past, but please do leave a comment if you think there’s something else.




A. Explicit date range in the past

Due to limitations in iexcloud’s API, there is no easy way to retrieve historical data for a specific range at some point in the past. This will currently use up a large chunk of quota, but we could build a feature that would optimize message count usage.

Example use case: Retrieve historical prices for a 5 day range 10 years ago while only using up the message count for 5 days.
Reference: https://iexcloud.io/docs/api/#historical-prices

B. Periodically append to cached historical data

If you need to periodically do some analysis (or train a model) on the last X years on data, you may want to cache it and periodically append to it. Requesting many years of data every week is wasteful, but we could build a feature that caches the data and appends to it.

Example use case: Get the last 10 years of data every week, but only use up quota for 7 days after the very first call.
Reference (caching data is okay): https://intercom.help/iexcloud/en/articles/2960973-can-i-cache-data

C. Message count visibility and configuration

This can include, but is not limited to:

  • Setting a maximum allowed message count such that requests will fail if the total count exceeds it. This can potentially prevent bugs from using up all your quota.
  • Programmatically access/retrieve the distribution of your message count usage.

Example use case: Stop making any requests if my message count exceeded 200,000.
Reference: The IEX cloud dashboard has really nice graphs for this, but there is no way to access the data programmatically.

D. Other.

Let us know if you have any other burning requests! (Comment below)

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants