[Middleware] Adds routing metadata (if any) to middleware execution flow.

[philliphoff]

If the Glimpse Agents includes routing metadata (route paths, HTTP method, and/or parameter values) when publishing middleware messages, the Client will now display it within the middleware flow of the Execution tab.

Also switches from using text to symbols for middleware results (i.e. next, end, and error) as it feels a little more streamlined and easier to read at a glance.

[avanderhoorn]

Wow looks great!!! Are we able to match the "tokens" back to the values that they matched on?

[avanderhoorn]

Damm... sorry I didn't see that it had matched... was looking at a small screen.

[avanderhoorn]

At the moment we have the "Route" section under the middleware section... as we know these will be integrated together at some point, but at the point where we are generating the messages to populate "Route" do we know how the tokens are matched?

[philliphoff]

The current UI is probably not the best way (or even a great way) to display the matching of tokens to their values in the route path, but that will require some designer help to sort out; the goal was to ensure that the raw data was displayed in a reasonable way.

[philliphoff]

The route path will contain the tokens (e.g. :id), which will correspond to a id property, so we should have enough information to present a "fused" UI for the route path. It gets more complicated if the middleware is attached to multiple routes, each with their own set of (possibly overlapping) tokens. That would probably be unusual in practice, but it might complicate identifying which route, in particular, was taken.

[avanderhoorn]

At the moment, do you have to manually parse these out like what you have described we would have to do for "Route" or because of our middleware implementation we have extra information available?

From a middleware perspective I think this is gtg :shipit:. Just need to make sure you get the compiled agent into the node server.

[philliphoff]

The route path is just a simple string with the embedded token(s), so we'd need to do some parsing to fuse them together. But we're handed the bag of token/value pairs to that shouldn't be too difficult.

[avanderhoorn]

Ok so just to be clear... where we are generating the route messages for the "Route" section, we have that bag of token/value pairs just the same way we currently do when we generate MW messages that have route data?

[philliphoff]

Express attaches the token/value pairs to the request (for the duration that it operates under the corresponding route), so that's available. What's not necessarily available at that point is the relative path to which the route was attached (because Express allows the same router/route to be attached to several different paths, so that information is only available at registration time).

I'm not totally sure about that, though. The "Route" section is a remnant of the original prototype which attempted to map Node.js to the existing ASP.NET concepts of route/action/view and is completely separate from any middleware work that I've been doing, and I've not really touched it since the prototype. I've been under the assumption that that section will just "disappear" at some point as the new timeline view is developed, in favor of showing a more sequential, middleware-based execution timeline.

[avanderhoorn]

Thanks for the info! We are in the process of working out what goes onto what screen and I'm just trying to get a sense of what we can get when. I was trying to ascertain whether we could get the data outside of the middleware processing logic you have been writing or whether it was only available at that time. Thanks!