Author Topic: [Evaluation]Need for rest API based on new archtechture?  (Read 1658 times)

0 Members and 1 Guest are viewing this topic.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
AFAIK there are many improvements in Steem, one of them is to reduce quantity of requests made to witness nodes, by storing some data into a mysql database (data feed by a node). With this database, developers can interact with the chain easier, since more developers are familiar with traditional databases. However, due to possible reorganizations (forks), it's not ideal to store data later than last irreversible block into the database. IIRC alt met one similar issue in the 0.x days and lost some money due to a unintended fork, I'm not sure in the new design if it's optimized/fixed (although with Graphene we didn't have serious forking issue so far, we're dealing with people's money, IMHO we should be serious).

In regards to REST API, I'm not sure what's the point? IIRC currently nodes can serve HTTP requests directly, if not, I think it's not hard to add, at least it's done in Steem.
BitShares committee member: abit
BitShares witness: in.abit

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
telegram:ebit521
https://weibo.com/ebiter

Offline bitcrab

  • Committee member
  • Hero Member
  • *
  • Posts: 1928
    • View Profile
  • BitShares: bitcrab
  • GitHub: bitcrab
@alt has worked on his private project btsbots https://github.com/pch957/btsbots for long time, he adopt some special archtecture in this project for high throughoutput, simply speaking, at server side one new layer is added to the api node, this layer subscribe transaction data from lower layer, preprocess it and generate a new database which suit for clients' query, and provide these data to client through meteor's ddp protocol.

while the "new api node" provide data such as open orders, transaction history, encrypt memos there's no need for api request to witness-node,only when client need to broadcast new transaction an api request to witness-node is needed. under this design the server side can handle higher throughoutput.

we are now considering one possiblility: is it possible to build general rest API for DEX based on this architecture? if yes we can have general http api for DEX with good throughoutput capacity, it is definitely good news for current and potential bot runners and will attract more users to DEX.

as alt said he hasn't design general APIs while develop btsbots, however he can develop them if there is clear demand, if he works 5 hours per day, he can finish the work in no more than one month.

I'd like to get more inputs on this idea, will this help BTS a lot? is the archtechture suitable for public usage? if the feedback is positive enough we can begin the next step.
Email:bitcrab@qq.com