It depends on how you would define "production scale".
If you're talking about hosting a publicly accessible Streamlit app on the internet, it's definitely possible but will require you to set up an appropriate infrastructure around it: sticky load balancer, replication, orchestration, etc.
If you're talking about hosting something for internal use by your company, very often just a simple machine serving your Streamlit app is more than enough.
That said, we're currently working on Streamlit For Teams, which is a paid offering that will make it trivial to deploy Streamlit apps for these use cases. If you're interested, you can sign up here: https://streamlit.io/forteams/
Not at the moment. There are a few reasons for this, but perhaps the most fundamental one is that Streamlit starts a blocking server -- so even if you could run it inside Jupyter it would pause your Jupyter session until you killed Streamlit.
This looks super interesting. I relate to the motivation of building something like this- the endless cycle of creating a Jupyter notebook which becomes a Flask app. I really liked the quick feedback loop for the visual components and the fact that it is all in Python.
I haven't checked yet but a question that comes to mind is how extensible is this framework. I can easily see how I'd want to make custom widgets.
Regarding extensibility, we totally agree: over time, many people are going to want to write their own custom widgets. Which is why we're actually in the early phases of designing a plugin system for Streamlit.
I use Jupyter notebooks all the time for acquiring, cleaning, and exploring datasets. Occasionally these notebooks mutated into tools for more than just one off exploring. It's always felt a little awkward to use them for more day to day data tasks. Steamlit looks amazing for these cases!
I am not sure "rerunning the script from top to bottom" is a necessary condition but for the code layout to reflect the expected behavior.
How would people compare this to Observable [1]?
1. Javascript vs. Python
2. Client-only vs. server-required?
Does the market already give advantage to Python and server-required because the data sets are too large and live on the server, and the users (data scientists) prefer Python and the existing libraries there?
This looks really slick, can't wait to try it out!
If anyone is curious about other tools in the same space, our data scientists use Dash[1] and plotly to build interactive exploration and visualization apps. We set up a Git repo that deploys their apps internally with every merge to master, so they're actually building and updating tools that our operations, marketing, etc teams use every day.
Dash is awesome. I've been using Shiny in R for similar purpose. Do you have any blog post or some more details around the deployment process and your use-case of using Dash?
I gave it a try on Windows and ran into an issue, but found a workaround.
I'm using WinPython 3.6 on Windows 7. I did "pip install streamlit" and then "streamlit hello", and had to allow it through the firewall, then got a 404 page.
The workaround is very simple, just use the provided http address and add "index.html":
requests_cache caches HTML requests into one SQLite database. [1] pandas-datareader can cache external data requests with requests-cache. [2]
dask.cache can do opportunistic caching (of 2GB of data). [3]
How does streamlit compare to jupyter voila dashboards (with widgets and callbacks)? They just launched a new separate github org for the project. [4] There's a gallery of voila dashboard examples. [5]
> Voila serves live Jupyter notebooks including Jupyter interactive widgets.
> Unlike the usual HTML-converted notebooks, each user connecting to the Voila tornado application gets a dedicated Jupyter kernel which can execute the callbacks to changes in Jupyter interactive widgets.
> - By default, voila disallows execute requests from the front-end, preventing execution of arbitrary code.
Acess control and resource exhaustion are challenges with building any {Flask, framework_x,} app [from Jupyter notebooks]. First it's "HTTP Digest authentication should be enough for now"; then it's "let's use SSO and LDAP" (and review every release); then it's "why is it so sloww?". JupyterHub has authentication backends, spawners, and per-user-container/vm resource limits.
> Each user on your JupyterHub gets a slice of memory and CPU to use. There are two ways to specify how much users get to use: resource guarantees and resource limits. [6]
> The reason for having a single instance running voila only is to allow non JupyterHub users to have access to the dashboards. So without going through the Hub auth flow.
> What are the requirements in your case? Voila can be installed in the single user Docker image, so that each user can also use it on their own server (as a server extension for example). [7]
Interesting project, but why does an open source developer tool needs browser telemetry?
You should ask for telemetry permissions _before_ the process starts up (as you do for email address), and keep the default as "No", instead of start to send the data transparently unless non user friendly steps are taken by the user.
I agree on the premise: yes eventually every analysis needs to become an app. Also let me add: no, dashboards are not going to cut it, they don't offer enough interactivity. I also love that the app here is a script and hence can be version controlled with git. However, there is no description anywhere of what happens when you need to scale with this. If you have to go from a couple of testers to 100 internal users like it very often happens in analytics, how does this react?
Also caching is a great idea but I would expect a lot of this logic to be managed on the server side, or I am missing something and ML is different here? I would expect to pipe as little data as possible back to the application because I want the user to wait max 3-4 seconds for the app to load at start.
As far as I can tell the caching is happening server-side. Pretty much all the frontend seems to be doing is poking the back-end to re-run the script (or get results from cache) and then getting back the diff to apply to the UI.
This is pretty neat! As this is an offshoot of some autonomous car project, what would the support be for 3D data. If I wanted to see some LIDAR or Pointcloud data in browser? Esp if its a tf-output.
The demo is broken on Macos:
"Streamlit failed to hash an object of type <class 'code'>.,
More information: to prevent unexpected behavior, Streamlit tries to detect mutations in cached objects so it can alert the user if needed. However, something went wrong while performing this check.
This is awesome! Is there a way to generate a standalone binary, e.g. as an electron app? I'm looking for ways to ship small custom python/pandas data analysis apps including data to non-technical users - but as a local application.
You may want to consider building Streamlit into a standalone binary using Static-X or pex. I use pex for standalone binary distribution of a fairly popular python app [1].
66 comments
[ 3.0 ms ] story [ 142 ms ] threadIt depends on how you would define "production scale".
If you're talking about hosting a publicly accessible Streamlit app on the internet, it's definitely possible but will require you to set up an appropriate infrastructure around it: sticky load balancer, replication, orchestration, etc.
If you're talking about hosting something for internal use by your company, very often just a simple machine serving your Streamlit app is more than enough.
That said, we're currently working on Streamlit For Teams, which is a paid offering that will make it trivial to deploy Streamlit apps for these use cases. If you're interested, you can sign up here: https://streamlit.io/forteams/
(Co-founder of Streamlit here)
(Co-founder of Streamlit here)
I haven't checked yet but a question that comes to mind is how extensible is this framework. I can easily see how I'd want to make custom widgets.
Regarding extensibility, we totally agree: over time, many people are going to want to write their own custom widgets. Which is why we're actually in the early phases of designing a plugin system for Streamlit.
So stay tuned!
How would people compare this to Observable [1]? 1. Javascript vs. Python 2. Client-only vs. server-required?
Does the market already give advantage to Python and server-required because the data sets are too large and live on the server, and the users (data scientists) prefer Python and the existing libraries there?
[1]: https://observablehq.com/
Installing on my Mac to test this out was very straight-forward:
Then I could play with the built-in demos by running: So that was a slick intro - next step was I followed this tutorial: https://streamlit.io/docs/tutorial/create_a_data_explorer_ap...And a few minutes later I had an interactive notebook-style interface for playing with Uber pickup data in New York.
This is a really interesting product.
If anyone is curious about other tools in the same space, our data scientists use Dash[1] and plotly to build interactive exploration and visualization apps. We set up a Git repo that deploys their apps internally with every merge to master, so they're actually building and updating tools that our operations, marketing, etc teams use every day.
[1] https://plot.ly/dash/
I've always looked on Dash as a bit of FOMO myself. If you have experience with Jupyter, could you contrast Dash vs Jupyter?
https://news.ycombinator.com/item?id=21127528 https://news.ycombinator.com/item?id=21126477
I'm using WinPython 3.6 on Windows 7. I did "pip install streamlit" and then "streamlit hello", and had to allow it through the firewall, then got a 404 page.
The workaround is very simple, just use the provided http address and add "index.html":
This link has more info: https://github.com/streamlit/streamlit/issues/244https://bookdown.org/yihui/rmarkdown/shiny-embedded.html
Jupyter -> internal tool/API is pretty much the holy grail of bridging data scientists, business teams and engineering.
I hope this project doesn't die out. A lot of people would pay for this.
requests_cache caches HTML requests into one SQLite database. [1] pandas-datareader can cache external data requests with requests-cache. [2]
dask.cache can do opportunistic caching (of 2GB of data). [3]
How does streamlit compare to jupyter voila dashboards (with widgets and callbacks)? They just launched a new separate github org for the project. [4] There's a gallery of voila dashboard examples. [5]
> Voila serves live Jupyter notebooks including Jupyter interactive widgets.
> Unlike the usual HTML-converted notebooks, each user connecting to the Voila tornado application gets a dedicated Jupyter kernel which can execute the callbacks to changes in Jupyter interactive widgets.
> - By default, voila disallows execute requests from the front-end, preventing execution of arbitrary code.
[1] https://github.com/reclosedev/requests-cache
[2] https://pandas-datareader.readthedocs.io/en/latest/cache.htm...
[3] https://docs.dask.org/en/latest/caching.html
[4] https://github.com/voila-dashboards/voila
[5] https://blog.jupyter.org/a-gallery-of-voil%C3%A0-examples-a2...
Acess control and resource exhaustion are challenges with building any {Flask, framework_x,} app [from Jupyter notebooks]. First it's "HTTP Digest authentication should be enough for now"; then it's "let's use SSO and LDAP" (and review every release); then it's "why is it so sloww?". JupyterHub has authentication backends, spawners, and per-user-container/vm resource limits.
> Each user on your JupyterHub gets a slice of memory and CPU to use. There are two ways to specify how much users get to use: resource guarantees and resource limits. [6]
[6] https://zero-to-jupyterhub.readthedocs.io/en/latest/user-res...
Some notes re: voila and JupyterHub:
> The reason for having a single instance running voila only is to allow non JupyterHub users to have access to the dashboards. So without going through the Hub auth flow.
> What are the requirements in your case? Voila can be installed in the single user Docker image, so that each user can also use it on their own server (as a server extension for example). [7]
[7] https://github.com/voila-dashboards/voila/issues/112
You should ask for telemetry permissions _before_ the process starts up (as you do for email address), and keep the default as "No", instead of start to send the data transparently unless non user friendly steps are taken by the user.
Also caching is a great idea but I would expect a lot of this logic to be managed on the server side, or I am missing something and ML is different here? I would expect to pipe as little data as possible back to the application because I want the user to wait max 3-4 seconds for the app to load at start.
Also take a look at Streetscape.gl [2] which is designed for visualizing AV data
Disclaimer: I work on Uber's data vis team but not on AVs.
[0] https://streamlit.io/docs/api.html#streamlit.deck_gl_chart [1] https://deck.gl/#/documentation/deckgl-api-reference/layers/... [2] https://avs.auto/
Can we use asyncio to update multiple charts simultaneously / at arbitrary intervals?
Wouldn't it be better if Jupyter absorbed this API for its dashboards?
More information: to prevent unexpected behavior, Streamlit tries to detect mutations in cached objects so it can alert the user if needed. However, something went wrong while performing this check.
Please file a bug... "
[1] https://github.com/johnj/salt-pex