> For the complete documentation index, see [llms.txt](https://docs.healthuniverse.com/overview/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.healthuniverse.com/overview/building-apps-in-health-universe/developing-your-health-universe-app/working-in-streamlit/streamlit-best-practices.md).

# Streamlit Best Practices

Streamlit is an excellent tool for rapidly prototyping healthcare and data-driven applications. It automatically generates a user-friendly interface from your Python code, allowing you to focus on functionality and logic without needing to manually design front-end elements. This makes Streamlit a great starting point when developing apps for Health Universe.

Many developers choose to **start with Streamlit** when building a new app because:

* It allows for fast iteration: You can immediately visualize how inputs, outputs, and layout affect the user experience.
* You can debug and refine your logic more easily in a visual context.
* It supports integration with healthcare data formats like FHIR, CCDA, and CSV using native Python libraries.

Once the app’s behavior and interface are solid, developers then are able to easily migrate the codebase to FastAPI for production use with **Navigator**, where performance, modularity, and robust API control are priorities.

Here are some **best practices** to keep in mind when using Streamlit for your initial app development:

**1. Organize Your Code Clearly**

* Use functions or modular components to keep the code clean and readable.
* Separate function logic from UI logic where possible.

**2. Minimize Reruns**

* Use Streamlit’s `@st.cache_data`, `@st.cache_resource`, or `st.session_state` to store data or avoid expensive re-computations on every input change.
* Learn more: [Streamlit Caching Guide](https://docs.streamlit.io/1.27.2/library/advanced-features/caching)

**3. Use Layout Features Thoughtfully**

* Leverage columns (`st.columns()`), expanders (`st.expander()`), and sidebar components (`st.sidebar`) for better organization.
* Use `st.markdown` with custom HTML/CSS for layout tweaks when needed.

**4. Make It User-Friendly**

* Add clear labels, tooltips (`help=...`), and default values.
* Handle errors gracefully with `st.error()` or `try/except` blocks around sensitive logic.

**5. Test with Real Data**

* Test with a variety of realistic files (e.g., FHIR JSON, CCDAs) early on to uncover edge cases and formatting issues.

#### Helpful Links

* 📚 [Streamlit Documentation](https://docs.streamlit.io/)
* 🧪 [Cheat Sheet for Streamlit](https://docs.streamlit.io/library/cheatsheet)
* 💬 [Streamlit Community Forum](https://discuss.streamlit.io/)
* 🎨 [Streamlit Layout & Theming Guide](https://docs.streamlit.io/library/advanced-features/layouts)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.healthuniverse.com/overview/building-apps-in-health-universe/developing-your-health-universe-app/working-in-streamlit/streamlit-best-practices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.