2015-08-26 MuBackend
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-p2p
handles peer connections,socket.io
is also used for fallbackexpress
is used for http-requests, withexpress-http-proxy
being used for connection to databases. Other http-requests are forwarded to peers that are logged in as daemon, throughsocket.io
.CouchDB
handless sync of client databases, and is also accessible as a database service for the clients.- For database REST APIs, both
CouchDB
andelasticsearch
is supplied. Both are proxied, andelasticsearch
is only available for peers logged in as daemon. The authentication is handled incouchdb
, 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.