Best practices for multiple Shiny apps
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?
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?
@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