gRPC in Production
Another downside in gRPC is that (de)serialization can be relatively slow. One of my pet projects is a tagging server that takes a list of tags and returns a list of objects that match, retrieved from RocksDB. I tested gRPC (proto and FlatBuffers) and Cap&#x27;n&#x27;Proto. For all of them, the process looked like:<p>Insert: Object comes in (built in RPC system for both), object is assigned ID (which is added before serialization), object is written to RocksDB, object is serialized and indexed.<p>Query: List of strings come in, strings are looked up in tag index, intersection of results is done, objects are retrieved from RocksDB, objects are deserialized, objects are added to list, objects are returned to client.<p>FlatBuffers was unfortunately a no-go since it doesn&#x27;t permit modification of fields that haven&#x27;t yet been set and it didn&#x27;t have a sane way of making a copy (which would also be slow).<p>Protocol Buffers worked but the pure Python driver is incredibly slow and the C++ driver for Python was non-default and marked &quot;experimental&quot;. I eventually adapted to it but it was still quite slow even on the server side. From memory a response with C++ client and server took ~9ms, 4-5ms of which were spent on serialization&#x2F;deserialization.<p>Cap&#x27;n&#x27;Proto eventually won for me. The Python driver is unstable and memory usage soars like an eagle until Linux shoots it down with an OOM but the server was much faster. Typical response times were closer to 3ms, most of which was spent in RocksDB or the actual index lookup. A downside though was that Cap&#x27;n&#x27;Proto has its own built in and odd library for async stuff and doesn&#x27;t really support threading.