RE: Is Custom JSON the Future of Steem? | The one thing that has been going up on Steem in the bear market!

You are viewing a single comment's thread from:

Is Custom JSON the Future of Steem? | The one thing that has been going up on Steem in the bear market!

in hive-167922 •  5 years ago 

I don't understand the problem with indexing. Why couldn't you store transaction id and block num into the application database and retrieve them fast? This is the way how taverngames works

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I believe because the indexing is not decentralized. If you ever lose "the application database", you need to replay blocks since the application genesis to recover the index.

That in itself wouldn't be that bad. At least you have a recovery process. It should also be possible to checkpoint the database to a backup periodically and then you only have to replay since the checkpoint.

This is far more ideal.

I don't see a problem here. Why would I lose application database?

Yeah, I don't see the problem either. You got to be very sloppy to lose the entire database especially without backup checkpoints.

It happens or what is more likely to happen is corruption where you have to rebuild from source.

Yes. @smooth has right. This is what I had on mine mind. You can always restore the backup.

Yes, if your app broadcasts the op, on your server, that’s a solution. But if a user broadcasts it from their browser, it starts to get tricky. Does your app then send the block number to you? Did they even use your app? Or did they use SteemConnect/Steem Keychain? Did they use a third party app that doesn’t know it needs to report the block number to you?

In a sense, the blockchain is the method of communication, so it’s redundant to also use another protocol to report the block number. Ideally, you just monitor the blockchain for new data or just some other indexing strategy, not both.

Users use my app and steemconnect as well. When they broadcast the transaction they get the transaction id and block num, then they send it to app endpoints.
Users don't use a third party apps.

If you said it's redundant to use also another protocol and blockchain is the method of communication why do you need SteemSQL then? It is also redundant.

Btw storing the data in the app application makes you independent, you don't need to count on someone's app like SteemSQL (what if they will disable it?)
You do the indexing on your side. I don't see there any disadvantages.

Also you don't need to stream all transactions from the blockchain only those that you really need.

If you accept requests where your users report block numbers, you’re bypassing the need to index independently, which is a great solution. If your app is designed to only accept requests this way, you’re golden.

The problem with this method is if you miss a block number being reported from your users, you need some strategy to find the stragglers. Whatever process you use, assuming it isn’t a manual process, why don’t you always use that strategy instead?

Also you don't need to stream all transactions from the blockchain only those that you really need.

Well, technically, if you’re streaming the blockchain, you are getting all transactions. You’re ignoring most of them, but that’s at least 500 MB of bandwidth, daily, last I checked.

Streaming works. But you need a strategy for knowing what the last processes block number was, so you can ensure you didn’t miss a block if your stream is interrupted.

By the way, if you have several apps all streaming independently, you should consider:

https://github.com/inertia186/meeseeker

Yes you are right.
Btw my app works in two way. Sometimes accept the requests from users (during gaming) but I also need to stream the blockchain (for shop purchases, yes they are not tracked as you mentioned because steemconnect doesn't return with the trx id and block num).

I have the complex solution for streaming blocks, which also detects missed blocks based on previous block, also It retries to preprocess the block when some block is not yet available through the API.

I can agree that all the things depends on the application specification.

I'll take a look at this github repo! Thanks :)

I also invite you to checkout how it works in the https://taverngames.io :)

  ·  5 years ago (edited)

What happens if the user's client crashes in between the time they broadcast the transaction and the time they send the id and block number to the app?

What happens if there is a chain reorg and the transaction ends up in a different block?

For custom jsons it doesn't matter, user doesn't lose his STEEM only some RC amount so it can be retried.

I've never noticed the chain reorg during custom json processing. I've processed many of transactions and no issues reported.

Transfer transactions are streamed from blockchain in the background process. So I never lose them.

Come and checkout : https://taverngames.io

I've never noticed the chain reorg during custom json processing

Chain reorgs on Steem are usually rare, and usually only one or two blocks (so resolved within seconds), so you may not see them much. But sometimes they do still happen and sometimes take much longer to resolve, so you need some strategy for handling it.

If your app expects the user to retry or accept lost transactions occasionally, that may be a perfectly acceptable strategy.

If your app expects the user to retry or accept lost transactions occasionally, that may be a perfectly acceptable strategy.

Yes it is. Everything works as expected.