Streamlit, shift your mindset, an interesting tip
Coming from a JS background, it has been hard to admit Python can be used for building web applications :-)
My biggest question was “why do you want to build in Python while JS/HTML/CSS are the only front end languages in modern browsers”.
I totally agree Python is by far superior for data science and data engineering — concision and performance wise it’s clearly better than JS.
Focusing on Data applications, an organization needs various skills to deliver web applications able to analyze, visualize, and offer interactivity:
- Data engineering/Data science
- Back-end development
- Front-end development
- Infrastructure
And here is where my mind is changing thanks to Streamlit. It greatly shrinks the first 3 steps, making it easy for a team to build an app themselves.
And soon with Snowflake deployment (including security aspects like authentication and authorisation), there will be an easy way to handle infrastructure as well. Meaning that it will be both easy to develop and deploy tactical (but very operational) applications, allowing you to drive decisions much faster.
In a way that was the “embedded analytics” promise, but my experience shows it hasn’t been adopted broadly, it’s often very static (although in context), it still involves pure web development dexterity plus BI/data competences.
IMHO, the key success factor is speed, not only to develop but also to maintain. The more autonomy a team has, the faster they’ll deliver, and I’m betting Streamlit will be the answer to this challenge for many data teams.
If you’re interested in trying Streamlit then heads up that the stateless mindset (code reruns) was surprising. It took me a while to adapt my thinking from my JS async experience. Every time a user interacts with widgets in your app, the script is re-executed. Out-of-the-box widgets automatically store their values and re-render properly.
However it can be very confusing if you’re not consistently assigning a formal “key” to those widgets. If you want to store business logic across runs then you need to use the session state object to maintain consistency.
To illustrate the potential confusion, I strongly encourage you to test:
import streamlit as st
st.session_state
st.session_state.sd = st.slider(“Change my value”, 0, 10, key=”slider_key”)
Would you expect st.session_state.sd to be equal st.session_state.slider_key ?
It’s true but only the first time, both are not instantiated, if you change the slider value, you’ll see st.session_state.sd is one step behind st.session_state.slider_key !
My advice is:
- Always declare a widget with a key
- Always use that key in session_state to retrieve value
- Never mix custom a session_state key in conjunction with widget key session_state
This is one of my findings I wanted to share in this article, since it took me a few hours to figure out what the problem was in my code :-)
More to come later, especially for creating Streamlit custom components
