Could .pkl files be used for JSON API contracts across languages, similar to .proto files for gRPC APIs?

[ae33]

Could it further be possible that .pkl files be used to generate structs that could serialize to protobufs (if that were added as an output)? For example, the following in Go:

type Foo struct {
    A int `protobuf:"varint,1,opt,name=a,proto3" json:"a"`
}

It seems as though a .pkl file could theoretically be used to generate the above (if they added support for protobufs). The only other thing .proto files have that .pkl doesn't is a "service" definition, which defines function signatures, thus enabling it to generate a client that makes requests and receives responses using the defined structs ("messages" in .proto speak). Even if .pkl files were never to expand to include an equivalent of a "service", I'd still take the shared request/response struct generation across languages for non-gRPC APIs, or for services that read messages from a queue (etc.).

tl;dr -- Could .pkl files become a broader abstraction to .proto files, expanding its reach beyond gRPC services? That seems exciting to me. I know they say they are a "configuration" language, but the API contract possibilities are what first popped into my head.

[bioball]

I don't know if I would suggest using Pkl to generate target language structs for gRPC or protobuf, because protobuf's codegen might cover intricacies that Pkl doesn't know about. I think for many of their bindings, they also generate code for deserialization.

Also: Pkl ins't a great fit for defining the message data that should be passed around between services, because adding a whole language runtime will slow down message passing by quite a bit. I think if I were defining gRPC, I'd stick to using .proto files, and use the structs that they generate for you.

However, you can certainly use Pkl as a way to generate .proto files, or use it to generate OpenAPI. In fact, you can already turn a Pkl class into an OpenAPI schema.

[ae33]

Oh, duh, OpenAPI!