Interesting, I like where this is going. Just a few thoughts:
- use blockchainmode (latest/irreversible) as parameter
- for dApps it's important that blocks aren't skipped. How do you make sure that this doesn't happen? And where is the current processed block-number saved? (How am I getting it back as user of the package?)
- when I used streaming with dsteem it was somewhat unstable - having the option to use something like STEEMSQL would be interesting. (I've written some code for that in node-js recently, so if you need some help with it, let me know)
- there will be apps that are using
required_auths- this needs to be included as well.
Yes, this is still in the earlier stages as development. Using blockchainmode as a parameter is something that should be coming out this week.
You can get the current processed block number by using
processor.getCurrentBlockNumber(), yes that is very important to the package. There is a documentation which contains items like this on the github (plus, this is also mentioned in the token tutorial I posted alongside this announcement). I’m not sure howsteem-statewould react to when a witness skips signing a block— when this occurs, the block number is not skipped, correct? (If I’m right, thensteem-statewill have no trouble with skipped blocks).STEEMSQL seems like a good idea, I’ll look into it.
Yes — I will look into that. Currently, the name of the user who ‘created’ a transaction is simply derived from
required_auths[0], so usingrequired_authsis currently untested and is not likely to work (I don’t have much knowledge in those DApps, if you could enlighten me that would be great). That will definitely be something I will add in the future.Thanks for reading this article and providing feedback @therealwolf! I’ll get to work building the next versions and including some of your suggestions! Currently this is the MVP and has a lot more features to come (I mean, the package is only 150 lines of code).
been streaming services data for a year, no instabilities.