![]() |
| Suggested cover: a dashboard bootstrap scene where page setup, cache boundaries and sidebar filters are all visible before the interface fills with metrics. |
The Streamlit layer becomes readable when the bootstrap stays honest
After the background threads are launched, the file changes mood again. It moves out of infrastructure and into presentation. This is the point where many mixed-purpose scripts become messy, because page configuration, a cached loader and sidebar controls all arrive at once. In a real internal tool that combination becomes the exact place where future readers decide whether the dashboard has a stable front door or just a pile of side effects that happen to render in the browser.
That is why the bootstrap deserves a patient explanation. Terms like cache TTL, data access boundary and filter surface are doing real work here. The dashboard is not merely showing data; it is defining how often expensive reads happen, where the historical table enters the page and how the operator is allowed to cut the visible slice before charts and KPIs begin speaking.
A good front section does not need to be fancy. It only needs to make the page feel predictable. When the user understands where the page starts, where the data comes from and how filters narrow the scope, the rest of the article can become more ambitious without becoming tiring.
| Dashboard term | Meaning | Why it matters here |
|---|---|---|
| Cache TTL | The freshness window Streamlit uses before recomputing cached data. | It decides whether the app feels responsive, stale or wasteful. |
| Data access boundary | The moment where the UI stops being layout code and starts reading the database. | It keeps operational questions easy to answer because the read path is explicit. |
| Filter surface | The set of controls that shape the currently visible slice of data. | It gives the dashboard a clear contract with the person using it. |
The page setup and first loader establish the dashboard's main contract
st.set_page_config(page_title="ITS Analytics Hub", layout="wide")
st.title("ITS Analytics Dashboard")
@st.cache_data(ttl=5)
def load_data():
conn = psycopg2.connect(**db_config)
df = pd.read_sql("SELECT * FROM mart.traffic_history ORDER BY report_hour DESC LIMIT 1000", conn)
conn.close()
return dfThe first visible slice keeps page identity and historical loading together, which makes the dashboard's opening contract easy to understand.
This is a good example of how a mixed file can still feel disciplined. The page title tells the operator what screen they are on, and the cached loader immediately explains what historical dataset the rest of the interface will depend on.
The first pass through the page checks whether the cached history is usable
try:
df = load_data()
if df.empty:
st.info("Waiting for data...")
else:
df['report_hour'] = pd.to_datetime(df['report_hour'])The opening of the main block stays direct on purpose: load the cached frame, admit when it is empty and normalize the timestamp only when the history table actually returns something useful.
That sequence matters because it keeps the dashboard honest. The page does not pretend freshness or structure until the underlying history has produced a slice the rest of the interface can safely depend on.
The sidebar controls stay narrow and tied to the dataframe itself
st.sidebar.header("Filters")
selected_camera = st.sidebar.selectbox("Camera", df['camera_id'].unique())
selected_types = st.sidebar.multiselect("Vehicle Types", df['vehicle_type'].unique(),
default=df['vehicle_type'].unique())The filter surface stays compact and readable, which helps the page feel stable before any metric card begins trying to summarize the traffic picture.
There is a lot of value in that restraint. The controls do not invent extra state. They simply expose the camera and vehicle-type fields already present in the dataframe and let the operator narrow the slice with minimal ceremony.
The filtered slice prepares the handoff into KPI rendering
df_filtered = df[(df['camera_id'] == selected_camera) & (df['vehicle_type'].isin(selected_types))]
if not df_filtered.empty:
last = df_filtered.iloc[0]The final bootstrap slice condenses the selection logic into one visible expression and then lifts out the latest row for the first dashboard summary.
This is a useful place to pause because it shows how the dashboard earns the right to display metrics. One filtered dataframe is created, one recent row is selected and only then does the page move into headline output.
- This article walks through page setup, cache controls, filter widgets and the first filtered dataframe.
- The snippets stay in order and stop right before the headline KPI section begins to render.
- The text keeps the focus on how a calm dashboard bootstrap is assembled.
A dashboard feels calmer when its page setup, cache rules and filters are visible before its metrics start talking loudly.



Reading Map
Start from one of these pages if you want to jump straight to a useful section of the site.
Browse the main page with all recent posts
Open the Python workflow article
Read the guide about archiving files
Send feedback or suggest a new topic