Appendix B — Deployment
If you want to share your app with the world, there are free options for each alternative. The free route I found for Dash has proven to be more complicated than the other two.
B.1 Shiny
Not a lot of trickery here; I got an shinyapps.io account and used the deployment service built into the RStudio IDE.
B.2 Dash
Plotly offers a Dash Enterprise service. However, if you want deploy a publicly-available app for free, you can deploy to Heroku.
The process is descibed in the Dash deployment documentation, but I found that I needed to implement a few workarounds to get things to work. Your mileage may vary.
The overall process is:
- Establish your Heroku account, once.
- Configure your Dash app, once per app.
- Create your app on Heroku, once per app.
- Git-push your app to Heroku, once per deployment.
B.2.1 Establish Heroku account
- Sign up at Heroku.
- Install the Heroku CLI.
The Heroku CLI is used to create your (Heroku) apps and deploy them.
From time to time, you will need to authenticate to Heroku from the terminal.
The easiest thing to do (from the terminal) is:
heroku login
This does not work for me, so (following this SO post) I use:
heroku login -i
Heroku asks for your email (account) and password. Because I use two-factor authentication with Heroku, I need to create a token to allow me to authenticate using the CLI:
- Create an authorization for Heroku CLI:
- Hit the “Create authorization” button.
- Provide a description, something like “Heroku CLI”.
- Provide an expiry duration, if you like.
Heroku will generate a token that you can use to log in from the command line.
😅
B.2.2 Configure Dash app
Following the Dash instructions, there’s a few things we need to to, once per app:
- create a local git repository
- use a Python virtual environment
- install
gunicorn
- adapt your app’s Python file
- create a
Procfile
in your app repo’s root directory.
Using git and creating a repository may be familiar to you already; if not, Happy Git with R is highly recommended.
To get started with Python virtual environments, see the Appendix: Field Guide to Python.
You will have to install “gunicorn” in your virtual environment, as Heroku uses this to serve Python apps. From the terminal:
pip install gunicorn
The next step is to define a server
variable in your app, as Heroko (gunicorn) will need to use it. In your app’s Python file, after you have defined app
:
# make `server` available to Heroku
= app.server server
Finally (at least for this section), we will need to tell Heroku how to use gunicorn to serve your app. In your repo’s root directory, create a file named Procfile
with a line like this:
web: gunicorn app-aggregate-local:server
Note:
app-aggregate-local
refers to the fileapp-aggregate-local.py
; use the name of your app file.server
refers to theserver
object inapp-aggregate-local.py
, the variable you just made available.
B.2.3 Create Heroku app
Once you have authenticated on the Heroku CLI, there’s a couple of steps to create the app on Heroku:
heroku create aggregate-local
Note: use the name for your app, rather than aggregate-local
.
This command does two things:
- creates the app at Heroku
- creates a git remote
B.2.4 Git-push Heroku app
When you’re ready to deploy, or redeploy, it’s a three-step process:
- Update your
requirements.txt
, so Heroku will know how to create the Python virtual environment. - Commit your changes to git, locally.
- Push your branch to Heroku.
From the terminal:
pip freeze > requirements.txt
Git-commit your changes, then:
git push heroku main
Or whatever your branch happens to be named.
All being well, your app should be deployed and operational. You can go to your Heroku apps dashboard to keep track of all of your deployed apps.
B.2.5 Miscellany
In the Dash instructions, there is a command they suggest running, after you have made you have made your first deployment:
From the terminal:
heroku ps:scale web=1
I have read this is not scrictly necessary, as it is setting the value to the default.
As well, the Dash instructions assume that you have one app per git repo.
If you want to have more than one app per repo, there’s a way. For each app in a given repo, you’ll need:
- a separate Procfile.
- a
PROCFILE
environment-variable for each Heroku app, specifying the location of itsProcfile
. - a separate Heroku git-remote.
I have not done this yet, myself.
B.2.6 References
B.3 Observable
At the Observable site, code is “deployed” once you hit the “Publish” button.
That said, there are some interesting possibilities to incorporate Observable into Quarto documents.