grpc/protobuf JSON support

[Gesly George]

Hi,

Once the JSON support for protobuf is available, are you guys considering adding the capability to choose between sending JSON or binary protobuf as the payload?
What happens once its possible to use grpc in the browser? Will the server side send JSON across or will grpc clients translate protobuf to JSON?
And what do you guys do internally when you want the data from a grpc server in JSON format - use something like a reverse proxy to serve JSON (like the the grpc-gateway implementation) or some other approach?

I've seen various discussions here and on the protobuf group but did not see a concrete answer. Perhaps, there is isn't one yet.

https://groups.google.com/d/msg/protobuf/ZRpcfmeGK6s/9TrQtwaWGWAJ

Regards,
Gesly

[Eric Anderson]

On Mon, Aug 10, 2015 at 8:53 AM, Gesly George <gesly....@gmail.com> wrote:

Once the JSON support for protobuf is available, are you guys considering adding the capability to choose between sending JSON or binary protobuf as the payload?

We're still undecided on the details. Using protobuf as much as possible is convenient and has advantages. If we did allow JSON we would need protobuf<->JSON support in each language (which will happen anyway, but there is a question of timelines) or to use a proxy. Using JSON on the browser is convenient, and JSON+proxy wouldn't be a bad solution. But all-in-all, not yet decided.

What happens once its possible to use grpc in the browser?

The browser story is still being figured out. We're trying to figure it out for both short-term (use existing browser functionality) and long-term (via Fetch API, hopefully with trailer support).

The gRPC protocol can certainly support JSON, but our libraries would need some more plumbing in order to choose which decoder to use. Or we would need a proxy-based solution.

Will the server side send JSON across or will grpc clients translate protobuf to JSON?
And what do you guys do internally when you want the data from a grpc server in JSON format - use something like a reverse proxy to serve JSON (like the the grpc-gateway implementation) or some other approach?

We've used an approach similar to grpc-gateway with great success. grpc-gateway is great for using gRPC while still supporting third-party clients, who may not (yet :-) ) be on the gRPC bandwagon and would just prefer REST.

I've seen various discussions here and on the protobuf group but did not see a concrete answer. Perhaps, there is isn't one yet.

https://groups.google.com/d/msg/protobuf/ZRpcfmeGK6s/9TrQtwaWGWAJ

Yeah, there isn't one yet, although you can probably see which type of solution we are leaning toward.

[Gesly George]

Are you considering open sourcing the internal proxy implementation given that you have a published the spec for it?

[Eric Anderson]

On Mon, Aug 10, 2015 at 11:48 PM, Gesly George <gesly....@gmail.com> wrote:

Are you considering open sourcing the internal proxy implementation given that you have a published the spec for it?

Considering, yes, but that is a very low bar. I don't have anything to share. If it happens, we'd share more.

Even without open sourcing it, publishing the options allows compatibility between proxy implementations and provides options that are more mature. That seemed like an obvious win, especially given the relative ease in sharing them.

We were really excited about grpc-gateway because we knew that you could provide nice REST interfaces on top of gRPC, but couldn't really communicate that story to others, because it didn't really exist yet.

[michal.w....@gmail.com]

Gesly, in terms of the proxy implementation, you may find https://github.com/gengo/grpc-gateway useful. It uses Google API annotations to auto-generate a REST to gRPC reverse proxy in Go. It's relatively easy to use and actively developed.

[m...@williamthurston.com]

Hello,
  I have a bit of an interest in digging into this sort of work and wasn't certain if posting here, or opening a github issue was the proper approach?  Long story short, I think it'd be interesting to have MethodDescriptor take a mapping of string to Marshaller<ReqT> and string to Marshaller<ResT> that would be matched against the string behind the + for Content-type when receiving a request.  As far as I can tell, at the moment, the Content-type of application/grpc+proto is only parsed for the prefix, but the elements behind the + go unused.  If instead I could provide a marshaller that could handle "proto" (the default now), but also "proto-json" for the json representation of a proto definition that would be great and allow me to have a single server and definition provide the appropriate responses as requested by the caller.  Is this of interest to the project?

Thanks,
William