Docs: Project goals

DRPC is supposed to be a replacement for those who are using or wanted to use gRPC but were unsatisfied with how large it is for one reason or another. In order to be a good replacement, the design of the project is guided by some main principles.

Principles

• gRPC API compatibility
• Modularity
• Small

gRPC API compatibility

It should be easy for a program that is using gRPC without some of the more advanced features to trivially migrate to using DRPC. Some compromises can and must be made. For example

• It should be possible to have gRPC and DRPC generated code in the same package, so the DRPC symbols must be namespaced.
• Some gRPC generated code contains interfaces that refer to gRPC symbols (like grpc.CallOption). Can't support that.

Modularity

When adding features, try to make sure they can be, at least in principle, implemented externally. The main drpc package defines only a set of interfaces and common error types. This is so that all of the concrete implementations are as general as possible, and so that if you only need to refer to some drpc types, you don't "get the whole gorilla with the banana".

gRPC is large because it has to be large. By being as modular as possible, we can keep the core small and maintainable, and have the users who need more features or functionality to implement it externally themselves if they wish.

Small

Small can mean many things. For example,

• Avoiding external dependencies
• Little code
• Compiled output is small

All of those things are important to this project.