hirosystems
Investigate providing API-powered alternatives to `/v2/pox` and `/v2/info`
These endpoints are hit pretty often and can take several seconds to resolve. It looks like the API could implement endpoint(s) that provide the same data. It may require modifications to the stacks-node event emitter to include any data that the API can't currently derive from its own DB.
A simple solution could just be include the /v2/pox and/or /v2/info data inside the existing /new_block payload, and implement a new endpoint like /extended/v1/pox that just returns the same data.
@zone117x : The crux of the issue seems to be Blockchain related and might need updates to the Blockchain for a clean fix. cc: @kantai
Can you provide any more details on what you're thinking about for the stacks-node on this issue? Are you thinking that this should be solved by just making the stacks-node faster? Or is the idea to add event data that makes this solvable from the API?
If the idea is that the stacks-node should just be faster for these endpoints, I'd tend to agree, but I think it's probably unlikely to be a quick and fruitful avenue for improvement. The network stack of the stacks-node is fundamentally custom-built, and these endpoints being slow would be a result of that network stack being totally synchronous (this is because these endpoints are just actually very cheap, so taking multiple seconds to respond means that the nodes are just busy doing other things). Making that network stack "async" would would be a large undertaking, with definite implementation risk, and may not even result in a solved problem.
My initial thoughts when creating this issue where that the /new_block event could include additional data (i.e. the /v2/pox and /v2/info data), which the API could store and serve under a new /v1/extended endpoint. We'd then migrate our products to use the faster /v1/extended endpoints, and provide guidelines to them in the docs.
