#1742 introduces a codegen ontop of the tonic codegen for our gRPC servers.
We should get this across the line, and then being implementing it for each service's methods.
I propose that each method should get its own file within the server's module. This also lets us keep unit tests (if desired) inline/close by.
Once all servers are migrated, we can then make the tonic server traits private, only exposing our server/method traits.
It would also be nice if we could move our server configuration into the proto crate. So maybe something like ServerXX::external (and internal), which would create the proper tower service.
Something I've also thought of, but not solved concretely, is that most of the RPC components methods do very basic verification before sending it on to the store aka a proxy of sorts. It may make sense to create an abstraction there where you define only the verification, and it automatically implements the method. Might also not be worth it.
#1742 introduces a codegen ontop of the tonic codegen for our gRPC servers.
We should get this across the line, and then being implementing it for each service's methods.
I propose that each method should get its own file within the server's module. This also lets us keep unit tests (if desired) inline/close by.
Once all servers are migrated, we can then make the tonic server traits private, only exposing our server/method traits.
It would also be nice if we could move our server configuration into the proto crate. So maybe something like
ServerXX::external(and internal), which would create the proper tower service.Something I've also thought of, but not solved concretely, is that most of the RPC components methods do very basic verification before sending it on to the store aka a proxy of sorts. It may make sense to create an abstraction there where you define only the verification, and it automatically implements the method. Might also not be worth it.