Using proto generated class in Java class vs defining individual fields separately in Java class

[jainlavina]

I am building a Java thick client library for a gRPC service and wondering whether tha Java request class that this library exposes to the users should inlcude the proto generated class directly vs individually define the request fields separately in the Java class.

For example given
message gRPCUserRequest {
// request fields
}

Should I define Java request class as:
class UserRequest {
gRPCUserRequest request;
}

vs

class UserRequest {
// request fields
}

Is there a downside to exposing proto generate class directly to the users in the client library?

[ejona86]

It's sort of up to you, but essentially it is two questions, 1) is the proto request message part of the library API and 2) is protobuf part of your API. So for (1), it's a bit of a question "does a v2 protobuf API require a v2 library API." The more your library does, the more likely you could hide major version changes of your protocol. So very thin clients often expose the messages, but the more processing you do in the library, the more you should consider hiding your dependencies. If in doubt, hiding the protobuf message types is probably the side to err on, but it really does depend on what you're doing.