Do you like the interactivity of Shiny apps? Do you also like the modularity and unit testing of R packages? Check out this small example to get the best of both worlds.

It’s a Shiny app!

The customary app.R is in the root directory, so you can launch the project as a Shiny app on a server as is. No package installation is required. Instead, devtools::load_all() in app.R automatically loads all the required R scripts and data files.

It’s a package!

Since app.R is listed in .Rbuildignore, you can install the package as is.

install_github("wlandau/appPackage")

Then, you can run the Shiny app locally.

library(appPackage)
my_app()

But what if my app uses compiled code?

Follow the CRAN directions to build your package on top of C, Fortran, or whatever compiled language you’re using. Then, all you need is an app.R that installs the package on the server and then launches your app with a function call. For this example, the server-side app.R would look like this.

install_github("wlandau/appPackage")
library(appPackage)
my_app()

Here, feel free to discard the app.R inside the package and remove the app.R listing from .Rbuildignore.

What of my project gets too big and messy?

Overambitious projects tend to get bloated, cluttered, and slow, especially when substance and interactivity fall under the same roof. If you do serious computation behind the scenes in xyzShinyApp, you could encapsulate the hidden core functionality in a separate package: say, xyzEngine. I used this exact approach in my dissertation project. Package fbseq processes user input and Monte Carlo output, and fbseqCUDA actually fits the model given an already-parsed set of instructions.