衍生信息的惯例是什么?

时间:2018-04-17 04:05:00

标签: protocol-buffers grpc

我正在开发一项服务,提供有关几个相关实体的信息,有点像数据库。假设有人要求检索有关学校的信息:

service MySchool {
    rpc GetClassRoom (ClassRoomRequest) returns (ClassRoom);
    rpc GetStudent (StudentRequest) returns (Student);
}

现在,假设我想找到一个教室的信息,我会收到一个看起来如此的原型:

message ClassRoom {
    string id = 1;
    string address = 2;
    string teacher = 3;
}

有时我也想了解课堂上的所有学生。我正在努力思考哪种设计模式更好。

选项A)添加额外的rpc,如下所示:rpc GetClassRoomStudents (ClassRoomRequest) returns (ClassRoomStudents),其中ClassRoomStudents只有一个字段repeated Student students。这种技术需要多次调用才能获得我们想要的所有信息(如果我们想知道多个教室的信息,则需要很多信息)。

选项B)向repeated Student students原型添加额外的ClassRoom字段,并且B')仅在必要时填写它,或者B“)每当服务器收到{{1}时填写它这可能有时会获取额外信息,或者根据填写的字段导致歧义。

我不确定处理此问题的最佳/最常规方法是什么。你们有些人如何处理这个问题?

1 个答案:

答案 0 :(得分:1)

没有简单的答案。这是简单性(选项A)和性能(选项B)之间的权衡,它取决于解决方案最佳的情况。

一般情况下,我建议首先使用简单的解决方案,除非您的测量表明它会导致性能问题。此时,可以轻松地将repeated Student students添加到ClassRoom,将字段bool fetch_students [default=false]添加到ClassRoomRequest。然后客户可以继续使用简单的API,或者如果需要,可以选择升级到性能更高的API。

请注意,这不是gRPC特有的; REST API中也出现了同样的问题,基本上几乎都是任何请求/响应模型。