One could also probably front FDB with a gRPC service that exposed something similar to the functions in our C API (probably using gRPC streams to correspond to transaction “sessions”, with the first operation in the stream also beginning the transaction, and a stream closure aborting any uncommitted work). Then this could be fronted with a standard load balancer and connected to in all of the “standard” ways with URLs/VIPs. (One could even add authentication at this layer and/or restrict operations to certain key ranges based on the authenticated user.)
In my mind, the gRPC servers use the existing C API (either though
libfdb_c if implemented as a separate service, say, or through the
NativeAPI directly if they are just other processes in the cluster) to handle all communication with the existing set of processes, but then they use gRPC to talk to clients. (Between Flatbuffers or Protobuf as the interchange format for gRPC I have no opinion.)
If one is willing to do some amount of work on the client side, one could probably take our existing bindings and make an API compatible thing that talked to this gRPC service instead of directly to the (current) FDB processes. This is getting somewhat in the weeds, but one problem I’ve often come across when thinking about this problem is what to do about the “set” operation, which the bindings assume are non-blocking. I think for that, one could (in the client) create a “client request queue”, and operations like
set would simply enqueue a request, and operations like
get, which demand RYW, would wait for all outstanding set operations to complete.
But before one embarked on this project, I think it would be important to have a clear idea why. (Your scientists were so preoccupied with whether or not they could, they never stopped to think about whether or not they should!) The most tangible benefit (IMO) would be that now as clients are using a protocol with a backwards compatibility story, client and server versions are no longer intertwined (ideally with tests to prove it). The other benefit would be that you no longer need to distribute a random C library, but can instead rely on the gRPC client libraries for most languages (which actually wraps a C library for some languages and reimplements everything for other languages), and connecting to a cluster looks a lot more like connecting to other services, which might be advantageous. The cost is an extra network hop, and also the complexity of getting client/server interactions right and monitoring these extra processes or the extra service. But this approach, unlike the ones outlined above, doesn’t require changing FDB’s server-to-server protocol (or requiring it to be backwards compatible), and it doesn’t require a rewrite of RYW or the other complex things the client currently does.
So, I don’t know. I’m somewhat ambivalent about this idea, as there are probably complexities I haven’t thought of. But I think something like it could be made to work.