Shiny Developer Series - Episode 2 - Follow-up Thread - Colin Fay on `golem` and Effective Shiny Development Methods

Following up with questions from the Shiny Developer series here. If you missed the live webinar, you can view the recording at shinydevseries.com/ep2 :+1:

For videos, resources, and more information about the full series, check out the Shiny Developer Series Website


Some questions from the webinar:

Q - Is it hard to switch mid-production to golem if you started without it in the beginning?

Q - Do you use packrat or renv alongside golem when building a shiny app to version all packages used in the project?

Q - I have some issues with Out of Memory problems with my Shiny-App, any best practices suggestions?

2 Likes

Q Is it hard to switch mid-production to golem if you started without it in the beginning?

It's definitely not. If you think of a "classical" Shiny App, there is a ui.R, a server.R and maybe a globals.R. The twi first files can be put (almost) as is in {golem}'s functions inside R/app_ui.R & R/app_server.R. The globals.R is a files where you can find data and/or functions, so as {golem} is built on top of a package structure, you can put data and functions just as you would have done in any package.

1 Like

Q - Do you use packrat or renv alongside golem when building a shiny app to version all packages used in the project?

You can indeed use {packrat} or {renv} with {golem}. A golem is a Shiny App built on top of a package, so you can definitely use any classical tools for Shiny and for package management that you are used to use in production.

Q - I have some issues with Out of Memory problems with my Shiny-App, any best practices suggestions?

It's kind of hard to tell without having a deeper look into how you Shiny App is built and why you encounter these errors.

It can be linked to one dataset you're operating on being too large for your R session and in that case I would suggest backing your Shiny App with a database (SQL if you're working with tabular data, or maybe MongoDB if you're working with unstructured data).

It might also be linked to a mistake in the way reactive values / values in general are handled in the app. You can for example I recently found in an app I had to optimise a reactive implementation that created a lot of duplication, leading to the app asking for more memory than what was actually needed.

But if that's linked to handling one big object in the application, either choose a database backend, or work with tools for on-disk memory usage.

1 Like

Golem with all its helper functions looks great. As I slowly try to figure out how to pass things in and out of modules, I'd like to ask a question about the (I suppose) easy bits:

If I build an app within a package with Golem, what is the best way to load data in the app? I mean, the read_csv calls and such I would otherwise put in global.r or at the very beginning of the app.r file.

While there may be many options, I'd be particularly interested in the following two use cases:

  • when the data is part of the package itself (e.g. a demo to be used to showcase something about the package), it seems to be quite straightforward: a global.r in the inst/app/ subfolder, and from there relative path to the data inside the package. I don't see particular problems with this.

  • but when the data is on the host computer/server... how can someone who uses the package feed their own data into the app, or how do I pass it in the final call in the docker file when I deploy it? it can also be located in some predefined location respective the working directory... but still unsure what is the best way to go about it.