RShiny & Shiny for Python: 6 wichtige Unterschiede

Mit Shiny for Python ergeben sich für Python-Entwickler und -Entwicklerinnen neue Möglichkeiten. Für diejenigen, die bereits Erfahrung in R Shiny besitzen, beleuchten wir 6 Unterschiede, die es zu beachten gilt.

RShiny & Shiny for Python: 6 wichtige Unterschiede

Mit Shiny for Python ergeben sich für Python-Entwickler und -Entwicklerinnen neue Möglichkeiten. Für diejenigen, die bereits Erfahrung in R Shiny besitzen, beleuchten wir 6 Unterschiede, die es zu beachten gilt.

Für wen ist Shiny for Python relevant?

Zunächst muss man sich mit den Unterschieden der Programmiersprachen R und Python bzw. mit der beabsichtigten Umsetzung beschäftigen. In einem vorherigen Beitrag sind wir auf diese Unterschiede eingegangen: Während R bzw. Shiny sich hervorragend für Datenvisualisierung eignet und ein sehr gut ausgebautes Ökosystem rund um die Posit-Produkte (ehemals RStudio) besitzt, sitzen bei Python die Stärke u.a. bei der Umsetzung von Natural-Language-Processing-Modellen, Bilderkennung sowie bei der Visualisierung von Daten.

Unterschiede von Shiny for Python und R Shiny

Eine gute Nachricht vorweg: Die Unterschiede zwischen R Shiny und Shiny for Python sind nicht so gravierend, wie die Unterschiede zwischen den R und Python vermuten lassen. Die meisten Hauptkomponenten von R Shiny sind bei Shiny for Python identisch. Dies schließt Reaktivität, Rendering-Funktionen und Module ein, da diese auf demselben JavaScript-Code basieren. Die folgenden Unterschiede gibt es jedoch:

1. Decorators statt Render-Funktionen
2. Der Output des UI wird durch Funktionsnamen gesteuert
3. Submodule statt single package namespaces
4. Input wird mit input.() aufgerufen
5. Einige Funktionen besitzen andere Namen
6. Die Server-Logik ist etwas anders

1. Decorators statt Render-Funktionen

Shiny for Python verwendet Decorators anstelle von Rendering-Funktionen. Decorators sind im Wesentlichen Python-Funktionen, die andere Funktionen als Argumente akzeptieren und aktiviert werden, indem man „@<decorator>“ über die Funktionsdeklaration setzt. Obwohl es in R kein direktes Äquivalent zu Decorators gibt, haben sie Ähnlichkeiten mit Funktionsoperatoren wie purrr::safe.

library(shiny)

ui <- fluidPage(
  sliderInput("n", "N", 0, 100, 40),
  verbatimTextOutput("txt")
)

server <- function(input, output, session) {
  output$txt <- renderText({
    paste0("n*2 is ", input$n, " * 2")
  })
}

shinyApp(ui, server)
Code-Sprache: R (r)

from shiny import ui, render, App

app_ui = ui.page_fluid(
    ui.input_slider("n", "N", 0, 100, 40),
    ui.output_text_verbatim("txt"),
)

def server(input, output, session):
    @output
    @render.text
    def txt():
        return f"n*2 is {input.n() * 2}"

app = App(app_ui, server)
Code-Sprache: Python (python)

QUELLE: https://shiny.rstudio.com/py/docs/comp-r-shiny.html

2. Output des UI wird durch Funktionsnamen gesteuert

R Shiny und Shiny for Python verwenden beide einen eindeutigen Objekttyp, um eine Verbindung zwischen Serverberechnungen und UI-Komponenten herzustellen. Ihre Schnittstellen unterscheiden sich jedoch erheblich. In R Shiny stellen wir die Verbindung her, indem wir das Ausgabeobjekt den UI-Elementen zuweisen. In Python hingegen, wo Renderings mit Hilfe von Decorators erzeugt werden, stellen wir die Verbindung zwischen Objekt und UI-Komponente über den Funktionsnamen her. In Shiny for Python wird die Ausgabe nicht durch Zuweisung von output$x definiert.

3. Submodule statt single package namespaces

Während in R Shiny alle Funktionen in einem einzigen single package namespace verortet sind, werden bei Shiny for Python Submodule verwendet. Dabei sind Submodule nicht mit Shiny-Modulen zu verwechseln. So wird beim Aufrufen von sliderInput() anstelle von ui.input_slider() genutzt, welches auf das ui-Submodul des Shiny-Moduls verweist.

