Came for the beer, stayed for the Freedom

So the startup I work for uses Mongo. I have my own opinions of Mongo,
some good, some bad. I have a decent amount of experience with the wire
protocol. I've written an asynchronous C driver[1] for GObject, rewritten a
python-twisted driver[2], and my own BSON implementation. We wrote ourselves
a "schema" verifier for Mongo that works offline against the Mongo
disk format using my C driver. Needless to say, we have a lot of investment
in Mongo and therefore this impacts my design decisions.

One thing that I do like about Mongo is the simplicity in the scaling
design. The implementation is somewhat annoying (all the different types
of daemons and configurations), but the design itself seems "good enough".
You communicate to each Mongo instance as if it were a real data store,
and it handles communicating with various shards or physical data access.
It is the "turtles all the way down" approach. Lovely. When a system fails,
you have information about the replica-set and can connect to another node
to continue operation.

This simplicity in this design means slightly more complexity in the
client libraries, at the benefit of simplifying the server implementation.
Debugging this process can also be much simpler because you can reuse
your debugging tools at each link in the system.

So, in short, I like this design and would like to use it for internal
services used to build our platform. Wouldn't it be nice if our services
were exported in the same fashion? It would allow for a more seamless
upgrade of internal services with little downtime. It would also allow
for code to be separated more readily and tested individually. When you
have issues with memory fragmentation or leaking in python it is contained
to the particular service and much easier to debug (as compared to a
monolithic app server). This has nothing to do with the choice of exporting
the command via Mongo, but just a side-effect of moving to this design.

So, in my fork of txmongo (a Mongo driver for twisted), I have implemented
a way to implement both clients as well as Mongo servers. You can export
RPCs as Mongo commands. This means you can use the Mongo command line client
to test things. You can implement how you want failover to work yourself.
You can use official Mongo drivers to write your RPC clients. Getting to
build on their work for handling failover, reconnection, and what not.
Standing on the shoulders of giants.

So lets take a look at how this might look in Twisted. We will start by
writing a service that we will eventually export as a Mongo server.

    from twisted.application import service
    class EchoService(service.Service):
        def do_ping(self, **kwargs):
            return {'pong': kwargs}
 

Now lets create a TCP listener that will listen and proxy commands to the
above service.

    import bson
    from twisted.internet import defer
    from twisted.python import failure
    from txmongo.protocol import MongoProtocol, Reply, REPLY_QUERY_FAILURE
    from pymongo.errors import OperationFailure
    import types
 
    class ServiceProtocol(MongoProtocol):
        def __init__(self, service):
            MongoProtocol.__init__(self)
            self.service = service
 
        def handle_QUERY(self, request):
            if request.collection.endswith('.$cmd'):
                query = request.query.decode(as_class=dict)
                if '$query' in query:
                    query = query['$query']
                # first key is the name of the command
                name = 'do_' + query.iterkeys().next().lower()
                func = getattr(self.service, name, None)
                if not func:
                    # needed for pymongo to connect
                    if name == 'do_ismaster':
                        func = lambda *a, **kw: {'ismaster': True, 'ok': 1}
                if callable(func):
                    df = defer.maybeDeferred(func, **query)
                    df.addCallback(self._queryCb, request.request_id)
                    df.addErrback(self._queryEb, request.request_id)
                    return
 
            ex = OperationFailure('No such command: ' + name)
            self._queryEb(failure.Failure(ex), request.request_id)
 
        def _queryCb(self, result, request_id):
            if not isinstance(result, types.ListType):
                result = [result]
            result = [b if isinstance(b, bson.BSON) else bson.BSON.encode(b)
                      for b in result]
            reply = Reply(response_to=request_id, documents=result)
            return self.send(reply)
 
        def _queryEb(self, reason, request_id):
            doc = {'$err': str(reason.value), 'ok': 0}
            if hasattr(reason.value, 'code'):
                doc['code'] = reason.value.code
            ret = [bson.BSON.encode(doc)]
            reply = Reply(response_to=request_id, documents=ret,
                          response_flags=REPLY_QUERY_FAILURE)
            return self.send(reply)

Now the simple part, lets wire up a TCP listener using twisted to accept
Mongo connections and bridge the service.

    from twisted.internet import protocol, reactor
 
    service = EchoService()
    factory = protocol.Factory()
    factory.protocol = lambda: ServiceProtocol(service)
    reactor.listenTCP(27017, factory)
    reactor.run()

So now we can go ahead and use the Mongo command line interface to communicate
with this service. Lets do that and execute our new ping command.

$ mongo
> db.runCommand({ping: 1, hello: 'world'})
{ "pong" : { "ping" : 1, "hello" : "world" } }

We can do the same thing using the pymongo driver from Python.

>>> import pymongo
>>> pymongo.Connection().test['$cmd'].find_one({"ping": 1, "hello": "world"})
{u'pong': {u'ping': 1, u'hello': u'world'}}

I haven't decided whether or not I want to move forward with designing services
in this manner, but I do think it is interesting and warrants more exploration
and experimentation. I really like the ability to compartmentalize my various
internal services and the power that gives me in testing, monitoring, and
application lifecycle.

I haven't made this easy to do with my C driver yet, but I do plan on adding
the functionality soon.

As always, patches welcomed!

[1] https://github.com/chergert/mongo-glib
[2] https://github.com/chergert/mongo-async-python-driver