3 ms·

For a good RPC abstraction, I think a key requirement is to easily and safely change the deployment separation between modules that use the abstraction – deploy

For a good RPC abstraction, I think a key requirement is to easily and safely change the deployment separation between modules that use the abstraction – deployment separations being: in-proc, inter-process-communication and remote-procedure-call. That is, 1. deploy the modules within the same process then the method invocation is most efficient; 2. deploy the module across separate OS processes on the same machine then the method invocation is via the best available OS IPC mechanism; 3. deploy the module across separate machines then the method invocation is over network with most efficient remote procedure call implementation. A long time ago I worked on a project that used Corba (with ACE TAO) that had facilities like this and it made development, testing environments vs various production environment permutations a lot easier to build for and manage over multiple product lifecycles. Now-a-days, these Microservices frameworks are missing these (basic) features and it overly complicates the deployment scenarios. Rather than hand-rolling 300 line custom RPC mechanisms like this one, I would rather prefer a more complete one that did solve the above problems.

EdSchouten 7y ago
Even though I think Go's GRPC implementation is pretty good, this is something that really annoys me about the way it's designed. The interface of a GRPC client is not the same as the interface of a GRPC server. This means that: - You cannot instantiate a piece of code built on top of a GRPC client directly on top of another piece of code that implements a GRPC service. You will need to create a full GRPC client and server. Don't want to let them communicate over an OS-level socket? You'll have to use something like https://godoc.org/google.golang.org/grpc/test/bufconn https://godoc.org/google.golang.org/grpc/test/bufconn to create an in-memory socket. - You cannot let a GRPC server process forward requests to a GRPC client directly. Quite annoying in case you want to multiplex requests, add an authenticating proxy, etc. etc. - Unit testing a GRPC service is annoying, as the service implementation has to take some concrete GRPC types that can only be instantiated by a GRPC server. This means that you also have to create a full GRPC client/server/bufconn to be able to test it.

EdSchouten 7y ago

Even though I think Go's GRPC implementation is pretty good, this is something that really annoys me about the way it's designed. The interface of a GRPC client is not the same as the interface of a GRPC server. This means that: - You cannot instantiate a piece of code built on top of a GRPC client directly on top of another piece of code that implements a GRPC service. You will need to create a full GRPC client and server. Don't want to let them communicate over an OS-level socket? You'll have to use something like https://godoc.org/google.golang.org/grpc/test/bufconn https://godoc.org/google.golang.org/grpc/test/bufconn to create an in-memory socket. - You cannot let a GRPC server process forward requests to a GRPC client directly. Quite annoying in case you want to multiplex requests, add an authenticating proxy, etc. etc. - Unit testing a GRPC service is annoying, as the service implementation has to take some concrete GRPC types that can only be instantiated by a GRPC server. This means that you also have to create a full GRPC client/server/bufconn to be able to test it.