add `get_tornado_instance` as an experimental API

[link89]

add `get_tornado_instance` as an experimental API

[link89]

@sfc-gh-jcarroll I believe you are working on some awesome solutions to solve those problems eventually , but the problem is when. I don't think I am lucky enough that some 2019 issues will be resolved in the next few weeks.

Thus I guess provide an experimental API as a transitional solution should not be bad. I think it's nothing to worry about the Tornado compatibility issue, once you have custom HTTP endpoint implemented it won't be hard for app developers to migrate to the new one and deprecate the broken feature.

I believe it will be good to provide some low level APIs so that a developer can use them to solve issues when there is no better way to choose. It's all up to you to decide anyway,

[sfc-gh-jcarroll]

Thanks @link89

It's unlikely that we'll directly support using the Tornado instance since we've intentionally avoided exposing Tornado internals since early Streamlit. We're also beginning to look at moving Streamlit to an ASGI framework in the not too distant future (you heard it here first! 😉) so that would break any Tornado compatibility.

We're actively working right now on auth use cases similar to the one you described, see #8518

We're also doing some planning and design on custom HTTP endpoints similar to what you described in a more general way, along the lines of what I described here.

In general today, most developers use the undocumented-but-supported headers API for similar use cases. We will likely add a fully-documented-and-supported version of that in the near future.

I'm sure it's not quite the answer you hoped for, but that's the current state and we are definitely putting more energy in this direction than we have historically.

[github-actions]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.

[vdonato]

@kajarenc @sfc-gh-jcarroll FYI -- we may want to consider doing something like this (or accepting #8662, potentially making some changes to it to export it from any new namespace we may add) as part of the auth/headers projects.