Part 4 of the video tutorial picks up here:
The whole reason we started building Redwood was to make full-stack web apps easier to build and deploy on the Jamstack. You've seen what building a Redwood app is like, how about we try deploying one?
Before we continue, make sure your app is fully committed and pushed to GitHub, GitLab, or Bitbucket. We're going to link Netlify directly to our git repo so that a simple push to
master will re-deploy our site. If you haven't worked on the Jamstack yet you're in for a pleasant surprise!
# The Database
We'll need a database somewhere on the internet to store our data. We've been using SQLite locally, but that's a file-based store meant for single-user. SQLite isn't really suited for the kind of connection and concurrency requirements a production website will require. For this part of this tutorial, we will use Postgres. (Prisma currently supports SQLite, Postgres and MySQL.) Don't worry if you aren't familiar with Postgres, Prisma will do all the heavy lifting. We just need to get a database available to the outside world so it can be accessed by our app.
If you'd like to develop locally with Postgres, see the Local Postgres Setup guide.
For now, you need to set up your own database, but we are working with various infrastructure providers to make this process simpler and more Jamstacky. Stay tuned for improvements in that regard!
There are several hosting providers where you can quickly start up a Postgres instance:
We're going to go with Heroku for now because it's a) free and b) easier to get started from scratch than AWS.
Head over to Heroku and create an account or log in. Then click that Create a new app button:
Give it a name like "redwoodblog" if it's available. Go to the Resources tab and then click Find more add-ons in the Add-ons section:
And scroll down to Heroku Postgres:
Click that and then on the detail page that comes up click the Install Heroku Postgres button that top right. On the next screen tell it you want to connect it to the app you just created, then click Provision add-on:
You'll be returned to your app's detail page. You should be on the Resources tab and see the Heroku Postgres add-on ready to go:
Click the Heroku Postgres link to get to the detail page, then the Settings tab and finally the View Credentials... button. We did all the steps above so that we could copy the URI listed at the bottom:
It will be really long and scroll off the right side of the page so make sure you copy the whole thing!
Now we're going to create a Netlify account if you don't have one already. Once you've signed up and verified your email done just click the New site from Git button at the upper right:
Now just authorize Netlify to connect to your git hosting provider and find your repo. When the deploy settings come up you can leave everything as the defaults and click Deploy site.
Netlify will start building your app (click the Deploying your site link to watch the logs) and it will say "Site is live", but nothing will work. Why? We haven't told it where to find our database yet.
Go back to the main site page and then to Settings at the top, and then Build & Deploy > Environment. Click Edit Variables and this is where we'll paste the database connection URI we got from Heroku (note the Key is "DATABASE_URL"). After pasting the value, append
?connection_limit=1 to the end. The URI will have the following format:
When configuring a database, you'll want to append
?connection_limit=1to the URI. This is recommended by Prisma when working with relational databases in a Serverless context.
Add one more environment variable,
BINARY_TARGET set to the value
rhel-openssl-1.0.x This is for Prisma to know which client libraries it needs, in this case so that it can run on AWS Lambda:
Make sure to click the Save button. Now go over to the Deploys tab in the top nav and open the Trigger deploy dropdown on the right, then finally choose Deploy site:
With a little luck (and SCIENCE) it will complete successfully! You can click the Preview button at the top of the deploy log page, or go back and click the URL of your Netlify site towards the top:
Did it work? If you see "Empty" under the About and Contact links then it did! Yay! You're seeing "Empty" because you don't have any posts in your brand new production database so head to
/admin/posts and create a couple, then go back to the homepage to see them.
If you view a deploy via the Preview button notice that the URL contains a hash of the latest commit. Netlify will create one of these for every push to
masterbut will only ever show this exact commit, so if you deploy again and refresh you won't see any changes. The real URL for your site (the one you get from your site's homepage in Netlify) will show the latest deploy. See branch deploys below for more info.
If the deploy failed, check the log output in Netlify and see if you can make sense of the error. If the deploy was successful but the site doesn't come up, try opening the web inspector and look for errors. Are you sure you pasted the entire Postgres connection string correctly? If you're really, really stuck head over to the Redwood Community and ask for help.
# Branch Deploys
Another neat feature of Netlify is Branch Deploys. When you create a branch and push it up to your repo, Netlify will build that branch at a unique URL so that you can test your changes, leaving the main site alone. Once your branch is merged to
master then a deploy at your main site will run and your changes will show to the world. To enable Branch Deploys go to Settings > Continuous Deployment and under the Deploy contexts section click Edit settings and change Branch deploys to "All". You can also enable Deploy previews which will create them for any pull requests against your repo.
You also have the ability to "lock" the
masterbranch so that deploys do not automatically occur on every push—you need to manually tell Netlify to deploy the latest, either by going to the site or using the Netlify CLI.
# A Note About DB Connections
In this tutorial, your lambda functions will be connecting directly to the Postgres database. Because Postgres has a limited number of concurrent connections it will accept, this does not scale very well. The proper solution is to put a connection pooling service in front of Postgres and connect to that from your lambda functions. To learn how to do that, see the Connection Pooling guide.
We are working on making this process much easier, but keep it in mind before you deploy a Redwood app to production and announce it to the world.