The concept of a nobackend-backend is that it should:
- Facilitate connections between peers
- Forward http-requests to peers
- Enable sync of databases to peers
- Authenticate and give direct access to database rest apis
I call this a mubackend, as it is a backend that is not doing anything, ie. just forwarding everything. (mu is both 無 and μ). This takes 69 lines of codes, and I have implemented this with the following technologies:
socket.io-p2phandles peer connections,
socket.iois also used for fallback
expressis used for http-requests, with
express-http-proxybeing used for connection to databases. Other http-requests are forwarded to peers that are logged in as daemon, through
CouchDBhandless sync of client databases, and is also accessible as a database service for the clients.
- For database REST APIs, both
elasticsearchis supplied. Both are proxied, and
elasticsearchis only available for peers logged in as daemon. The authentication is handled in
couchdb, and the mubackend.
This allows a programming model with no distinction between servers and clients, except that servers would usually run headless, and log in with a user with special database privileges.
The mubackend should be scalable. The weakest components for scalability are
- socket.io, – which could later be replaced by more optimised code if scalability issues arise
- CouchDB, – which could late be replaced by CouchBase if scalability issues arise.
I choose to socket.io/CouchDB as it this is the easiest path, and it would require more work to have some optimised sockets+couchbase. They should also be reasonable scaleable. The mubackend can scale and be load-balanced, if the socket.io code inside of it moves it state to a distributed database.