Hi folks,
I'm on my fourth day of GunDB exploration and while reading the docs and various other tutorials, there's one thing that's uncertain at this point: Storage & whether or not I need a Superpeer?
The tutorials and demos I've seen so far either instantiate gun without peers or with heroku peers such as gun = Gun( [https://gun-us.herokuapp.com/gun, https://foobar.herokuapp.com/gun ] )
.
I reckon the latter is good if you want to demo a chat or todo app where you'd like to demonstrate real-time behavior including p2p syncing of peoples webbrowsers with the help of those superpeers. I understand that concept, it's great, I love it.
However, since I'm about to migrate my Sapper (Svelte) app off of Firebase firestore (because the nature of a graph dataset suits my app a lot better than a hierarchy of colletions and documents) where I already have about 9 GB of data and the fact that firestore is always online for clients to sync with, my big big questionmark at this point is, how do I build the equivalent with GunDB where I have
I've read about AXE, I've read about RAD and the fact that it's the default storage algorithm with a GunDB node deployment, I've seen there's an optional AWS S3 storage adapter, and I've of course also read about the (planned but not yet ready?) IPFS storage option.
All in all, I'm now completely lost and confused about how to continue at this point with regards to storage and superpeer options available.
localStorage. In browser, GUN app data is stored in the browser's localStorage, but is primarily treated as cache.
GunDB is the Open Source Firebase alternative, a web3 data protocol. How it works. (1) Sync directly between your devices & friends. (2) Reclaim ownership and control of your data. (3) Experience a web that is truly free and open.
GUN is an open-source decentralized database service that allows developers to build fast peer-to-peer applications that will work, even when their users are offline.
GUN. js is a real-time, decentralized, offline first, graph database. Sure is a mouthful. Knowing a little bit about decentralized architecture we can understand the other features. Under the hood, GUN allows for data synchronization to happen seamlessly between all connected nodes by default.
# In Production Apps
We've seen up to 30M monthly active users use GUN across HackerNoon, Internet Archive, NotABug, and some large ecommerce & alternative video platforms that I cannot mention yet.
A decentralized app is not "deployed" in the traditional sense. A dApp is "deployed" by even loading it from your harddrive, or a static website, or a traditional "server" if you opt for one (don't!).
A great example of this is that in the last step of the 5min interactive coding tutorial ( https://gun.eco/docs/Todo-Dapp ) you "deploy" your app by loading it in CodePen/other and sharing that URL with your mom and friends.
# Storage
All peers (browsers, nodejs, phones) store data by default.
Sadly, some are more or less reliable.
A native phone app might store data reliably, but may not be "online" for others to access it.
Browser may store data in localStorage, but that might get deleted at any point in time.
So yes, a dedicated "peer" that is always online and has large & reliable storage capacity will always be beneficial to have as a backup.
There is no need for this to be a centralized server though. You can run many machines and peer with all of them. I know people who even connect their desktop directly to the internet to get a dedicated IPv6 address and use that.
# If I use a Cloud Peer How Do I set it Up?
This is insanely simple, and in the main README, just "1-click deploy" to Heroku/Zeit or Docker to other clouds:
https://github.com/amark/gun#deploy
These are not just demo peers! They've handled thousands users per second. They're the ones I've used for some of the large in-production apps.
Of course there still may be hiccups or bugs, but we're continually improving it.
The goal of GUN is to be truly simple. Without need for super complex configuration that is different from local testing versus in-production deployment. They're all peers, they're all the same!
The last and final note, is that depending on where you deploy a cloud peer, you may or may not have persistent storage. So the only annoying configuration you might have to do is hook up to S3 or any compatible alternative (Open Stack, GC, Azure, Sia, etc.), check out this:
https://gun.eco/docs/Using-Amazon-S3-for-Storage
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With