[API] questions / suggestions for improvement

[monsterer]

Graphene API is just different, it's a paradigm shift - rather than "pulling" data from blockchain it exploits "push" concept allowing creation of close to real time clients.

This is great for non mission critical data, like streaming trades in a candlestick display, or orderbook depth graph, but it doesn't change the way mission critical data is read; you cannot stream historical data, so you must query it, otherwise you could end up out of sync if some part of your system has an outage.

[valzav]

Graphene API is just different, it's a paradigm shift - rather than "pulling" data from blockchain it exploits "push" concept allowing creation of close to real time clients.
It's pretty early in it's development, I expect it would be more user friendly as it mature and we implement more features and bindings. I predict the ideas we up to would have a big affect on all crypto APIs in the mid-term future.

Hey man Been a long time.

So instead of reading the entire blockchain as an observer and picking our trigger events, the blockchain is alerting you pro-actively and you get to passively receive?  That is very interesting, we had to build XChain to do that for us reliably with Counterparty and Bitcoin.  If I understand what you're saying, we would not need to build that with Bitshares, it would talk directly to our vending machines or ecommerce system?

Hey Adam, yes been a long time
Correct, in Graphene the end clients can just subscribe to incoming transactions/balance changes events and update their state accordingly. Not sure what exactly XChain does - looks like its another function is to mirror the blockchain state into traditional database, in your architecture you still might need this layer, but it would definitely be easier to implement in Graphene and it would feel faster for end users.

[svk]

Graphene API is just different, it's a paradigm shift - rather than "pulling" data from blockchain it exploits "push" concept allowing creation of close to real time clients.
It's pretty early in it's development, I expect it would be more user friendly as it mature and we implement more features and bindings. I predict the ideas we up to would have a big affect on all crypto APIs in the mid-term future.

Hey man Been a long time.

So instead of reading the entire blockchain as an observer and picking our trigger events, the blockchain is alerting you pro-actively and you get to passively receive?  That is very interesting, we had to build XChain to do that for us reliably with Counterparty and Bitcoin.  If I understand what you're saying, we would not need to build that with Bitshares, it would talk directly to our vending machines or ecommerce system?

Pretty much, you can get a notification over websocket connection whenever an object (everything in Graphene is an object: accounts, balances, assets, etc) has changed. It's then up to you to react to that change.

That part is actually pretty sweet and far better than BTS 1.

[AdamBLevine]

Graphene API is just different, it's a paradigm shift - rather than "pulling" data from blockchain it exploits "push" concept allowing creation of close to real time clients.
It's pretty early in it's development, I expect it would be more user friendly as it mature and we implement more features and bindings. I predict the ideas we up to would have a big affect on all crypto APIs in the mid-term future.

Hey man Been a long time.

So instead of reading the entire blockchain as an observer and picking our trigger events, the blockchain is alerting you pro-actively and you get to passively receive?  That is very interesting, we had to build XChain to do that for us reliably with Counterparty and Bitcoin.  If I understand what you're saying, we would not need to build that with Bitshares, it would talk directly to our vending machines or ecommerce system?

[valzav]

Graphene API is just different, it's a paradigm shift - rather than "pulling" data from blockchain it exploits "push" concept allowing creation of close to real time clients.
It's pretty early in it's development, I expect it would be more user friendly as it mature and we implement more features and bindings. I predict the ideas we up to would have a big affect on all crypto APIs in the mid-term future.

[svk]

It seems BitShares API is 3 to 4 times more difficult to integrate then anything else I've dealt with.  Why is that?
I hope this doesn't come off too overly critical, I'm happy to work through the difficulty and really only want a better experience others looking to integrate.
I'm not the most skilled or experience programmer, so I may either be mistaken or not understand the reason some things are done, so keep that in mind.  Thanks

I made a post about inconsistent "amount" fields sometimes being strings and sometimes integers
https://bitsharestalk.org/index.php/topic,19566.0.html

Why is this?  can we not keep it one type?

I'd like to see amounts in a consistent type.  So I don't need to catch so many random cases of it being different.