4. Input aufrufen

Während in R reaktive Werte und Ausdrücke mit unterschiedlichen Ausdrücken aufgerufen werden, werden diese in Python mit einer Funktion aufgerufen. In diesem Fall wird input.value() statt input.value genutzt.

5. Änderungen von Funktionsnamen

Um die Handhabung der Auto-Vervollständigung in Shiny for Python zu vereinfachen, wurden die Namen einiger Funktionen geändert. Grundsätzlich gilt: Output-Funktionen beginnen mit output_ , Input-Funktionen dementsprechend mit input_ . Nutzt man in R beispielsweise plotOutput nutzt man in Shiny for Python nun output_plot() .

Es sei erwähnt, dass nicht alle Funktionen diesem Schema folgen, eine Übersicht über die wichtigsten Änderungen der Namen finden Sie auf der offiziellen Shiny von Posit Seite.

6. Serverlogik

Bisher musste für Python eine separate Server-Client-Architektur genutzt werden. Das heißt, der Server führte Python und Shiny aus, während sich die Endgeräte per Browser aufschalten – ähnlich wie bei R Shiny bei dem es bisher noch ein dedizierter Shiny-Server nötig ist. Wobei wir an dieser Stelle auf die aktuelle Entwicklung im webR-Projekt hinweisen, welches sich genau mit dieser Thematik beschäftigt.

Mit Shinylive, hat Posit eine komfortable Lösung entwickelt: Hier laufen beide Instanzen auf dem Endgerät – es fungiert also als Server UND Client gleichzeitig. Der Webserver dient dabei, vereinfacht gesagt, als Speicherort der Daten. Das heißt, die Daten können bequem in Github-Pages oder Amazon S3 abgelegt werden.

Damit Shinylive (for Python) dies umsetzen kann, nutzt man das binäre Format Webassembly (wasm) sowie das für wasm kompilierte Portierungspaket Pyodide.

Dadurch ergeben sich für Nutzer und Nutzerinnen von Shiny for Python, bzw. Shinylive verschiedene Vorteile:

• Keine Installation notwendig
  Für die Verwendung von Shiny for Python müssen weder Python noch Shiny auf dem lokalen Computer installiert werden.
  
• Vereinfachtes Teilen
  Anwendungen lassen sich bequem per URL teilen.
  
• Deployment
  Shiny for Python Anwendungen lassen sich in fast allen statischen Webhosting-Diensten hosten.
  
• Skalierbarkeit
  Da die Daten für die Shiny for Python Anwendungen auf einem statischen Server liegen, kann dieser einfacher hohem Traffic umgehen.
  
• Sicherheit
  Shiny for Python Anwendungen laufen auf den Endgeräten in einer Browser-Sandbox speziell für Code ab – d.h. der Code der Anwendung wird nicht auf einem separaten Server ausgeführt. Dadurch werden entsprechende Sicherheitsrisiken reduziert.

Auf der anderen Seite müssen sich Entwickler und Anwender bei der Nutzung von Shiny for Python an gewisse Änderungen gewöhnen:

• Aktuell sind nicht alle gängigen Python-Pakete in Pyodide (und damit in Shinylive) verfügbar.
  
• Durch die Ausführung im Browser der Endgeräte werden die entsprechende Pakete dort heruntergeladen. Daher empfiehlt sich eine stabile und schnelle Netzverbindung.
  
• Der Code der Anwendung ist vollumfänglich im Browser der Endgeräte einsehbar.
  
• Zur Wahrung der Sicherheit kommt es zu Einschränkungen des Netzwerkverkehrs .

Ausführliche Informationen zu Shinylive finden Sie auf der offiziellen Shinylive-Seite von Posit.

Fazit

Mit Shiny for Python können Python-Entwickler und -Entwicklerinnen die Vorteile von Shiny für eigene Projekte nutzen. Die größten Unterschiede ergeben sich gegenüber R Shiny der Shinylive Ausführung und der damit verbunden Anforderung an die Netzverbindung sowie dem Styling der Shiny-Apps – das Einbringen von CSS ist in R aktuell noch komfortabler gelöst. Durch die Entwicklung bzw. Öffnung von Shiny for Python und Shinylive hat unser Partner Posit die Data Science Community noch enger miteinander verbunden.