Deploying Rails API to Heroku
An exercise in “What the #&$% am I missing now?”
This first image is how I felt setting off to deploy my Rails API to Heroku. My bootcamp cohort full of whispers of Heroku not enjoying different parts of code, meant that I approached it as though I was about to enter a hostile warzone. I had my local development API and frontend set up and ready to go so it was time to get out there and do it.
What is Heroku?
Heroku is a SaaS platform that lets you deploy, run and manage applications written in Ruby, Node.js, Java, Python, Clojure, Scala, Go and PHP. As with most things in life these days the more functionality the more the cost, but there are student/hobbiest/free packages with enough oomph to get a fledgling proof of concept out to the world. Other hosting packages also exist.
The documentation and user guides for Heroku are incredibly clear and their devcenter is well laid out and easy to find what you need. As this blog post is focussed on Rails API the snippets will come from the Rails section of the Ruby language support. The guide is here.
Where to start
The local setup elements include setting up the Heroku Command Line Interface — the details are in this article here. Dependant on your OS it may be a little tricky, but as a WSL user it was fine and clearly signposted where to go. Create an account and login via the Heroku CLI by typing heroku login it will then automagically navigate you to the Heroku login page and sign you in.
Once Heroku CLI is in place the next step is to prepare your API database, the default for most Rails apps is sqlite3 however this doesn’t play well with Heroku, one of those aforementioned whispers, so we need to convert the database to Postgresql if we haven’t set up the repo with the definition of --database=postgresql this is relatively straight forward if you have postgresql already installed on your system, if not there is a guide for it here, we need to go to the gem file and remove gem sqlite3 and replace with gem pg once this is done run bundle install to lock in the updated gemfile.lock and we are almost off!
A quick double check of congfig\database.yml to ensure the adapter is pointing at postgresql (note the sql at the end) otherwise it won’t work!
There are a couple more steps in the Rails guide to set up, as we already have an existing repo ready for deployment we are going to skip ahead in the guide, to the section helpfully titled…
Deploy the Application to Heroku
In the Rails app’s root directory we will use the Heroku CLI to create an app on Heroku: heroku create this creates an imaginatively named app on Heroku (which we can edit later if desired, I was quite enamoured of my glimmering-fish-04512 random name so I contemplated keeping it and renaming the app!)
Running the create automatically adds the remote to Heroku — we can verify this with git config --list --local | grep heroku which should show the new remote pointing to our URL
All there? Still following along? The scary part — deploy the code. git push heroku main (replace main with whatever branch you are pushing e.g. master) These four little words which will shape the future of your next few hours/days/weeks the code will be fired across on the new heroku remote and you will hopefully receive a deployment successful message.
There are a couple of extra steps once it’s deployed, the key one being your development LOCAL database doesn’t get transferred with the deployment! We need to run heroku run rails db:migrate db:seed this will run our database migration files and seed them, we just need to include heroku run before any of our normal rails actions such as the console heroku run rails c to access it, this comes in very handy when debugging if/when things go wrong.
Code deployed? Or Debug time
Hopefully your code deployed ok, and you can visit your application on Heroku, but what you may see is:
This isn’t a bad thing, it is running a the app at your-heroku-app.heroku.com/ if / isn’t defined as a route in your code it will error. Send it to one of your public routes e.g. /hamsters and you will be able to see the render from return, normally a JSON with your seeded data for an API response.
However all may not be well in the kingdom of Denmark, or your app and you receive nothing, check the status from the CLI with heroku ps this should show whether it is up and running or crashed, we can also use the command heroku logs --tail (for live logs) as pointed to by the error message in the browser error page, which will show what has caused the error however it’s not the easiest to read. This is where the heroku run rails c comes in, we can use this to get an easier to read Rails error message which will tell us what parts of our code aren’t being read as intended. We can then rectify the error, commit to git, and then push it back to Heroku. If there is more than one error, it will be a case of systematically going through correcting the errors until a stable build is created.
Deployed, running, stable
Not a political message, but the app should now be up and running and not crashing. Hooray.
Inevitably there will be more issues that come as the code develops and becomes more nuanced, fortunately I haven’t come across them, if I do I will update with how to debug them. The devcenter has extensive error-code support (here) so it will be a case of working through these.