Sinatra is a Ruby framework. It helps you take your app and get it online, complete with a front-end. I’ve spent the past week making various Sinatra apps, and it’s been a lot of fun. My first was Are You Still Sad?, an emergency compliment site.
A Sinatra app has a few basic components. An app.rb file, a views directory, and a lib directory when needed.
The app.rb is like the app’s controller. It’s where the user’s input is taken and turned into an http request. For example, in the following gist,
get "/compliments" do is a route. The route is part of the address for your app. So this code will only work for specified-url/compliments. Leave off the compliments, or change it to anything else, and you’ll get a 404, page not found error. If you wanted something else to be valid, you’d have to make a separate route.
Your app.rb should also have some of the logic in it to make your app run. In fact, all your logic should be either in your app.rb, or in classes in your lib directory. In lines 9 and 11, I linked to my public directory, which contained a yaml file of all the compliments that can be pulled from, and a directory of all images. Then inside my route I create a new class, with an image and compliments selected from the data. The Compliment class was defined in my lib directory.
You’ll also note that in my app.rb, instead of requiring all the gems I need, I require Bundler. This links to my Gemfile. (As a side note, if you want to deploy to Heroku, the capitalization of your Gemfile is important. Capitalize only the first letter, or you’ll run into deployment issues!)
In the Gemfile, you first have to link to the source. Instead of using “https://rubygems.org”, you can technically use the
:rubygems symbol or “http://rubygems.org”. However, there are potential security issues with these, so you should use https!
Next you list out all your gems. If there’s something that you only want to use in development, you can create a group called development. Sinatra will know that these gems should only be used on your localhost, and when deploying it will ignore them! This lets you use gems like shotgun, which allows you to see changes without having to restart your local server each time you touch your code, without having to worry about it causing issues in production.
Then we get to the view. In this example we’re using erb, which stands for embedded ruby. It lets you include ruby in your HTML. This is amazing, because it lets you use variables and include all the ruby logic you can muster! Again, it’s best practices to keep your logic in your app.rb and lib directory when you can. There are two ways to use erb. Typing
<% code here %> will execute your ruby code and do whatever logic is written. However, typing
<%= code here %>, with the equal sign, will insert the return value into the html! This is how you make your site dynamic. You can call on your variables, and style them as you like with css in your public directory.
I had done a little work with static HTML sites, before, but now being able to combine Ruby logic with a front-end is wonderful.