A description of the differences between Firebase (the good, original DB that got acquired, indicated by ) and Firestore (the rebuilt one that is not as good as the original, represented as ).
I think we can take a lot of tips from this on how to design a database / database interfaces in the webnative SDK / on top of WNFS.
The main flaw in is that the client was created a few years too soon, before you could reasonably expect most web developers to know what immutability was. As a result, assumes you are mutating your data, and will not benefit from any immutability you feed it. It will also not reuse data in the snapshots it gives you, making diffs much harder. For larger documents, its mutable-diff based transactional mechanism is just inadequate. C’mon guys, we have WeakMap in JavaScript now. It’s cool.
If you give your data the right shape, and keep your trees shallow, you can work around this. But I do wonder whether wouldn’t get a whole lot more interesting to people if they just released a really good client API based on leveraging immutability, coupled with serious practical advice on schema design. Instead it’s like they tried to fix what wasn’t broken, and made it worse.
Yay for immutability and maybe people understanding it a bit more now
“One big JSON document”, along with the built in ability of IPFS to call into JSON key / values is a pretty good starting point.
Better still you have a programmable global giant graph as commons to connect all those json fragments. You just given away the secret sauce in MindGraphs recipe
) and Firestore (the rebuilt one that is not as good as the original, represented as 
).