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;
}
}
Getting Startedโ
- To help everyone get started with the Ent + gRPC integration, we have published an official Ent + gRPC Tutorial (and a complimentary GitHub repo).
- Do you need help getting started with the integration or have some other question? Join us on Slack or our Discord server.
- Subscribe to our Newsletter
- Follow us on Twitter
- Join us on #ent on the Gophers Slack
- Join us on the Ent Discord Server