I am testing this new-ish method of deploying R shiny
apps on dumb web servers by leveraging the WASM
technology.
I have produced this simple app that doesn't need any data. Its only function is allow the user to upload a .csv
file. It then reads the file and displays its content.
Here is the app:
# Load required libraries
library(shiny)
library(shinythemes)
# Define UI
ui <- fluidPage(
theme = shinytheme("flatly"),
# App title
titlePanel("CSV File Uploader"),
# Sidebar layout with input and output definitions
sidebarLayout(
sidebarPanel(
fileInput("file", "Choose CSV File", accept = ".csv"),
tags$hr(),
checkboxInput("header", "Header", TRUE),
checkboxInput("stringAsFactors", "Convert strings to factors", TRUE)
),
# Show CSV data
mainPanel(
tableOutput("contents")
)
)
)
# Define server logic
server <- function(input, output) {
# Read CSV file
data <- reactive({
req(input$file)
df <- read.csv(input$file$datapath,
header = input$header,
stringsAsFactors = input$stringAsFactors)
return(df)
})
# Show CSV data
output$contents <- renderTable({
data()
})
}
# Run the application
shinyApp(ui = ui, server = server)
I save this file under the name "app.R"
and then package the app and save it in a folder called "app"
by using shinylive::export()
function.
Testing the app locally using httpuv
package works well:
httpuv::runStaticServer("path-to-the-exported-app-folder")
Ultimately, I want to upload the app files to a Github repository and view the app through github pages
facility.
Unfortunately, the files are too huge. Viewing the properties of the "app"
folder reveals its size is 98mb
. How is that possible?
Trying to run this app using github pages results in a "time out"
error.
What is happening?
I've broken this post into sections to address the concerns raised. Hopefully, it helps!
Shinylive apps require around 60 MB or more data due to their dependency on the initial webR base and all {shiny} package dependencies. When moving away from a compute server running Shiny Server to a generic web server, the trade-off lies in the amount of user bandwidth required. So, the users internet and computer is paying for the ability to view the app compared to the old status quo where the host paid a license fee (to Posit), server and maintenance costs.
You can inspect the current list of package dependencies for a basic Shiny app using the following R code:
pkg_db <- tools::CRAN_package_db()
shiny_pkg_dependencies <- tools::package_dependencies(
packages = c("shiny"),
recursive = TRUE,
db = pkg_db
)
shiny_pkg_dependencies
#> $shiny
#> [1] "methods" "utils" "grDevices" "httpuv" "mime"
#> [6] "jsonlite" "xtable" "fontawesome" "htmltools" "R6"
#> [11] "sourcetools" "later" "promises" "tools" "crayon"
#> [16] "rlang" "fastmap" "withr" "commonmark" "glue"
#> [21] "bslib" "cachem" "ellipsis" "lifecycle" "base64enc"
#> [26] "jquerylib" "memoise" "sass" "digest" "Rcpp"
#> [31] "cli" "magrittr" "stats" "graphics" "fs"
#> [36] "rappdirs"
Adding more R packages through in-app dependencies will expand this list and increase the download size of each app.
Please avoid using the gh-pages
branch deployment technique for sharing the app on GitHub pages.
Instead, opt for the GitHub Actions approach, which is preferred because it doesn't store artifacts from converting a Shiny App into a Shinylive App inside the repository. Plus, this approach allows for Shinylive apps to be deployed up to the GitHub Pages maximum of about 1 GB.
Specifically, we're advocating for a file structure of:
.
├── .github
│ └── workflows
│ └── build-and-deploy-shinylive-r-app.yml
├── README.md
└── app.R
Thus, we could place the example app source code into app.R
and, then, use the following GitHub Action in .github/workflows/build-and-deploy-shinylive-r-app.yml
to build and deploy the shinylive app every time the repository is updated.
on:
push:
branches: [main, master]
release:
types: [published]
workflow_dispatch: {}
name: demo-r-shinylive-app
jobs:
demo-website:
runs-on: ubuntu-latest
# Only restrict concurrency for non-PR jobs
concurrency:
group: r-shinylive-website-${{ github.event_name != 'pull_request' || github.run_id }}
# Describe the permissions for obtain repository contents and
# deploying a GitHub pages website for the repository
permissions:
contents: read
pages: write
id-token: write
steps:
# Obtain the contents of the repository
- name: "Check out repository"
uses: actions/checkout@v4
# Install R on the GitHub Actions worker
- name: "Setup R"
uses: r-lib/actions/setup-r@v2
# Install and pin the shinylive R package dependency
- name: "Setup R dependency for Shinylive App export"
uses: r-lib/actions/setup-r-dependencies@v2
with:
packages:
cran::shinylive@0.1.1
# Export the current working directory as the shiny app
# using the pinned version of the Shinylive R package
- name: Create Shinylive App from working directory files
shell: Rscript {0}
run: |
shinylive::export(".", "_site")
# Upload a tar file that will work with GitHub Pages
# Make sure to set a retention day to avoid running into a cap
# This artifact shouldn't be required after deployment onto pages was a success.
- name: Upload Pages artifact
uses: actions/upload-pages-artifact@v2
with:
retention-days: 1
# Use an Action deploy to push the artifact onto GitHub Pages
# This requires the `Action` tab being structured to allow for deployment
# instead of using `docs/` or the `gh-pages` branch of the repository
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v2
Deployment with this approach requires it to be enabled by:
For a comprehensive example demonstrating deployment, documentation, and a functional version of your app, refer to the following:
Some quick screenshots that describe whats up: