Shiny para Python

O Shiny nasceu em R, mas desde 2023 existe oficialmente em Python — o mesmo modelo reativo, agora na linguagem dominante de ciência de dados e ML. Isso abre projetos híbridos: uma equipe de modelagem que vive em Python pode construir seus próprios dashboards sem migrar para R, e você — que domina o Shiny — consegue transitar entre os dois mundos. Esta aula transfere tudo que você aprendeu para a sintaxe Python, destacando o que muda e o que permanece idêntico.

Entender o Shiny para Python: instalação e estrutura, o modelo reativo com decoradores (@render, @reactive.calc, @reactive.effect), a diferença entre a API Core e a Express, e como o conhecimento de Shiny em R se transfere quase inteiro — permitindo atuar em projetos híbridos R/Python.

O poder do Shiny para Python

Boa parte da ciência de dados e praticamente todo o deep learning vivem em Python (pandas, scikit-learn, PyTorch). Antes, quem trabalhava em Python e queria um dashboard tinha Dash ou Streamlit — bons, mas com modelos mentais próprios. Shiny para Python traz o modelo reativo maduro do Shiny para essa comunidade, e — para você — significa que o mesmo conhecimento serve nas duas linguagens. A reatividade, os módulos, o bslib (sim, o mesmo!), o deploy com Docker: tudo se transfere.

pip install shiny        # instala o Shiny para Python
shiny create meu_app     # cria um app de exemplo
shiny run --reload       # roda com hot-reload

O mesmo modelo reativo, sintaxe diferente

Compare lado a lado. Em R:

library(shiny)
ui <- fluidPage(
  sliderInput("n", "N", 1, 100, 50),
  textOutput("quadrado")
)
server <- function(input, output, session) {
  output$quadrado <- renderText({ input$n^2 })
}
shinyApp(ui, server)

O equivalente em Python (API Core):

from shiny import App, ui, render

app_ui = ui.page_fluid(
    ui.input_slider("n", "N", 1, 100, 50),
    ui.output_text("quadrado"),
)

def server(input, output, session):
    @render.text                      # decorador no lugar de render*()
    def quadrado():
        return input.n() ** 2         # input.n() — chamada, não input$n

app = App(app_ui, server)

As diferenças de sintaxe, todas mecânicas:

Inputs são funções: input.n() (com parênteses) em vez de input$n. Ler um input é chamá-lo.
Outputs usam decoradores: @render.text acima da função, em vez de output$x <- renderText(...). O nome da função vira o id do output.
Componentes com pontos: ui.input_slider(...), ui.page_fluid(...) — namespace ui. em vez de funções soltas.
O modelo mental é idêntico: fonte reativa → o output depende dela → recalcula quando muda. Tudo o que vale na arquitetura reativa vale aqui.

Os equivalentes reativos

Cada peça de reatividade do R tem seu par em Python. Se você entendeu a arquitetura reativa, já sabe usá-los — só muda a grafia:

R	Python	Papel
`reactive({...})`	`@reactive.calc`	condutor: calcula e retorna valor (cacheado)
`observe({...})`	`@reactive.effect`	sumidouro: efeito colateral
`observeEvent(x, {...})`	`@reactive.effect` + `@reactive.event(x)`	efeito só no gatilho
`eventReactive(x, {...})`	`@reactive.calc` + `@reactive.event(x)`	valor só no gatilho
`reactiveVal()`	`reactive.value()`	estado do app mutável
`req(x)`	`req(x)`	mesma função, mesmo nome

from shiny import reactive, render, req

def server(input, output, session):
    # CONDUTOR (= reactive do R): calcula e cacheia
    @reactive.calc
    def dados_filtrados():
        req(input.arquivo())                    # req existe igual
        return carregar(input.arquivo()).query(f"regiao == '{input.regiao()}'")

    # SUMIDOURO com gatilho (= observeEvent do R)
    @reactive.effect
    @reactive.event(input.salvar)               # só dispara no clique de salvar
    def _():
        salvar_no_banco(dados_filtrados())
        ui.notification_show("Salvo!")          # = showNotification

    # OUTPUT que lê o condutor
    @render.data_frame
    def tabela():
        return dados_filtrados()                 # lê o reactive.calc

