Consider grpc and grpc-gateway to automate API bridge code

[wfarner]

It looks like grpc-gateway can bridge a grpc service to a REST-like interface, which would allow us to avoid maintaining our existing bridge.

https://github.com/grpc-ecosystem/grpc-gateway

See examples:
https://github.com/philips/grpc-gateway-example
http://www.grpc.io/blog/coreos

[wfarner]

Note: we'll have to make sure that grpc-gateway has support for the google.protobuf.Any type as an analog to our uses of json.RawMessage. If it doesn't support Any, we should consider contributing it as means to an end.

[wfarner]

Unfortunately Any is not yet supported: golang/protobuf#216

[wfarner]

Another consideration is that Any includes a type URL field. golang/protobuf includes this in marshaled JSON, for example

{"an":{"@type":"something.example.com/jsonpb.Simple","oBool":true}}

This convinces me that the JSON output from golang/protobuf rightfully aims to provide compatibility with the protobuf wire format. Since this is not the direction we are currently heading, i'm closing this issue.

[wfarner]

More data worth considering in our strategy here - net/rpc is frozen for future development: golang/go#16844

[chungers]

+1 Thanks for closing this. TBH I don't see a pressing need to go with GRPC especially considering the lack of support for an equivalent of json.RawMessage. Also, JSON-RPC is probably a better choice given that it's easy to implement an API without extra tooling (good for languages not supported by GRPC).