doc/website/blog/2021-06-28-gprc-ready-for-use.md
A few months ago, we announced the experimental support for generating gRPC services from Ent Schema definitions. The implementation was not complete yet but we wanted to get it out the door for the community to experiment with and provide us with feedback.
Today, after much feedback from the community, we are happy to announce that the Ent + gRPC integration is "Ready for Usage", this means all of the basic features are complete and we anticipate that most Ent applications can utilize this integration.
What have we added since our initial announcement?
Support for "Optional Fields" - A common issue with Protobufs
is that the way that nil values are represented: a zero-valued primitive field isn't encoded into the binary
representation. This means that applications cannot distinguish between zero and not-set for primitive fields.
To support this, the Protobuf project supports some
"Well-Known-Types"
called "wrapper types" that wrap the primitive value with a struct. This wasn't previously supported
but now when entproto generates a Protobuf message definition, it uses these wrapper types to represent
"Optional" ent fields:
// Code generated by entproto. DO NOT EDIT.
syntax = "proto3";
package entpb;
import "google/protobuf/wrappers.proto";
message User {
int32 id = 1;
string name = 2;
string email_address = 3;
google.protobuf.StringValue alias = 4;
}
Multi-edge support - when we released the initial version of
protoc-gen-entgrpc, we only supported generating gRPC service implementations for "Unique" edges
(i.e reference at most one entity). Since a recent version,
the plugin supports the generation of gRPC methods to read and write entities with O2M and M2M relationships.
Partial responses - By default, edge information
is not returned by the Get method of the service. This is done deliberately because the amount of entities related
to an entity is unbound.
To allow the caller of to specify whether or not to return the edge information or not, the generated service adheres
to Google AIP-157 (Partial Responses). In short, the Get<T>Request message
includes an enum named View, this enum allows the caller to control whether or not this information should be retrieved from the database or not.
message GetUserRequest {
int32 id = 1;
View view = 2;
enum View {
VIEW_UNSPECIFIED = 0;
BASIC = 1;
WITH_EDGE_IDS = 2;
}
}
:::note For more Ent news and updates:
:::