O paralelo é quase um dicionário de tradução. Note @reactive.event(input.salvar) empilhado sobre @reactive.effect: é o padrão Python para "só no gatilho", combinando dois decoradores onde o R usava uma função única (observeEvent).

Core vs Express: duas APIs

O Shiny para Python tem duas formas de escrever apps, e é bom saber distingui-las:

Core API: ui/server separados, explícita — espelha o Shiny de R e é melhor para apps grandes e módulos. É a que usamos acima.
Express API: UI e lógica juntas no mesmo fluxo, mais concisa — ótima para apps pequenos e protótipos rápidos. Não tem equivalente direto em R.

# EXPRESS: UI e server misturados, muito conciso
from shiny.express import input, render, ui

ui.input_slider("n", "N", 1, 100, 50)

@render.text
def resultado():
    return f"Quadrado: {input.n() ** 2}"

Regra prática: Express para explorar/prototipar; Core para apps de produção, módulos e tudo que este curso ensinou sobre arquitetura. Como você vem do R, o Core vai lhe parecer familiar imediatamente.

O que se transfere direto (e o que muda)

A notícia boa é quanta coisa é idêntica:

bslib: os mesmos page_sidebar, card, value_box, layout_columns existem em Python (ui.page_sidebar, ui.card, ...). Arquitetura responsiva e identidade visual transferem quase sem alteração.
Módulos: o Shiny para Python tem módulos com namespace (@module), mesmíssimo conceito de programação em Shiny.
Deploy: Docker e a lógica de conteinerização de implantação com Docker são idênticas — troca-se a imagem base para uma de Python e pip install em vez de renv. ShinyProxy serve apps Python do mesmo jeito.
Widgets: plotly, leaflet (via ipyleaflet/shinywidgets), tabelas — via a ponte shinywidgets para os widgets do ecossistema Jupyter.

O que muda de fato: a sintaxe (decoradores, inputs como funções), o ecossistema de dados (pandas/polars no lugar de dplyr), e alguns nomes. O modelo mental — a reatividade — é o mesmo. Foi por isso que investimos tanto na arquitetura reativa: aquele grafo reativo é a fundação nas duas linguagens.

Quando usar cada linguagem num projeto híbrido

Numa organização real com equipes mistas, a decisão costuma ser:

R + Shiny: quando a análise já vive em R (tidyverse, modelos estatísticos, sf), a equipe é de estatística/análise, e você quer o ecossistema mais maduro de Shiny (mais pacotes, golem).
Python + Shiny: quando a análise vive em Python (ML/deep learning, pandas, engenharia de dados), a equipe é de ML/engenharia, e integrar o dashboard ao pipeline Python evita reescrever tudo em R.
Ambos: um mesmo application.yml de ShinyProxy pode servir apps R e Python lado a lado — cada equipe usa sua linguagem, o portal é único. É o cenário "híbrido" que o objetivo do curso mencionou.

O Shiny existe oficialmente em Python desde 2023, com o mesmo modelo reativo do R — e é isso que torna o conhecimento transferível. A sintaxe muda em três pontos: inputs são funções, como input.n(); outputs usam decoradores, como @render.text, com o nome da função servindo de id; e os componentes vivem no namespace ui.. As equivalências são diretas: reactive vira @reactive.calc, observe vira @reactive.effect, observeEvent é @reactive.effect com @reactive.event, eventReactive é @reactive.calc com @reactive.event, reactiveVal vira reactive.value, e o req é igual. Há duas APIs: a Core, com ui e server separados, boa para produção e módulos e familiar a quem vem do R; e a Express, que junta UI e lógica, boa para protótipos. Transferem-se quase sem alteração o bslib, com os mesmos componentes, os módulos via @module, e o deploy em Docker e ShinyProxy; o que muda é o ecossistema de dados, com pandas e polars, e a sintaxe. Em projetos híbridos, escolha a linguagem pela do pipeline e da equipe — o ShinyProxy serve apps R e Python no mesmo portal.

