Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collab opportunity #29

Open
janstenpickle opened this issue Jul 8, 2022 · 5 comments
Open

Collab opportunity #29

janstenpickle opened this issue Jul 8, 2022 · 5 comments

Comments

@janstenpickle
Copy link

Hey @rossabaker I'm the creator and one of the maintainers of https://github.com/trace4cats/. The core tracing code is native Scala, with translations to various different backends. For the tracing portion of this project I was wondering if there might be an opportunity to share a common kernel? I haven't had a good look through this codebase yet, but my gut feeling is by both trying to do native scala implementations of at least the tracing part, we can share some code. Let me know! 😄

@armanbilge
Copy link
Member

See also discussion in #11 :)

@janstenpickle janstenpickle mentioned this issue Jul 8, 2022
@iRevive
Copy link
Contributor

iRevive commented Jul 29, 2022

Perhaps the project can be more modular.

For example, http4s-metrics can depend only on otel4s-metrics module, since it does not care about tracing. And another lib can depend on otel4s-tracing and ignore metrics.

As of now, I can think of the following structure:

  1. otel4s-base - Attribute, AttributeKey, AttributeType and some shared internals
  2. otel4s-metrics - depends on otel4s-base
  3. otel4s-tracing - depends on otel4s-base
  4. otel4s-core - aggregates otel4s-base, otel4s-metrics, otel4s-tracing

@janstenpickle
Copy link
Author

@iRevive that makes a lot of sense to me!

@rossabaker
Copy link
Member

Sorry for the slow reply. It's been a slow reboot from vacation...

I like @iRevive's module boundaries. OpenTelemetry also includes logging, but it's the least exciting concern vs. existing solutions. That's a distant third, but could sit next to otel4s-metrics and otel4s-tracing in this scheme.

One goal for this project is for its naming to adhere closely to the OpenTelemetry standard. I work in a polyglot shop, and it's helpful to have a shared vocabulary for the core Otel concepts. As far as trace4cats goes, would those otel4s-base types be useful?

I would imagine that trace4cats could target otel4s-tracing, but it's not clear what that would bring over its existing opentelemetry backend, at least until someone is ambitious enough to write a backend that doesn't depend on the JDK. (As a JVM person, I don't have any plans to implement that, but I know the Scala.js people would like it, and I don't want to foreclose the opportunity.)

@janstenpickle
Copy link
Author

Sorry for the slow reply. It's been a slow reboot from vacation...

No problem at all, I hope you had a good time off!

As far as trace4cats goes, would those otel4s-base types be useful?

Yes, I think at very least we should definitely share a base.

I would imagine that trace4cats could target otel4s-tracing, but it's not clear what that would bring over its existing opentelemetry backend, at least until someone is ambitious enough to write a backend that doesn't depend on the JDK

Yeah, that's fair. My main motivation with trace4cats was to eliminate the requirement for a dependency on gRPC, which with all the reflection the Java gRPC library does, was wreaking havok with dependency hell at $work where we also have to depend on Google libraries for working with GCP services. For me this is motiviation enough to create a Scala/JVM cats-effect based otel4s-tracing backend, assuming the pieces fit and would be an interesting exercise in aligning the two projects.

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

No branches or pull requests

4 participants