Local/Deployed Environment Variable Switching

[simon121]

shinyapps doesn't allow you to specify dashboard-specific environment variables from the web interface. Instead, users must define a .Renviron file locally and ensure this is deployed with the app so that you can invoke Sys.getenv() within your Shiny app to call on these vars.

This is problematic for a number of reasons with regards to development and production environments because developers must remember to switch between devel/prod settings when testing code between local and deployed.

I was wondering what current 'best practice' is with regards to handling env vars between devel/prod (in this case, prod is a shinyapps deployment). Is there some sort of env var switching that can occur in-script so that people don't have to remember to switch up variables?

For example (pseudo code):

if (working_locally = TRUE) {

pool <- dbPool(odbc::odbc(),
               Driver       = Sys.getenv('DEVEL_DB_DRIVER'),
               Server       = Sys.getenv('DEVEL_DB_SERVER'),
               UID          = Sys.getenv('WH_USER'),
               PWD          = Sys.getenv('WH_PW'),
               Warehouse    = Sys.getenv('DEVEL_WH'),
               Database     = Sys.getenv('DEVEL_DB'))


} 
else {

pool <- dbPool(odbc::odbc(),
               Driver       = Sys.getenv('PROD_DB_DRIVER'),
               Server       = Sys.getenv('PROD_DB_SERVER'),
               UID          = Sys.getenv('WH_USER'),
               PWD          = Sys.getenv('WH_PW'),
               Warehouse    = Sys.getenv('PROD_WH'),
               Database     = Sys.getenv('PROD_DB'))

}

[andresrcs]

They recommend using the config package for this kind of scenarios

Chapter 3 Applications | shinyapps.io user guide

[nirgrahamuk]

Why put the DB_DRIVER in differently named environment variables that would require you to switch in the manner you showed ?

If you had environment variable called simply DB_DRIVER in both environments but on development the variable had the content of the development driver and in production it had that content then no internal app logic would be required as the config would come from the environment. (I.e. how it is with the WH_USER in your example )

[simon121]

I'm running a very hacky local development set up. I'm on an M1 Macbook Pro and Snowflake don't provide native arm64 drivers. I've therefore had to install x86_64 Homebrew and emulate RStudio etc. etc. in Rosetta. The easiest way to get the Snowflake driver to work is simply to point directly at the driver, rather than try and create a DSN within my cobbled together x86/64. When deployed on Shinyapps, simply calling the driver "Snowflake" will allow RStudio's Professional drivers to know what to do.

I don't understand your second paragraph. We have two different databases - ANALYTICS_DEV and ANALYTICS_PROD. Shinyapps.io doesn't let you specify vars within the web dashboard, so how will my Shiny app know to use ANALYTICS_PROD when it's deployed, using the same .Renviron file? Ordinarily if you're deploying a web-based app via AWS or Azure, you can save env vars to whatever instance(s) you've spun up to serve your app - there's no need to package up an .env file and pass that with your app deployment. The .env stays local and the vars are encrypted on the host side (this really ought to be how shinyapps works, in my opinion.)

Am I missing something here? Although the username/password/compute warehouse are the same, the database and driver are both different between the two environments, and I thus need a way to switch between the two automatically, if possible.

[simon121]

Thank you I searched high and low on Google/SO for an answer to this and config just didn't come up for me, I'm not sure why. I'll implement this today. Thanks for the heads up.