RFC: Tracing routerify
applications
#74
Replies: 1 comment
-
Hello @lucacasonato, thanks for opening this discussion! Adding tracing to Routerify would certainly be a welcome addition, and the two proposals you've listed are a great starting point for this topic. Proposal 1 seems to introduce breaking changes with regards to how middleware is configured in Routerify, which will warrant a bumping the major version for this breaking change. There's no active discussion around releasing 3.0, but hierarchical middleware is a good motivation to do so. The second proposal does not require any breaking API changes and could be released as a new minor version and released sooner, however it is certainly much less flexible and seems to require Routerify-users to re-implement their own solutions to tracing based on whatever the |
Beta Was this translation helpful? Give feedback.
-
Tracing is an essential feature for modern distributed systems. It allows you to create trace propagation of data through a complex application, or set of applications. In Rust
tracing
in combination withopen_telemetry
is the most obvious way to do this. Tracing works by creating a span, and then attaching some unit of work to that span. Once the span is dropped, it is considered over and is ready to be collected and sent to the server. You can create one scope from within an another, linking them together with a parent-child relation.Routerify makes using
tracing
rather difficult, because middlewares and route handlers are not hierarchical, but instead "siblings" of each other. Pre middlewares, handlers, and post middlewares are called in series, not from each other. For the use case of tracing, you need a middleware type that is not serial, but hierarchical. The two possible solutions I have come up are listed below:Hierarchical middleware
The first and most obvious solution would be to make
routerify
middlewares hierarchical, and thus remove the concept of pre and post middlewares. All middlewares would have a signature like described below, where the user receives aRequest
, and anext
function that they can call at any time to invoke the next middleware / route handler. This next parameter could either be a generic, or aBox<dyn FnOnce>
.Pros:
Cons:
Box<dyn FnOnce>
"Trace handler"
A different, more specialised, solution would be to add the concept of a
trace_handler
. This would have the following signature, very similar to the hierarchical middleware solution above.The difference here is that there would be a single trace handler for the entire router. The
handler
function this trace handler is given would represent the entire "inner" section of the router, so pre middleware, post middleware, route handler, and error handler.The trace handler would thus wrap the entirety of the request handling process in
routerify
.Pros:
Cons:
Beta Was this translation helpful? Give feedback.
All reactions