Publishing Platform for communicating impactful data science work R Markdown is a tool for creating computational documents - can contain interactive elements Interactivity Spectrum
Iteration • Shiny development starts innocently • Natural choice for tool-building projects in R • Quickly escalates when you want to give access to someone else
- Rambling, Cluttered - Parts that work well - Parts that work not-so well Local Development EDA, Prototyping, Iteration The “Lightning-Talk” of Data Products - Targeted - Elegant - Streamlined - Optimized Production Development
Case for Starting with Shiny • Kelly’s Shiny in Production “Most Important Thing” • Joe Cheng’s “Most Important Thing” • An example: CRAN Logs - Trending Packages App ◦ Joe’s Performance Workflow ◦ Refactoring for Production ◦ Evaluating Impact ◦ Reconsidering the Hierarchy of Interactivity
Packages to Support Shiny in Production: - shinytest - Automated UI testing for Shiny - shinyloadtest - load testing for shiny - profvis - Profiler for R code - plot caching - dramatically speed up repeated techniques - async - last resort technique for dealing with slow operations resources.rstudio.com/webinars
Packages to Support Shiny in Production: - shinytest - Automated UI testing for Shiny - shinyloadtest - load testing for shiny - profvis - Profiler for R code - plot caching - dramatically speed up repeated techniques - async - last resort technique for dealing with slow operations resources.rstudio.com/webinars
Use shinyloadtest to see if app is fast enough 2. If not, use profvis to see what’s making it slow 3. Optimize a. Move work out of shiny (very often) b. Make code faster (very often) c. Use caching (sometimes) d. Use async (occasionally) 4. Repeat! CRAN Whales App is so slow • We didn’t know until shinyloadtest • Profile - the code: why is it so slow? • ETL Process - Moving work out of Shiny
cranlogs API /trending endpoint to get the top 10 trending packages 2. Makes 10 more calls to the cranlogs API to retrieve download counts for each package 3. Drops that data into DT 4. Uses rvest magic to scrape metadata about each package Visit the cranlogs API project on GitHub: r-hub/cranlogs.app
my local development environment! Works okay on my RStudio Connect staging server… Is it fast enough to support the number of users I expect? Activate the Performance Workflow! Visit the cranlogs API project on GitHub: r-hub/cranlogs.app
Use shinyloadtest to see if app is fast enough 2. If not, use profvis to see what’s making it slow 3. Optimize a. Move work out of shiny (very often) b. Make code faster (very often) c. Use caching (sometimes) d. Use async (occasionally) 4. Repeat! • Don’t do work while the user is waiting • Don’t do the same work for every user
while the user is waiting. Eleven API requests to create the “Trending R Packages” table. Don’t do the same work for every user. Wasteful! Two rvest function calls performed for every row selection.
user activity for different types of content. 1. Shiny applications - records information about each visit and the length of that visit. 2. Static and rendered content - records information about each visit. github.com/sol-eng/connect-usage Code examples showing how to access the instrumentation data are in the User Activity recipes within the RStudio Connect API Cookbook.
it! or... This app isn’t getting visited… now what? • Set a Daily Visit goal • Set a Session Duration goal Send an alert when the app isn’t making the desired impact
Shiny Application means taking a different approach Sacrifice Shiny Runtime to Achieve: • Parameterized R Markdown • Scheduled email report delivery • Plumber REST API Custom Email Alert Message from Instrumentation Dashboard