ShinyProxy is one of the most popular alternatives to conventional Shiny hosting options (offered by RStudio). Especially when it comes to hosting multiple applications, apps other than Shiny, and built-in enterprise features, like authentication and authorization (find a recent review of Shiny hosting options here).

This pretty useful and sophisticated technology just got a whole lot better, thanks to the dedication and hard work of folks at Open Analytics: version 2.6.0 was recently announced. If you want the full release notes, head over to the ShinyProxy Download page. Otherwise, here are the highlights and a summary of my experience after demoing the new features. In the end, I give a brief update on the DigitalOcean 1-click app.

App recovery

The most exciting update is the App Recovery option. When you make changes to the ShinyProxy configuration or update ShinyProxy and its dependencies, you need to restart the ShinyProxy instance for the changes to take effect. Previously, this resulted in losing the currently running apps. This is the case no more!

The new feature allows you to change the configuration of ShinyProxy and restart without losing current running apps. This feature is not enabled by default, because it may cause incorrectly behaving applications. You can enable it by changing a few of the configuration options.

When enabled, the App Recovery feature will make sure apps (Docker containers that are running) do not stop when ShinyProxy restarts. After restart, ShinyProxy will look for these running apps in the container-backend and restore them into the memory of ShinyProxy.

Similar behaviour has existed for the ShinyProxy Operator (this needs a Kubernetes backend). The current change brings this feature to “less complex” deployments, such as a virtual server.

User interface

The new User Interface page of the documentation describes the layout for both the previous and the new functionality.

The “Stop instance” button stops the app, the “Restart instance” restarts it. By default, one user can only have access to a single instance of an app.

It is now possible to run multiple instances of an app. You can specify the number of max instances. In this case, the user will see a “Switch instance” button to switch among multiple instances.

These instances of the same app are fully isolated and are running in separate containers. The user can stop the apps using the popup after clicking the “Switch instance” button.

The “Report issue” opens a popup window where a user can report an issue to the administrator of the ShinyProxy server (see configuration).

Automatically reconnecting WebSockets

The user interface can now try to reconnect websocket based apps. This might be required when the internet connection is patchy and the connection drops from time to time. The default option is not to try to reconnect with the app. The other options are “Confirm” (ask the user first) or “Auto” (reconnect anyway).

ShinyProxy will start a restore procedure when reconnecting is enabled and the websocket connection of the apps get interrupted:

When ShinyProxy detects that the running application is a Shiny app, it uses the $socket.reconnect() function of the Shiny JavaScript API to restore the connection. For all other apps, ShinyProxy reloads the iframe displaying the app. The mechanism tries to restore the connection up to ten times. However, between every attempt, ShinyProxy waits for an increasing amount of time. That is, after the first attempt, it waits for two seconds, after the third for three second and so on. If the app cannot be restored after 10 seconds, ShinyProxy asks the user whether it should reload the complete page.

Spring expressions

Spring is the Java framework used by ShinyProxy and its underlying application called ContainerProxy. The Spring Expression Language (SpEL) allows determining the values of variables at runtime.

Previously, you had to hard code values in the app specification. In extreme cases, you had to compile ShinyProxy from source to allow certain requirements by 3rd party integrations (like authentication providers).

With this update, you can directly specify dynamic (i.e. user-specific) variables. E.g. the #{proxy.userId} expression will be by the user ID when starting the app. This can be used to mount user-specific directories and provide data persistence much easier. Another use case is to provide user-specific target paths.

There is a list of configuration options that support expressions. See what values are available during runtime. A separate section deals with authentication use cases, when properly identifying users is important for your applications.

1-click app updates

The DigitalOcean 1-click app was also updated to pack ShinyProxy 2.6.0. Apart from adding the new version of ShinyProxy and testing the machine image, there was only 1 more change. There is now a new /etc/shinyproxy/logs/ folder for logs which is configured so that ShinyProxy can write the logs to the folder.

Here is a quick video about the 1-click app deployment. The video also demonstrates the new app stop/restart features of ShinyProxy:

Follow this link if you want to test-drive the DigitalOcean 1-click app with ShinyProxy 2.6.0.

Conclusions

ShinyProxy continues to be the top choice for hosting Shiny apps for a reason. The new features are either directly benefit the users or make developers' life much easier when integrating with other tools.

We can't wait to see what will be in 2.7.0 (or maybe 3.0.0?). In the meantime, enjoy 2.6.0. And let me know if you have a particular topic related or unrelated to ShinyProxy that you'd like to learn more about.

Further reading

• Release notes for ShinyProxy 2.6.0
• Release announcement
• App recovery
• Spring expressions