Go SDK Roadmap

[smeubank]

Go SDK roadmap v1.0.0

Better performance API

• Add concrete Transaction/Span types
  This will allow us to better distinguish between transactions and spans, allowing for stricter typing and only exposing the proper attributes and functions for each type.

• Add TransactionContext & SpanContext
  The Go SDK lacks abstractions for the context, making it weird to compose transaction/span options. This will also make distributed tracing more robust, as we can properly propagate the parent context during transaction/span creation.

• Add getters/setters for all exposed Transaction/Span attributes
  This will allow us to make breaking changes to the core data structures more easily.

• Remove StartSpan not needed
  This method will be entirely replaced by StartTransaction and follows the unified API.

• Remove SpanOptions
  Replaced TransactionContext/SpanContext

• Move Transaction name to the Transaction context
  Currently, the transaction name is set on the scope, making it cumbersome to work with it in concurrent environments.

Move all integrations into their own submodules

The sentry-otel module will be the first attempt to solve this issue, leading the way for other integrations to follow.

Performance tracing out of the box

We currently only offer performance tracing for net/http and should expand this to all integrations by default.

Add gRPC integration

available in OTel

gRPC is widely used in Go, so the SDK should ship with a default integration.

Add Fiber support

Fiber is one of Go's biggest frameworks, so the SDK ship with a default integration.

(Stretch goal) Add Buffalo support

A framework that is closer to other languages' frameworks like Ruby on Rails or Laravel.

(Stretch goal) Add support for more logging libraries

TBD

SDK usage in Go routines

The current APIs exposed are insufficient and hard to understand when working with Go routines. We should make it easier to clone and set the Hub/Scope on the context when using Go routines.

go func(ctx *conext.Context) {
	// Explicitly set a new Hub on the context
	sentry.SetHubOnContext(sentry.GetHubFromContext(ctx).Clone())
	...
	hub := sentry.GetHubFromContext(ctx)
}

go func() {
	// Replaces sentry.GetCurrentHub()
	hub := sentry.GetGlobalHub().Clone()
}

Investigate: SDK configuration via functional options

With the current approach (passing ClientOptions to sentry.Init), we can't always say if the configuration option was passed or not (e.g., Golang will initialize all boolean flags to false, if they're not set to true in ClientOptions). Functional options (resource1, resource2) is a pattern that is sometimes used to handle cases like this.

• We can first start using it for integration to change the behavior of Repanic which is false by default.
• EnableTracing flag might not be necessary if we do this.

Misc

• The current transport fails in high throughput environments. We may utilize more than one buffered channel.
• Remove the usage of the store endpoint, as it is considered deprecated. We'll use the envelope endpoint exclusively.
• Rename captureExcpetion to captureError
• Do not swallow panics in integrations by default.
• Do not get the release by calling git, as this has unwanted side effects on client-installed binaries.
• (TBD) better stack traces, in-app frame detection, source fragments, ...
• (TBD) captureMethods() should not return an EventID
• Improve examples and overall documentation

---

Road to Performance and OTEL

• No start_transaction only start_span - ideal minimum for OTEL span processing
• OTEL support in sentry
  • there are some missing data points that do not translate from OTEL to Sentry in the product
  • there are missing support/integrations in our Go SDK, which OTEL does provide support for already
  • gRPC - we are totally out of the loop - while it is OOTB with OTEL
  • Go & OTEL are much more natively compatible
  • OTEL Errors? Can be done but Sentry
  • Phase 2 or 3 for example is consolidating logic where we might need to amend OTEL data to suit the Sentry

Performance feature Parity

• auto-instrumentation
  • at least standard library for HTTP
  • txn gets completed and keeps context
  • middleware for HTTP
  • auto instrumentation can be quite complex and tightly coupled with releases of Go
  • we may need to move towards auto-instrumentation but it won't be the same as other platforms
  • offer transports per HTTP client and DB integrations, so that a span is started per event
  • How much of this is required? Considering we could go straight to processing spans from OTEL
    • differs from other SDKs, is that OK?
    • All APIs would still be available

Misc:

• Open PRs
• Dependencies and submodules
  • submodules are difficult in Go - tried to replicate in Go similar to other platforms
  • however the main lock file has dependencies on all Gin's dependencies
  • Security scanner flare up, makes versioning complex
  • in Go 1.19 has ability to fix this
  • to move to this we will break some older versions where we have many users
    • compatibility promise - app will always compile with new versions
    • 1.16 is the lowest possible
    • OTEL promises compatibility for every major version
    • https://github.com/golang/go/wiki/Modules

[smeubank]

@tonyo & @cleptric converting this to an issue on meta repo, did either of you have a chance to check this if there's any big points to add for Go 1.0

some of these checklist items are done or in progress of done already if memory serves correct

[smeubank]

Short list of short term investments:

• source context [research]
• proper transaction concept [there are tickets]
• catch up with Go ecosystem
  • exception groups for example
  • needs more definition