aep-dev/aepc

aepc

Generates AEP-compliant RPCs from proto messages. See the main README.md for usage.

Purpose

aepc is designed to primarily work off of a resource model: rather than having individual RPCs / methods on a resource, the user declares resources that live under a service. The common operations against a resource (Create, Read, Update, List, and Delete) are generatable based on the desired control plane standard, such as the AEP standard or custom resource definitions for the Kubernetes Resource Model.

Design

aepc works off of an internal "hub" representation of a resource, while each of the consumers and producers is a "spoke", using the resource information for generation of service, clients, or documentation:

flowchart LR
    hub("unified service and resource hub")
    protoResources("proto messages")
    proto("protobuf")
    crd("Custom Resource Definitions (K8S)")
    http("HTTP REST APIs")
    protoResources --> hub
    hub  --> proto
    hub  --> http
    hub  --> crd

Loading

User Guide

go run main.go -i ./example/bookstore/bookstore.yaml -o ./example/bookstore/bookstore.yaml.output.proto

aepc's Issues

support for implicit / virtual resource?

Context: https://github.com/aep-dev/aepc/pull/1/files#r1332008974

There are resources that are more or less containers of other resources, rather than have any behavior in it's own right.

The question is: should these be expressed in the resource model via some specific property?

Should APIs be versioned, or just resources?

Just making a note to remember to revisit a live discussion that didn't wrap up.

support for singletons

we need to resolve whether singletons is an acceptable pattern for a resource, or is an implicit behavior that doesn't need to be explicitly stated in the resource definition (i.e. implemented server-side).

singletons are described in google.aip.dev today: https://google.aip.dev/156, with some patterns that help identify it.

author example illustrating why collection names not correlating to types is problematic.

author example of extracting resource IDs from paths.

lightweight client use case: extracting IDs from resources.

look at bufbuild/protoyaml-go

protoyaml-go may be a better choice for deserialization of Yaml, and possibly enable serialization of expanded resource definitions: https://github.com/bufbuild/protoyaml-go