Skip to main content

Ent + gRPC is Ready for Usage

ยท 3 min read

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โ€‹

For more Ent news and updates: