After covering the most important issues regarding the programming of a Shiny application, it is now necessary to introduce the different possibilities of fulfilling the main purpose of developing a Shiny application, that is, exhibiting it.
In this chapter, we will look at the different ways of sharing an application, that is, from simply passing the code files to setting up a web address to make it accessible to anyone capable of connecting to it.
In this sense, it is important to keep in mind that in the majority of cases, it will be intended to make these applications accessible to everyone, regardless of their programming skills or the software they have installed on their computers. Although this might sound trivial or obvious, doing this optimally implies that certain specific knowledge is required to configure the applications correctly.
Once the application is ready, there are mainly four ways of sharing it as follows:
- Passing the whole code: This is as easy as zipping the application and sending it over the Internet. This is naturally one of the worst alternatives and is only sensible, for instance, to share the application with a colleague or co-worker. In many cases, it is not even the best alternative, as using version control is definitely better. In this case, it will be necessary that the person who receives these files has all the corresponding software (R and RStudio, at least) installed and all the required packages along with a certain expertise in R in order to reproduce the application and run it locally.
- runGist/runGitHub/runUrl: This Shiny package provides certain alternatives to run applications whose files are hosted on the Internet locally, by passing either
gist, a GitHub repository directory, or a URL that points to a compressed file (.tar.gz,.tar,and.zipextensions are accepted). Although this is definitely better in terms of sharing simplicity than the previous alternative, they are essentially the same. - shinyapps.io: Under http://www.shinyapps.io/, RStudio provides a hosting service especially prepared for Shiny applications. Its main advantage relies on the simplicity to manage them; uploading applications from your local machine will take no longer than 5 minutes. Apart from this, it provides a very intuitive and friendly GUI to administrate users, permissions, and so on. Probably, its main drawback is that the free version is limited (in terms of hours of service, storage, and so on) and that the developer has naturally no access to the configuration options of the server that is hosting the application. From the end user side, it is only needed that they have a compatible web browser.
- Own server: Hosting applications on your own server is also a possibility. In this case, the end user requirements are the same as in the case of shinyapps.io. In comparison, hosting applications on your own server is an advantage in the sense that the open version has no time restrictions, and for advanced users, this can provide some extra customizing possibilities. However, naturally, its configuration is entirely manual. The paid version offers some considerable extra features as well.
In the following, the details of each of the alternatives presented will be given, except for the first one, which is actually something widely known by every Internet user.
These three functions provided by Shiny basically do the same. In fact, runGist() and runGitHub() are mere wrappers of runUrl(). They basically build the URL based on GitHub's standard taxonomy and call runUrl(). All these functions download all the files to a temporary folder on the local computer and execute them on the end user's side. Of course, if the application requires any file that is not included in the repository, it must be on the user's side. If an application calls a library and it is not on the end user's side, R will throw an error.
Both runGist() and runGitHub() point to a repository in GitHub. The main difference between them is that the first one is not necessarily associated to a user while the second one does. Apart from this, the gist repositories are identified with ID while the GitHub repositories have a name associated to them. For this reason, runGitHub() expects both username and repository name. The following is an example of both functions running the same application; one is hosted in a gist repository and the other, under my personal GitHub repository:
runGist("1867aa4a401d9d1a9239") runGitHub("Dashboard","nivangio")