stephenh/ts-proto

Generate google.api.http-based clients

moecasts opened this issue · 5 comments

https://cloud.google.com/endpoints/docs/grpc/transcoding

is possible to generate a http client from a proto like:

syntax = "proto3";

package api.hellp;

service GreeterService {
  rpc Hello(HelloRequest) returns (HelloReply) {
    option (google.api.http) = {
      post: "/hello/{name}",
      body: "*",
    };
  };
}

message HelloRequest {
  string name = 1;
  string sentence = 2;
}

message HelloReply {}

Expect ouput like:

export class HelloServiceClientImpl {
  constructor(http = fetch) {
    this.http = http;
  }

  hello(request: HelloRequest) => {
    const localVarPath = `/v1/dentities/{id}`
    const url = localVarPath.replace('{id}', request.id);

    return this.http({
      url,
      method: 'post',
      data: request,
    })
  }
}

Hi @moecasts , no, I don't think that's possible today... We can generate clients for Twirp, Grpc, Nice rpc, and NestJS, but it looks like you're using the google.api.http extensions, which we don't have any special processing for.

If you'd be interesting in submitting a PR for this support, that'd be great!

You could probably crib from the existing client impls to get going. As a disclaimer I've seen the google.api.http annotations are a thing, but don't really know much about them otherwise.

I also have this issue. Spent some hours trying to use the generated code by "ts-proto", from protobufs which all use "google.api.http".
Maybe add into your documentation what protobuf extensions/packages or whatever they are called, are supported.
In the end people just want to transpile protos into ts and start sending their requests. Having to know what protobuf extensions are is a bit much, but that is just my humble opinion.

@erba fwiw I agree the google.api.http extensions are confusing, which frankly is kind of par-of-the-course for the whole protobuf/gRPC ecosystem. 🤷

Personally I've not used them, which is why ts-proto doesn't support them; I'll add a disclaimer to the readme.

Happy to have anyone that wants/needs this submit a PR.

I have some extensions for timestamp here, could add the other packages like http as well: https://github.com/aperturerobotics/ts-proto-common-types

@stephenh Thanks for that. Sorry for the curt tone of the last message. In the end this is not your fault. It seems expecting to use protobuf just like an openapi spec - i.e transpiling it and starting using client code right away - is not realistic.
Protobuf seems to be more complex and needs understanding even from the client code users, which is a pity.