Skip to content
This repository has been archived by the owner on Sep 13, 2022. It is now read-only.

Usage in a browser #109

Closed
pavolloffay opened this issue Apr 13, 2017 · 18 comments
Closed

Usage in a browser #109

pavolloffay opened this issue Apr 13, 2017 · 18 comments

Comments

@pavolloffay
Copy link
Member

pavolloffay commented Apr 13, 2017

Hello,

I have a question, can this library be used in a web browser?

-- update Jan 24 2020 --
jaegertracing/jaeger-client-javascript#1

@yurishkuro
Copy link
Member

yurishkuro commented Apr 13, 2017

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.

@pavolloffay
Copy link
Member Author

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).

@yurishkuro
Copy link
Member

The collectors currently expose TChannel-thrift ports only.

https://github.com/uber/jaeger/blob/master/cmd/collector/main.go#L70

@pavolloffay
Copy link
Member Author

pavolloffay commented Apr 21, 2017

@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.

@yurishkuro
Copy link
Member

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.

https://github.com/uber/jaeger-client-javascript

@pavolloffay
Copy link
Member Author

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 core, tchannel-reporter, rest-reporter...

@tiffon
Copy link
Member

tiffon commented Sep 2, 2017

I highly recommend lerna, it's very handy and intended for exactly this type of situation.

Some examples of it in action:

@pavolloffay
Copy link
Member Author

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?

@yurishkuro
Copy link
Member

I suppose, but it would pull additional dependencies into the browser.

@tiffon
Copy link
Member

tiffon commented Nov 9, 2017

I did a quick check on the exported file size of browser-thrift.

Minified, it's about 151kb, 42kb after gzip.

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 69kb, 20kb after gzip.

Looks like we might be able to remove bluebird (if it's not actually being used) or replace it with the native Promise, which is pretty well supporterd.

@MarckK
Copy link
Contributor

MarckK commented Nov 9, 2017

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:

  1. lerna is a great choice
  2. the alle pattern
  3. Formidable Lab's Builder

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.

@yurishkuro
Copy link
Member

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

@felixfbecker
Copy link

So is the plan to bake in JSON support into the Jaeger backend or to provide a backend proxy that converts the JSON?

@yurishkuro
Copy link
Member

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).

@MarckK
Copy link
Contributor

MarckK commented Feb 23, 2018

Well, this might be left-field (and very green), but:
gRPC-Web seems very interesting
It's still being developed and is subject to change.
However, Improbable have built and are using in production something similar.
They have open sourced their gRPC-web.

@felixfbecker
Copy link

felixfbecker commented Jan 24, 2020

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? 😔

@yurishkuro
Copy link
Member

There was some work started in jaegertracing/jaeger-client-javascript#1, but stalled. Using OpenTelemetry-js might be a better option at this point.

@silvairsoares
Copy link

silvairsoares commented Jan 29, 2021

While we have no news on this subject, I continue using the architecture below. Unfortunately, with the burden of duplicating http calls (Angular Frontend => BFF .Net => API Gateway instead of Angular Frontend => API Gateway), in order to maintain end-to-end traceability.

Angular Opentracing

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants