A Live Web Application
Use web framework Sinatra to develop a web-based palindrome detector and learn to create dynamic content using embedded Ruby (ERB) and use Ruby-based site layout along the way.
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this final chapter, we reach the culmination of this Ruby tutorial: a dynamic web application. Our app will put the custom Ruby gem developed in Chapter 8 to good use through the development of a web-based palindrome detector. Along the way, we’ll learn how to create dynamic content using embedded Ruby (ERB).
Detecting palindromes from the Web requires using a back-end web application to handle form submission, and our tool of choice is Sinatra, the micro-framework we met in Section 1.5 and applied further in Section 5.2. Although simple, Sinatra is not a toy—it’s a production-ready web framework used by companies like Stripe, Apple, and Disney.1
Our palindrome app will also feature two other pages—Home and About— which will give us an opportunity to learn how to use a Ruby-based site layout. As part of this, we’ll apply and extend the work in Chapter 8 to write automated tests for our app.
Finally, as in Section 1.5, our final step will be to deploy our palindrome app to the live Web. We’ll end with pointers to further resources for Ruby, Sinatra, and other topics like JavaScript and Ruby on Rails.
10.1 Setup
Our first step is to set up our app as a proof-of-concept and deploy it to production. We’ll start by making a directory for it:
The app itself will live in the file app.rb, and we’ll also need a Gemfile:
In addition to the sinatra and puma gems, we’ll also include rerun, which will let us see changes to the app without quitting and restarting the local server, as shown in Listing 10.1.
Listing 10.1: Defining the gems for our app.
Gemfile
source 'https://rubygems.org' ruby '3.1.1' # Change this line if you're using a different Ruby version. gem 'sinatra', '2.2.0' gem 'puma', '5.6.4' gem 'rerun', '0.13.1'
We can then install the gems using bundle install:
To get started with the app itself, let’s write “hello, world!”, as shown in Listing 10.2.
Listing 10.2: Getting to “hello”
app.rb
require 'sinatra' get '/' do 'hello, world!' end
To run the app, I recommend opening a new terminal tab and then using the rerun command, as shown in Listing 10.3.
Listing 10.3: Using rerun to run a Sinatra app.
$ bundle exec rerun app.rb 12:10:10 [rerun] Palindrome_app launched 12:10:10 [rerun] Rerun (79556) running Palindrome_app (79575) == Sinatra has taken the stage on 4567 for development Listening on localhost:4567, CTRL+C to stop
As with running a Sinatra app using ruby (e.g., Listing 1.9), Listing 10.3 runs the app on a local port, where the exact number can be read in the log output. The exact results may be system-dependent, but on my system the log says something like “Sinatra has taken the stage on 4567” (the highlighted line in Listing 10.3), meaning that the site can be accessed at localhost:4567. The result appears in Figure 10.1.
)
Figure 10.1: Our initial app running with rerun.
Now let’s see what happens if we make a change to our app, as shown in Listing 10.4.
Listing 10.4: Time to say “goodbye”.
app.rb
require 'sinatra' get '/' do 'goodbye, world!' end
In Section 5.2, we had to quit and restart the server in order to see changes to the app, but thanks to the rerun in Listing 10.3, the app is updated automatically (though we still do have to refresh the browser by hand). The result should look something like Figure 10.2.
)
Figure 10.2: An auto-updated Sinatra app.
Finally, following our practice to deploy early and often, we’ll put our project under version control with Git in preparation for deploying to Heroku:
As in Section 1.5.1, we need to add a configuration file for Heroku’s sake:
The contents are shown in Listing 10.5 (which apart from the app name is identical to Listing 1.12).
Listing 10.5: The configuration file for production deployment.
palindrome_app/config.ru
require './app' run Sinatra::Application
At this point, we’re ready to deploy (the first line may or may not be necessary, but it does no harm to include it):
The result is a working app in production, as seen in Figure 10.3.
)
Figure 10.3: Our initial app in production.
10.1.1 Exercises
Change the app back to read “hello, world!”, and deploy the update to production. Note: The second time you deploy, you can leave off main, and just type git push heroku.