Repository navigation
Consider exposing OpenTracing-compatible gRPC API #125
Description
I haven't run very far with this idea, so this is just a thought dump for now. But I've been considering how Appdash could reach the most languages.. it stands to reason that we would gather support for a large number of languages by exposing a gRPC service which would literally be the OpenTracing API itself.
Then, from a user's perspective, they could either directly use this gRPC client from their language of choice OR we could even implement opentracing-python, opentracing-java, etc by simply calling out to this gRPC service.
This is interesting, because it could give many other tracers that do not wish to spend a significant amount of time implementing tracing clients in various languages automatic support if they were to expose the same OpenTracing-compatible gRPC service. This could also be done over, e.g. HTTP or others, I just chose gRPC because I am most familiar with it.
Activity
bhs commentedon May 7, 2016
@slimsag c.f. go-kit/kit#247
asilversempirical commentedon Dec 22, 2016
One thing to watch out for: https://github.com/sourcegraph/appdash/blob/master/internal/wire/collector.proto is a proto2 proto, and it's incompatible with proto3 without some changes. Namely: support for group fields was removed: https://github.com/google/protobuf/releases/tag/v3.0.0
This isn't a huge deal, except that there's no python3 support for proto2, only proto3. So doing this over gRPC exclusively doesn't open up python3 support.