will it be streaming too so we don't have to keep polling the price feeds every few seconds for updates? lol

Maybe I was a bit tired last night, but after looking at this again, I think I may see part of the problem, starting from when you wrote:

>Does it need to use a websocket or can pubsub be achieved by other means?

For example, you talk about "saving from latency" and a "fully native" API.  From the added context, respectfully, I think those things may mean something very different for me (and for the steemit devs) than they do for you.  For example, if you're concerned about latency, clean code, etc, why would you be thinking of adding extra layers of external dependencies and complexity such as grpc?  

And if you're already doing pull requests on their code while thinking on a completely different level than they are, well, put it this way.  I wouldn't be comfortable touching their code without being pretty darn sure I know it inside and out (short of some very obvious bug fixes). 

From your own code, you see that you are already talking to steemd with a websocket!  From my perspective, the steemd is already easily accessible from **ANY** language (and over the net via wss://).  It uses json-rpc.  It doesn't get much simpler than that!  It would be nice, though, to be able to do something like:

>'{"jsonrpc": "2.0", "method": "call", "params": ["database_api", "sub_order_book", [10,protobuf]], "id": 3}'

to open a stream of order book updates, in json or even better, maybe as a protobuf (to save bandwidth).

In fact, this describes what I was saying perfectly, though I'm not sure why the decision was made to remove *asynchronous notifications* (which to me means **subscriptions**):

>Websockets are provided by steemd because they're what we use to implement steemit.com. The steemit.com website is essentially an in-browser JavaScript implementation of most of the cli_wallet functionality (with lots of additional functionality and a pretty GUI as well, of course). Websockets are much saner to use for modern interactive web applications than HTTP connections. ***In BitShares, the previous Graphene-powered blockchain, websockets were also used for the server to send asynchronous notifications to the client, but Steem currently has little to no functionality that uses websockets in that way.***

https://steemit.com/theoretical/@theoretical/how-to-use-the-steem-api

And regarding @officialfuzzy's "promises", I thought he meant this (but perhaps I missed an intended "double entendre" lol):
https://scotch.io/tutorials/javascript-promises-for-dummies

As for latency, you should also read @dantheman's recent post on how he's thinking about "latency":
https://steemit.com/blockchain/@dantheman/blockchains-should-be-designed-like-massively-multiplayer-games

<p>This post has been ranked within the top 25 most undervalued posts in the first half of Mar 27. We estimate that this post is undervalued by $9.63 as compared to a scenario in which every voter had an equal say.</p> 
<p>See the full rankings and details in <a href="https://steemit.com/curation/@screenname/the-daily-tribune-most-undervalued-posts-of-mar-27---part-i">The Daily Tribune: Mar 27 - Part I</a>. You can also read about some of our methodology, data analysis and technical details in <a href="https://steemit.com/curation/@screenname/introducing-the-daily-tribune-most-undervalued-posts-of-nov-04---part-i">our initial post</a>.</p>
<p>If you are the author and would prefer not to receive these comments, simply reply "Stop" to this comment.</p>

#steemdev a good tag for dev stuff.
https://steemit.com/active/steemdev