Some people asked why this release is so important:
- It fixes several critical bugs that happened during the performance rewrite. Example: If a server crashed and had its data wiped, there wound up being some sync issues. But this release fixes those.
- First time for us to hit 2K table inserts/second synced end-to-end across a federated (browser <-> server <-> server <-> browser) network topology. This load test was running on low end hardware, so expect better results on better hardware.
- These tests are now available for anyone to run, using our distributed testing framework called PANIC, which simulates failure cases (inspired by Aphyr's Jepsen.io tests). Code and docs for it at https://github.com/gundb/panic-server .
- - The test that was added in this release simulates what happens to GUN in a split brain network partition during a server loss. We expect the data to converge once the network heals (it previously was not, but now does). The PANIC test for this is here: https://github.com/amark/gun/blob/master/test/panic/holy-gra... (Warning: not commented, please see the previous test to understand what is going on)
Happy to answer any other questions. For anybody using GUN, this is one of the most important releases and upgrading is strongly recommended.
What are some appropriate real production use-cases for this? Particularly since you can't trust the user to tell you the 'real' state of a resource, the REST model is to send discrete state changes to resources and having an explicit endpoint to validate that the change is allowed (and logical).
- And we're chatting with a bunch of companies doing some really cool stuff: robotic manufacturing, ethereum/blockchain 'lightning network' state channels, realtime decision engine / predictive fraud detection, federated home servers / DNS on top of gun, multiplayer VR, and more.
You should NOT use gun for any globally/strongly consistent data, like bank account balances and such.
Ever since we introduced our Security, Encryption, Authorization framework, people are starting to build more user facing apps, like P2P crypto social networks, and collaborative tools.
Which leads to.... if you cryptographically sign the data, you can trust that the user's copy of the data! It is very untraditional, but that is what we are trying to push/encourage. We even produced an entire animated explainer series, 1 minute each, to explain the concepts: http://gun.js.org/explainers/data/security.html !
REST is a very good model, I actually designed gun around the best parts of it - GET and PATCH (although for simplicity it is just called PUT). Graphs are a stateless representation of the data, which when statefully connected (via WebSockets or something), allow us to efficiently transfer only the delta/diffs and maintain sync. While you can run a traditional server with gun as an endpoint for validation, it is actually possible to do validation client side (as long as all clients are running the same rules) as well.
Autonomous IoT data is exactly opposite of needing global consistency. I can't say what it is, but this system isn't even hooked up to the internet. It needs immediate local and autonomous decisions made, part of why they chose gun.
@jimktrains2 it is nearly impossible to lose data with gun because of its master-master replication even into the edge/peers. It is about as fault tolerant as you can get (check out the links to the tests I mention in the other comments).
I understand now how it might have sounded confusing, sorry about that! Mission critical systems often require HA, not master-slave. Master-slave is very important in other use cases.
- It fixes several critical bugs that happened during the performance rewrite. Example: If a server crashed and had its data wiped, there wound up being some sync issues. But this release fixes those.
- First time for us to hit 2K table inserts/second synced end-to-end across a federated (browser <-> server <-> server <-> browser) network topology. This load test was running on low end hardware, so expect better results on better hardware.
- These tests are now available for anyone to run, using our distributed testing framework called PANIC, which simulates failure cases (inspired by Aphyr's Jepsen.io tests). Code and docs for it at https://github.com/gundb/panic-server .
- - If you want to run (or write your own) please read through this well-commented 300LOC test: https://github.com/amark/gun/blob/master/test/panic/load.js .
- - The test that was added in this release simulates what happens to GUN in a split brain network partition during a server loss. We expect the data to converge once the network heals (it previously was not, but now does). The PANIC test for this is here: https://github.com/amark/gun/blob/master/test/panic/holy-gra... (Warning: not commented, please see the previous test to understand what is going on)
Happy to answer any other questions. For anybody using GUN, this is one of the most important releases and upgrading is strongly recommended.