Exercícios

Traduza este trecho de R para Shiny para Python (Core): um sliderInput("x") e um textOutput que mostra o dobro de x.
✓ Resposta:
```
from shiny import App, ui, render
app_ui = ui.page_fluid(
    ui.input_slider("x", "X", 1, 100, 10),
    ui.output_text("dobro"),
)
def server(input, output, session):
    @render.text
    def dobro():
        return input.x() * 2
app = App(app_ui, server)
```
Pontos-chave: ui.input_slider/ui.output_text no namespace ui.; o output é a função dobro decorada com @render.text (o nome vira o id); e o input é chamado com input.x(), não input$x.
Qual é o equivalente em Python de eventReactive(input$rodar, {...}) e por que ele usa dois decoradores?
✓ Resposta:
É um @reactive.calc combinado com @reactive.event(input.rodar):
```
@reactive.calc
@reactive.event(input.rodar)
def resultado():
    return calculo_pesado(input.param())
```
Usa dois decoradores porque cada um expressa uma faceta que, em R, eventReactive reúne numa função só: @reactive.calc diz "isto é um condutor que retorna um valor cacheado" (o análogo de reactive), e @reactive.event(input.rodar) diz "só recalcule quando este gatilho disparar" (o análogo do primeiro argumento de eventReactive). Empilhados, reproduzem "valor recalculado apenas no gatilho".
Qual a diferença entre a Core API e a Express API do Shiny para Python, e quando usar cada uma?

✓ Resposta:
Na Core API, a UI (app_ui) e o server são definidos separadamente e conectados por App(app_ui, server) — estrutura explícita que espelha o Shiny de R e favorece apps grandes, módulos e arquitetura de produção. Na Express API, a UI e a lógica reativa ficam entrelaçadas no mesmo fluxo do arquivo, resultando em código mais conciso — ótimo para protótipos e apps pequenos. Use Express para explorar rapidamente e Core para produção/módulos (e por ser mais familiar a quem já conhece o Shiny de R).
Verdadeiro ou falso: "migrar de Shiny R para Python exige reaprender o modelo de reatividade". Justifique.

✓ Resposta:
Falso. O modelo de reatividade é o mesmo nas duas linguagens: fontes reativas (inputs), condutores que calculam e cacheiam, sumidouros que produzem efeitos/outputs, avaliação preguiçosa e invalidação — tudo o que vale na arquitetura reativa vale igual. O que muda é a sintaxe (decoradores @render/@reactive.*, inputs chamados como funções) e o ecossistema de dados (pandas/polars em vez de dplyr). Reaprende-se a grafia, não o modelo mental — por isso o conhecimento de Shiny se transfere quase inteiro entre R e Python.
Numa empresa, a equipe de ML trabalha 100% em Python e quer um dashboard integrado ao seu pipeline de modelos. Já existe um portal ShinyProxy servindo apps R. O que você recomenda?

✓ Resposta:
Recomendo construir o dashboard em Shiny para Python, para que ele conviva no mesmo pipeline Python da equipe de ML (sem reescrever modelos em R) e aproveite pandas/PyTorch/scikit-learn diretamente. Para o deploy, conteinerizar o app Python com Docker (imagem base Python + pip install, análogo a implantação com Docker) e adicioná-lo ao mesmo application.yml do ShinyProxy existente como mais um specs com sua container-image. O ShinyProxy serve apps R e Python lado a lado no mesmo portal, com a mesma autenticação/autorização. Assim cada equipe usa sua linguagem e a organização mantém um único ponto de acesso — o cenário híbrido ideal.