I'd like to see, anytime an Amount is given that it be accompanied by its precision or already adjusted based on precision so I don't have to make 2 or 3 extra calls just to make the conversion.  Why exactly do we insist on having the API user to make this conversion? 

I'd like to see "price" added to the fields returned with list_limit_orders and other orderbook calls.  It is annoying not having, and required some mental gymnastics to figure out a clean consistent way to derive the price in all cases.  I don't think anyone looking to utilize the API should have to go through that.

missing cancel_order .  You can't make a market if you can't cancel your orders.  Its kind of important.

missing list_my_open_orders.  also important

I understand its probably early and everyone is busy with more important things. No problem there.  Just bringing it up.

I must say I agree with you here, working with prices and market orders in general is a real pain, especially when you start working with feeds and flipped markets.

I also seem to remember us having this issue of inconsistent types in 1.0 and thought it would be different here, but there are inconsistencies all over the place, sometimes it's a string, sometimes its a number. JavaScript is lenient though so most of the time it works out OK there..

[Xeldal]

Anybody have a link to Bitshares 2.0 api documentation?

There may be other resources but this is what I've been using.
http://docs.bitshares.eu/api/index.html

[AdamBLevine]

Anybody have a link to Bitshares 2.0 api documentation?

[Thom]

One of my roles in my distant past history was integration specialist for a military project.

These are not very positive reports, and counter what others have said about how clean the graphene code is compared with the 1.x codebase. It is a reflection of the lack of engineering methodology Charles Hodskinson has spoken of and others have observed like myself.

Graphene is still a very young infant, and before it gets to toddler age I hope CNX will recognize the need for a better engineering process and address concerns of consistency, documentation and ease of understanding. These are obstacles that also interfere with the level of respect this project has in the crypto community.

It may be time to slow down and deal with this now rather than bringing Plasma into view. IMO that was a mistake to even bring that up in a mumble session. It divides attention and shifts focus away from the crucial concerns before us right now. On the other hand I am not alone in my expression of the need for a roadmap, and it's only natural that the items on the distant fringe will trigger our natural curiosity about the future. Though I think it is not so good to deal with Plasma at this time at least BM cut off the discussion and didn't let it go too far. As he said it was a teaser but I don't think is helpful now.

As critical as I am of CNX and gang, I still believe this is a great project with a team of forward thinking innovators at the development helm. I applaud the team's desire to step out of the way and allow the community to take the reigns of control and target the moon, and let CNX be the booster that gets us there. I'm beginning to see the early stages of leadership begin to coalesce, but it is too early to tell if it will congeal into the visionary leadership required to get past the Van Alan Radiation Belt, or if the radiation will kill the crew leaving the ship to drift in space. 

[monsterer]

It seems BitShares API is 3 to 4 times more difficult to integrate then anything else I've dealt with.  Why is that?

 

Most difficult coin API I've had to integrate with metaexchange so far

[Xeldal]

It seems BitShares API is 3 to 4 times more difficult to integrate then anything else I've dealt with.  Why is that?
I hope this doesn't come off too overly critical, I'm happy to work through the difficulty and really only want a better experience others looking to integrate.
I'm not the most skilled or experience programmer, so I may either be mistaken or not understand the reason some things are done, so keep that in mind.  Thanks

I made a post about inconsistent "amount" fields sometimes being strings and sometimes integers
https://bitsharestalk.org/index.php/topic,19566.0.html

Why is this?  can we not keep it one type?

I'd like to see amounts in a consistent type.  So I don't need to catch so many random cases of it being different.

I'd like to see, anytime an Amount is given that it be accompanied by its precision or already adjusted based on precision so I don't have to make 2 or 3 extra calls just to make the conversion.  Why exactly do we insist on having the API user to make this conversion? 

I'd like to see "price" added to the fields returned with list_limit_orders and other orderbook calls.  It is annoying not having, and required some mental gymnastics to figure out a clean consistent way to derive the price in all cases.  I don't think anyone looking to utilize the API should have to go through that.

missing cancel_order .  You can't make a market if you can't cancel your orders.  Its kind of important.

missing list_my_open_orders.  also important

I understand its probably early and everyone is busy with more important things. No problem there.  Just bringing it up.