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 fallback
  • express is used for http-requests, with express-http-proxy being used for connection to databases. Other http-requests are forwarded to peers that are logged in as daemon, through socket.io.
  • CouchDB handless sync of client databases, and is also accessible as a database service for the clients.
  • For database REST APIs, both CouchDB and elasticsearch is supplied. Both are proxied, and elasticsearch is 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.