-
Notifications
You must be signed in to change notification settings - Fork 131
Usage in a browser #109
Comments
not in the current from. The plan was to pull the core logic from this library into jaeger-client-javascript and leave Node.js specific logic here. In particular, one main change would be to replace UDP sender with an HTTP sender (#170) that can submit the spans directly to the backend, since UDP won't work from the browser. This is on our roadmap for later in the year, not a high priority right now, but as always contributions are welcome. |
Thanks it looks promising 👍. I could take a look at it soon. Is it possible to send spans via TCP to backend at the moment? directly to collector? Could you please point me at code? (I'm still not very familiar with the backend components). |
The collectors currently expose TChannel-thrift ports only. https://github.com/uber/jaeger/blob/master/cmd/collector/main.go#L70 |
@karelhala did some work on this master...karelhala:browser-client. Currently it creates all-in-one distribution which can be loaded by browser. I will proceed but I guess we need REST endpoint on the collector side. |
What I would like to happen is to not duplicate the core tracer implementation, but to extract the shared part and have two shims, one for Node another for the browsers. I believe that's what lightstep did with theirs. We have a repo for that "core" part, and probably the browser shim, while the Node shim can remain in the current Node client repo. |
Agree, as much as possible should be reused. About https://github.com/uber/jaeger-client-javascript, there is this https://lernajs.io/ project for managing multiple packages in one repository. We could have |
I highly recommend lerna, it's very handy and intended for exactly this type of situation. Some examples of it in action:
|
I remember that we have talked about HTTP json endpoint on the server side which requires to define jaeger JSON model. Could we use just thrift with something like this https://www.npmjs.com/package/browser-thrift? |
I suppose, but it would pull additional dependencies into the browser. |
I did a quick check on the exported file size of browser-thrift. Minified, it's about But, most of the size comes from bluebird, which seems to be exported, but not used (not sure why). Removing bluebird reduces the size to Looks like we might be able to remove bluebird (if it's not actually being used) or replace it with the native |
Re lerna: interesting writeup on PouchDB's experience using lerna with a monorepo can be found here, with Henry Zhu of Babel weighing in. There are a few of options for managing monorepos: Happily, breaking out of any of these options isn't hard and it is therefore easy to move from one to another, or change to writing a custom solution. |
20kb still sounds like a lot for functionality that is not absolutely necessary. I still think the browser client should report spans in plain JSON |
So is the plan to bake in JSON support into the Jaeger backend or to provide a backend proxy that converts the JSON? |
The plan is to support JSON on the backend. We already can accept Zipkin v2 JSON, but we haven't decided what Jaeger JSON should look like. Possible options are the Jaeger UI's JSON format, or the serialized format of the domain model (merging those too wouldn't be the worst thing either). |
Well, this might be left-field (and very green), but: |
We are looking to migrate from LightStep to Jaeger at Sourcegraph and I just stumpled across this issue again. Is there any active work or plans on the roadmap for this? 😔 |
There was some work started in jaegertracing/jaeger-client-javascript#1, but stalled. Using OpenTelemetry-js might be a better option at this point. |
Hello,
I have a question, can this library be used in a web browser?
-- update Jan 24 2020 --
jaegertracing/jaeger-client-javascript#1
The text was updated successfully, but these errors were encountered: