search

ThinkR-open / golem

A Framework for Building Robust Shiny Apps
https://thinkr-open.github.io/golem/
Other
914 stars 133 forks source link

Best practices for multiple Shiny apps #139

Open jonmcalder opened 5 years ago

jonmcalder commented 5 years ago

For standalone Shiny apps, and especially for large Shiny apps, it usually seems to make sense to stick to one R pkg for each app.

Yet for smaller apps and/or apps that share common resources and functionality, I believe one can sometimes make a case for developing multiple apps within the same package. Obviously shared code / pkg infrastructure should be developed as modules that can be shared across these apps, and possibly even refactored out into a separate infrastructure package where this makes sense.

However, this (best) practice - making use of modules to eliminate repetitive infrastructure or boilerplate code - reduces the amount of code required for each of the individual apps. So it doesn't then really seem sensible to require that each (small) app be housed in a separate package, especially if they have related purposes and are going to be distributed / deployed together.

What are the best practices for approaching development of multiple applications within the same package?

What then are the implications for deployment via docker?

nelato commented 3 years ago

Hi,

this is a great topic and thank you for starting this discussion!
2 years after, do you have any recommendations or literature to share about what the best practice is for the development of multiple applications within the same (golem) package?

ashleyasmus commented 2 years ago

@nelato and @jonmcalder did either of you figure something out for this? we are running into this exact issue for a <small, simple> app we'd like to translate into the golem framework, then create multiple apps that share the same code/infra. https://github.com/Metropolitan-Council/covid-poops