Consider using route information instead of URL for Starlette transactions

We’re slowly started using Starlette for some smaller applications due to its simplicity and async capabilities. We also happen to use Elastic APM for our monitoring, but we’ve found that the agent works quite different from other agents, such as Django or Flask.

The default for Django, is “HTTP Method + path.to.view”. This can be changed for Django 2.2+ using the django-transaction-name-from-route setting, to instead use the route that was matched against. For example GET /users/<int:user_id>/.

For Flask, the default seems to be the that of method + route, e.g.: GET /users/<int:user_id/.

For Starlette however, information about the matched route is not actually available on the request, and for that reason (I assume), the full URL is instead used as the transaction name. In the example above, it would mean that every time a user with a different URL was hit, it would generate two separate transaction entries. For some of our views, that would mean 1+ milllion transaction names for the same view.

However, it is somewhat possible to extract the route by mimicking what Starlette itself does. On the request, the Application itself is available, and from that route router + routes. This means it’s possible to loop over them, and match their regular expression against the current request.

1. I realise this isn’t pretty in any way, shape or form - but it would make instrumentation of Starlette applications a lot more useable
2. I also realise it’s backwards incompatible - but perhaps this could be solved in the same way that it’s done with Django?

What would your thought be on such a change?

For us at our workplace, we’ve actually have one major of our main applications ported to Starlette, but once we saw what was happening to the transaction names, we had to revert the deployment. We’d love to have it running, so we’d probably be interested in providing a patch for it as well.

EDIT Just wanted to add this here, since it’s a discussion of making this type of information available in the middleware system: https://github.com/encode/starlette/issues/685 It also links another repo for timing of ASGI that basically does what I describe here, by looping over all routes and comparing them to the current URL.

[HenrikOssipoff]

@HenrikOssipoff Is this a change you’re still interested in contributing?

Sorry very late to the game - I can see @beniwohli has assigned himself, which is more than fine by me. Work’s not leaving me much free time unfortunately.

Looking forward to the “fix” though - sorry for being slow here.

Personally I would say you shouldn’t think about backwards compatibility for this one, given most likely very few people even use this particular integration, but that’s my opinion alone.

[HenrikOssipoff]

@basepi Definitely, I’ll give it a go in the near future. Would enable us to use Starlette much more than we currently do 😃