Best practices for using modules across multiple shiny apps?

[philiporlando]

I'm part of a team that is trying to deploy several new shiny apps to our company's enterprise Posit connect server. The look and feel of each app is very similar, but the underlying data differs by geography. For example, one app focuses on the state of Oregon, while another focuses on California, but the same style of maps and plots need to be recycled across each app.

We are using the rhino framework for each of these apps, but we are trying to determine the best way to share the same shiny modules across multiple different apps. The third option within this Posit Community comment mentions the use of a standalone package of shiny modules that we can use to perform version control and share common functionality across different apps. We are interested in this approach but don't know how to implement it within the rhino framework.

Any feedback on this is greatly appreciated. Thanks in advance!

[natalieoshea]

I would love to get an answer to this question as well! Based on this section of the documentation, it seems theoretically possible to have multiple apps that share modules in a single rhino repository but I haven't been able to figure out the correct configuration settings to do so (perhaps by altering the legacy_entrypoint settings?). Ideally, I'd love to swap out main.R with top level files for each app (e.g. app1.r and app2.r) that mix-and-match the modules in the subdirectories of app. Is this possible?

[vedhav]

If you have a look at the .Rprofile file you'll notice that we set a static box.path using options(box.path = getwd()) which makes sure that you can source using box with relative reference from this path. I would imagine that you would have to modify this in each of the rhino app's .Rprofile file to set them to a common place where you intend to place all the modules or make it to the root so you can source all the modules from the root of the whole repo instead of individual rhino app's directory.

So, this is one way of having multiple rhino apps that share modules:

.
├── app_1
│   ├── app
│   │   ├── view
│   │   │   └── app_1_view.R
│   │   ├── logic
│   │   │   └── app_1_logic.R
│   │   ├── data
│   │   │   └── app_1_data.csv
│   │   └── main.R
│   ├── app.R
│   ├── renv.lock
│   ├── .Rprofile
├── app_2
│   ├── app
│   │   ├── view
│   │   │   └── app_2_sidebar.R
│   │   │   └── app_2_mainbar.R
│   │   ├── logic
│   │   │   └── app_2_logic.R
│   │   └── main.R
│   ├── app.R
│   ├── renv.lock
│   ├── .Rprofile
├── common_modules
│   ├── tables
│   │   ├── demographic_table.R
│   │   ├── safety_table.R
│   ├── graphs
│   │   ├── km_plot.R
│   │   ├── scatter_plot.R

Now, when you set the box path to the root of the directory in each of the .Rprofile you will be able to access the common modules too.
You can have a look at the multiple_rhino_apps repo that showcases this.

[vedhav]

This is not as ideal as you wanted, like having app1.R, app2.R etc. But I like this structure better because it needs a little tweaking and still retains the main rhino structure. But, I think with the help of legacy_entrypoint and custom box.path you can achieve what you proposed. However, I think it will be messy to distinguish between modules that are app-specific in that case (even having separate sub-directories will make things messy)
So, I recommend a structure where the rhino apps are well-isolated and can take common modules from a shared directory.

[jakubnowicki]

rhino currently does not support shared modules. The example provided by @vedhav should work, as it solves the main problem: the path where box looks for modules. But it is going to be hard to make it work in the deployed version, where you 1) might not control where the application files are stored and 2) it might collide with other applications. If you want to share modules between different applications, the best way will be to extract them into an R package.

[vedhav]

As Jakub mentioned it looks like the deployment with files from other/parent directory will be a challenge and the recommendation is once again to extract them into R package.

[vedhav]

I think creating symlinks can be one way to overcome this, haven't tested it though.

[natalieoshea]

Got it! Thank you both for your help on this. I've definitely made some initial efforts at moving shared logic into a separate package but ran into some roadblocks and hoped that maybe it would be possible to just leverage shared modules in a rhino framework... would love to see this implemented one day!