And the main cost of this (questionable IMO) benefit is losing consistency, which is losing any change to DB not coming from the calling app. You haven't mentioned this cost anywhere.
The writes are not tunneled somehow through this algorithm. You still use the database like your normally would do. So the consistency is not affected.
Also this is an open source project, not something I want to sell you. Feel free to make a PR/issue with any open topics that are not mentioned in the docs.
OK, so you don't "tunnel writes through" EventReduce, you "tee" them to EventReduce.
Anyway, to maintain consistency, you have to limit yourself to one process of your app. No sharding, load-balancing etc. This is significant limitation, and it's not obvious. I encourage you to mention it in README.md.
I encourage you to read the readme and check out the demo.
EventReduce is nothing magically drills out your database and affects the consistency of your write-accesses.
It is a simple algorithm that is implemented as a function with two inputs and one output.
> For the different implementations in common browser databases, we can observe an up to 12 times faster displaying of new query results after a write occurred.
Is this intended to be an optimisation on top of localStorage and so on? If so, at least you don't have to worry about multiple writers.
Also this is an open source project, not something I want to sell you. Feel free to make a PR/issue with any open topics that are not mentioned in the docs.