Data Flow — westside-streamlit

How a page render moves data from the Postgres database to the user's browser. Streamlit re-runs the entire script on every interaction; the @st.cache_data(ttl=30) decorator keeps repeat queries off the database for 30 seconds.

Current app.py issues 4 SELECTs per cold render (counts, offered, declined, signed, jerseys — signed is behind an expander so it only runs when opened; jerseys and offered are the heavy ones). With ttl=30 and an audience of 2, database load is effectively negligible: < 10 queries/minute at peak.

Streamlit's mental model: every widget interaction re-runs the whole script. Cached queries return instantly on re-run; everything else (pandas filtering, rendering) is pure Python on a small DataFrame, so the loop feels immediate.

This is why caching is critical: without the 30s TTL, every filter click would hit the database 4 times.

There is none. The dashboard issues zero writes. All mutations go through:

This is a deliberate architectural decision, not a limitation. It keeps the Streamlit app safe to iterate on without risk of corrupting production data.