Cool Concept for Consideration: History Provider

[brandonfancher]

Node History APIs are expensive to run. For that reason, that API is not supported by many nodes. Others are coming out with alternative means of getting chain history information. But their APIs may not match the standard History API.

What if we created the concept of a History Provider?

[ismyhc]

This is a great idea. As I am updating Lynx I've started using eosio-swift. Right now I can only use the RpcProvider for the normal chain calls since Lynx now uses Hyperion History for all history requests. I believe a good candidate for this would be Hyperion History obviously :)

https://github.com/eosrio/Hyperion-History-API

This is something Id be willing to help out with in the near future with some guidance from you guys of course.

[brandonfancher]

Nice. I haven't thought too much about this since posting the issue/idea... we already have the concept of an RPC Provider, and the history calls are a subset of that. Another, less intrusive approach might be to just create a new RPC Provider that has the same chain calls but wraps Hyperion for the history calls. @ismyhc

[ismyhc]

Nice. I haven't thought too much about this since posting the issue/idea... we already have the concept of an RPC Provider, and the history calls are a subset of that. Another, less intrusive approach might be to just create a new RPC Provider that has the same chain calls but wraps Hyperion for the history calls. @ismyhc

Right, not a bad approach. Ill take a look at doing it this way and report back.