I just found out about gunDB and the concept seems very interesting and I'd like to find out more about it before starting to evaluate it further.
- If I wanted to build a chat app like the tutorial but implement chat rooms. Would there be a way for clients to only "subscribe" to certain chat rooms only, and avoid transferring the content of every other chat room? How does that affect persistence, if not all data is sync'd to all clients? Do we need to run a special client (ie a server?) that will make sure all data is kept alive at all times?
- For that same chat room tutorial, if I want to subscribe to multiple chat rooms, would I need to instantiate multiple Gun instances, with each one using "peer" storage?
- How should user management/passwords/etc be dealt with in gunDB?
Sending every client a copy of the user DB is interesting from a
replication stand point, but from a security aspect, it seems counter
intuitive.
- Is there a way to ask gun to only sync under certain circumstances such as when a WiFi connection is available (think Cordova)?
- What about data that's temporal? Is there a way in the chat app, for
instance to tell gunDB that I'm only interested in future messages
and ignore anything that was created prior to a certain
state/timestamp (again to avoid transferring huge amounts of data on
an expensive data plan)?
- How do you persist to disk (potentially circular) data in a gunDB and
load the data back in the DB should the need arise?
- Can you ask gun to monitor two keys simultaneously? For example if a client needs to display chat data and todo list (both 'keys' from the tutorial) assuming both are 'peered'.
- Is there a tutorial for how to use my own server for storage?
Chat rooms. So in the same way the chat tutorial loaded the chat "table", you can just have a "rooms" table. Then you can grab only the room you want. Because gun uses partials to be fast, it will only wind up loading the data you subscribe to. Yes, clients can store only a sub-set of the data as a whole - however that of course might effect your replication/persistence levels. If you are worried about this then running a "strong" peer (like a server) is an easy and perfect solution, since it will then back up everything. (And unfortunately, because WebRTC has problems* to it, you kinda have to run a relay server peer anyways. So might as well use it for storage as well).
Multiple Instances. You do not need to instantiate multiple gun instances per key. In fact, this is bad. It is better if you do not. It is possible, however we haven't tested this as much as we should since it isn't ideal.
Security/authorization is a very very touchy subject so this depends wildly on how you want to build your app. If you are going for a true P2P/decentralized design then you'd need to do end to end public/private key cryptography and signatures. Such that other users can't actually read the data even though they might be helping with backing up the data. However if you want to keep things simple and build your app like most apps are built... as a centralized service, then you'd proxy writes to your server. This is the same technique most people use currently while building apps, and GUN can do the same thing.
WiFi/Rate-limiting data. That is unfortunately not available in JavaScript directly, however it sounds like hybrid apps like you mentioned with PhoneGap can get access to that information. GUN is designed to work in scenarios like this since it is offline-first. But how you interface with external APIs that give you those conditions... is outside my experience, but doable.
Temporal data / limiting data transfer. See my above response first, doable but dependent upon external APIs. In terms of limiting queries though, yes. A: We're introducing 'lexical cursors' soon that will allow clients to constrain responses, however we'll probably be rolling out each of its constraints features incrementally (as it hasn't been a huge priority to the community, but your participation will escalate it!), first with exact property matches (think like a SQL select statement - in fact, it is what we'll be using to create a SQL query extension for gun!), then second a lexical range (select properties starting with 'a' through 'c') which could be done with timestamp ranges, then third a byte constraint (of like only send back at most 200bytes at a time).
However, an obvious thing you can do yourself manually (not that you want to), you could just have a table of rooms, and then the room is a table of chunks, and chunks are a table of messages. Potentially with the room also having a "last" chunk, then you could easily access your chat app by doing gun.get('rooms').path('mychatroom').path('last').map().val(function(message){ console.log(message); }); or something like that. This would allow you to control exactly the conditions you'd want, but also means you have to do a bit more work.
Circular references. Done for you already, have as many circular references as you want - this is where gun excels because of its graph structure (circular refs, tables, documents, key/value, whatever).
Yes, gun can monitor multiple keys simultaneously.
Using your own server for storage... that could mean a couple different things.
How to run your own gun server? There is an easy wrapper for that: https://www.npmjs.com/package/gun-server . If you want examples with Express and stuff those are simple as well.
How to use your current deployed server's file system as storage because you don't want to use S3? You can use the level driver https://github.com/PsychoLlama/gun-level .
Did that answer?
*WebRTC requires STUN/ICE/signaling servers to bootstrap the WebRTC connection. Which is super annoying. This means that even though WebRTC is P2P, in order to get connected you have to go through some server and this has to happy for every page load. Because of this, we by default bundle gun with websockets/JSONP that it has to connect to a gun relay server peer (there are also so community gun relay peers that people can use for personal experiments, but it is easy to run your own as in Point4). As a result, we haven't released a WebRTC adapter yet, despite the fact that WebRTC + gun is a perfect fit - stupid STUN/ICE/signaling servers.
