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
API changes between 0.6 and 0.7, proposal for more improvements #36
Comments
Thanks for your input. I am glad you address these points, as I've struggled with naming for quite a while and never seemed to be able to come up with a truly consistent way of doing things. My goal was to come up with fluent, meaningful method names for common use cases, hence the The with_name / add_prefix in particular was a hard call. I wanted to convey the idea that the namespace gets appended to rather than entirely replaced. Also, the "prefix" is a prefix to the eventual metrics, but the added prefix is itself appended to the existing prefixes actuallyt making it a suffix of the existing namespace. Finally, to be consistent, the with_* convention would have to be used with other properties, such as with_cache, with_buffer, etc. Some structs were not meant to be instantiated directly:
Following the previous points, |
Regarding the |
I have just finished the update to 0.7, our setup method is below. The rest of the code operates with The issues with API that I see from our use case point of view:
|
Also, the cache is only useful if the metrics names are dynamically generated at runtime to prevent any cost of re-creating the metrics of the same name. If using static metrics, either through the |
We use both static-programmatic metrics wherever possible - counters of requests, errors, latency, etc. - and the dynamic ones for e.g. HTTP status codes in responses. We don't use fully static |
Closing this as the new names have been merged. |
I'm trying to update Dipstick dependency to 0.7.1 in our project. There are a lot of great API improvements, but I like some parts of 0.6 more. Migration guide with few items would help a lot during the switch.
Nice
.with_name()
has been renamed to strange.add_prefix()
..with_name()
was clear, it extended an existing name by a new subname. Current.add_prefix()
is quite hard to use. Does it prefix the existing name or adds a suffix? I don't understand this change, it looks like the implementation detail leaked to the API.AppMetrics
was the "core" object of the library in 0.6. It's now calledAtomicBucket
in our use case. What about to add a type alias for it? We are usingMonitor
,Metrics
or something other would be also good.There is no clean "entry point" for the library that is otherwise very good. There are many of them in the examples (listed below), which one should be preferred? It's extremely hard for newcomers. Finding
AtomicBucket
was difficult even for me who was already using 0.6 for some time. I know it's in the example at crates.io but who would expectAtomicBucket
?! What about to introduce a builder or helper struct calledDipstick
and start all library uses with it?Stream::write_to()
AtomicBucket::new()
MultiInputScope::new()
Graphite::send_to()
MultiInput::input()
MultiOutput::output()
Prometheus::send_json_to()
dipstick::Log::log_to().input()
Statsd::send_to()
Stream::to_stderr()
The text was updated successfully, but these errors were encountered: