As I read about what is new and hot in JS, I came across https://risingstars.js.org/2019/en . Here I found gun. And with that I got a followup to my last post. Gun is a system/framework for building distributed apps. Apps that can work, hosted by the community, and can run without the need from your side, to run all the expensive servers.
The heard of GUN is a graph database module, that will sync data between devices. The device can be a server node or peer as they call the servers or a client, what can be PWA, electron or any other client side app, desktop or mobile.
As database module the GUN team developed RAD, a radix tree database that can store to nodejs fs, indexDB, or local storage.
The GUN servers are often called ‘relay’ servers, as they can help clients to communicate together, via webRTC or web-sockets through the server. The relay server is broadcasting database updates. When I read about the relay servers, I was instantly thinking back, to a proof of concept I developed back in 2015.
GUN also has encryption based authentication. It uses SEA (Security, Encryption, & Authorization). A library, that can generate a keypair, sign, verify, encrypt and decrypt. I wonder where I have seen that before,… trsa.
It is not important what technologies you are using to build your own dapp using the components provided at gun.eco, any of my suggestions or come up with your own solution.
When companies build web applications, they usually plan to keep control over the data, when developing distributed apps the developer give up that control, but not only the control, but also responsibilities (not an advice about law, ask a lawyer for implications). But I think I found a neat use case:
Mobile games. I enjoy a round of farm valley now and then or trainstration, fishdom, sea port or alike. Mainly long time running economy clicker games. For such games, the data security is not the most important, and If a player what to cheat himself, so he who cares? These games often limit the player interaction to a minimum, of sending some items or ‘hugs and kisses’ around, with very limited effect on the game itself. You can see the progress of your friends, that is pretty much it.
I think that a building the such games as a distributed app, can greatly reduce any server cost, and by that make the operation of the game much cheaper, what could allow for more interactivity, while having low cost.
I would also think of building hybrid apps, setting up a bunch of relay servers, and other servers to manage the application. Relay servers could just provide the realtime data exchange for playing rounds, such as in Data or leak of legends, where account and progress is actually stored and secured on the companies server.
GUN in implementing a graph database. I would like you to consider using pouchDB and in the server couchDB. Using PouchDB you could setup many small databases in a single server and expose them to the client to sync data around. The synchronization mechanism uses long-polling, what can provide you a way to have real-time interactivity. Using pouch or CouchDB, even servers can sync each other. With all the conflict resolution that couchDB provides.
Instead of sea, I would recommend you with trsa, it has basically the same API, is compatible with other RSA libraries and provide an easy way to have authentication not he server.
Is the current situation even all that bad? When I want to setup a website, I got lots of choices, ranging from services, over agencies, self service host. And and and. There is lots of services that let you book linux servers and you can install any service, chat, databases, email, web service, what ever you like. Lots of software is available for free and even open source. You can adjust existing software for your needs or pay someone to do so.
I believe, once we face a situation, where some huge provider will let us down, we will have a good standing getting alternatives up and running very quickly.