Sanity-checking my understanding of a typical Positron workflow for Python apps

I’m trying to sanity-check my understanding of a typical Positron workflow for Python data apps.

My rough mental model is:

  • Positron for authoring, analysis, debugging, and running apps
  • Shiny for Python as the interactive front end
  • FastAPI as an optional backend/service layer
  • Quarto for reproducible reporting

Here's an architectural diagram using FastAPI for the backend:

My guess is that, in a more normal data science workflow, Shiny is probably more common than FastAPI because data scientists are more often building interactive tools for people than separate backend APIs for other software systems.

So for smaller apps, I assume Shiny might connect directly to data/services, while for larger apps, FastAPI might sit in between.

Is that roughly how Positron is used in practice, or is that too architecture-heavy for the normal workflow?

Also: Shiny have its own server/runtime?

1 Like

First analyze the existing information on the Posit site, then consider in the context of what skills current undergraduate computer science and data science students to get that first entry job in a tough job market the the back half of 2026 and throughout 2027. Finally, consider the workflow of a Posit future enterprise customer, not just the great person using Posit free tools.

Standardizing access & ensuring consistent data in data products (using FastAPI and Posit Team)

  • ensure teams are using same dataset regardless of how the analysis was done
  • use FastAPI as data gateway for Jupyter Notebook, Shiny app

benefits summarized from article:

  • code simplification
  • make data accessible to different apps and workflows (both R and Python developers)
  • increased security due to the API authentication layer

my assessment

  • data security needs to be treated seriously. It is a pain for many people to deal with, but I believe that data access must be managed. Using FastAPI authentication with Shiny token-based authentication helps with security. In this architecture, Shiny sends username/password to FastAPI /login using HTTPS and then FastAPI provides validation and sends back a JWT. This is the common Authorization: Bearer <token> format
  • many stories of the data analysis workflow gloss over how the data gets inputted into the data set and how the data analyst confirms they have the most recent dataset. If the data is in manufacturing or ERP, the data is streaming into a central system constantly. In this case, it is going to be painful to constantly attempt to download the data as CSV for every analysis. Additionally, the human is likely doing massive filtering on the dataset with SQL or other query mechanism prior to loading it into pandas or other framework
  • most data workflow stories do not address mobile. Mobile may be relevant in both the presentation and the data input phases. Although mobile web on phones and tablets address parts of these problems, it is often not the best user experience. Shiny does use reactive screen updates, so it is going to be better than Streamlit, but I still think that having the data as a secured API endpoint opens the market for companies that need a mobile device in the field.

Posit Connect Documentation for FastAPI

I believe that FastAPI is a supported deploy type in Posit Connect. However, when I used it with Posit Connect Cloud, I was not able to deploy it.

The document also covers outputting HTML from the FastAPI server in addition to the API data.

The features of Posit Connect (the on-premise enterprise one) look quite excellent, but I can't find any pricing information online.

As a thought exercise, describe the type of person that buys Posit Connect (the on-premise version). If you think about it, I believe you'll see that the "data science" workflow is expanding into new areas.

Shinylive: Shiny + WebAssembly

It is possible to deploy Shiny using wasm and pyodide. This allows Shiny to run in a web browser without the Shiny server.

Although I have not used Shinylive with wasm and pyodid, I have a good amount of experience with wasm and pyodide in Flet wasm deployments. As an aside, Flet when deployed as a server, uses FastAPI itself as the backend while Shiny uses Starlette (which FastAPI itself is based on).

The Shinylive examples use Pyodide. It's impressive that they got it working.

My assessment

Although it is initially seems simpler to run Shiny without a server and use Pyodide with wasm, I do not recommend this approach in general. I do use this approach to host Flet apps on GitHub pages. However, there are differences in compatibility in what Pyodide can use as dependencies versus the local development environment.

1 Like

Hi there! Thanks for posting this, there are a lot of moving parts here, and I think you've got the mental model just about right!

Shiny shares much of its foundation with FastAPI, using packages like starlette and uvicorn under the hood. For most use cases, you won't need both Shiny and FastAPI. The point in time where you'll want to think more critically about your architecture is when you get to deploying your app.

One thing I'd like to point out in your diagram is that Shiny is able to connect directly to data via S3, PostgreSQL, OpenAI through other packages that are compatible with Shiny. Here's a bit more info on Shiny apps connecting to the storage/LLMs you mentioned:

Shiny can be hosted in the cloud, which will require a server. Popular places to deploy Shiny applications are Posit Cloud and HuggingFace. Some apps can be ran entirely in the browser through WebAssembly, in which case you would not need a server at all! This page outlines the server options for Shiny.

Positron's use here is as the place to write and debug the Shiny application.

2 Likes