autometrics-ts: supporting different metrics collection libraries (and exemplars)

[keturiosakys]

Unlike other libraries, autometrics-ts currently only supports one underlying metrics collection library: the official OpenTelemetry metrics SDK.

I'm exploring options how to add support for different underlying metrics collection libraries. The main reasons for this are:

1. Autometrics should work with whatever setup you may already be using to produce metrics;

2. Exemplars support (#57) is currently blocked by the fact that the official OpenTelemetry client doesn't itself have support exemplars. Supporting a more mature Node.js specific prom-client would allow supporting exemplars in the TypeScript library as well.

In the Rust version of Autometrics, the underlying libraries are configured using the --features flag, however, of course no such thing exists in the TS/JS world. There are two main ways I'm currently weighing to enable this interface:

1. Separate autometrics packages for each underlying metrics library. This means: @autometrics/autometrics-open-telemetry , @autometrics/autometrics-prom-client each of which the user would be able to install separately. If the user doesn't care about this and just wants to start with autometrics they can always pick the default package npm i autometrics which would just run OpenTelemetry under the hood.

   • The main advantage: the user can make a choice already when installing the library and not having to worry about further configuration.
   • Pitfalls: maintaining all of the different packages would be quite unwieldy.

2. Set underlying metrics collection libraries at runtime using an environment variable. So in order to run Autometrics with prom-client you would run AUTOMETRICS_ENV=prom-client node server.js. If no environment variable is set, the program would run with the default OpenTelemetry package.

   • The main advantage for this is that the maintenance of the library would (probably) be a lot simpler than maintaining several different packages.
   • Pitfalls: if we bundle all of the libraries, I'm a bit concerned about how much code would actually get shipped to the runtime. Also, forgetting to set an environment variable can be a very easy to make mistake.

Between the two I'm currently firmly on the fence, so I'd love to get community's input before moving with either.

[emschwartz]

I'd put in a vote for separate packages. It doesn't make sense to me to include both dependencies when you're only ever going to use one.

[flenter]

My worry with splitting the packages up into autometrics-{your-flavour-of-underlying-reporter-library} is that it complicates the story for new users. Not all new users will land on our getting stared page of the docs and so will see the more complicated story about which library is used under the hood. Dependencies are typically fairly small so installing one or 2 too many isn't a huge deal typically. Bundle size is something that we should be careful with though on the front-end. But that's an issue we're already facing and splitting things up into separate packages might introduce the issue that for certain solutions like next.js autometrics code itself might be included twice

Come to think of it, if we do want to split things up, maybe it would be good to make it explicit and have an @autometrics/core and an @autometrics/{your-flavor-of-reporter}-exporter package? That way it becomes explicit and we could change the API so that users need to explicitly set/initialize the library with their preferred exporter?

[emschwartz]

What about having @autometrics/core + @autometrics/prometheus-exporter, etc and still having the autometrics package that gives you whatever the default combination is?