Thanks for the info here @dan. Can you please explain how API endpoints/block producers will respond to API requests in a timely fashion?
I understand that they'll independently be handling the scaling within their own node through read replicas, and data storage over IPFS. But each asset will have to have an endpoint. How's the DNS and http request proxying being handled for this?
The same question goes for general API requests. It's the http/https proxying and speed that I'm most concerned about. Would a developer/end user post a transaction to the chain, and then have to wait for the response by checking that transaction?
How do you see this happening? And, would real-world use of this result in delayed response times, requiring a developer to deal with this in a more presumptuous fashion? AKA, assuming that a POST request, for instance, will be successful prior to actually getting back the response, and if there is a failure, dealing with that retro-actively within an application.
RE: Introducing EOS.IO Application Stack