JumpCast: Get Started with Sinatra

Jess: I’m here with John Barton, who is one of the founders of Goodfil.ms. He’s here to talk to us about Sinatra today. What can you tell us about Sinatra?

John: There’s not a lot to tell about it, but it’s essentially just really lightweight web framework written in Ruby, making web apps really, really easy.

Jess: I understand Sinatra doesn’t use the typical MVC pattern that other frameworks use. What does it focus on instead?

John: It doesn’t really focus on much at all. It’s really, really lightweight. Most Ruby programs, if you’re familiar with the Rails framework, which is the opinionated software framework for web app development, and Sinatra is almost the complete opposite of that, in that it does the smallest amount of work to help you publish webpages without getting in the way with anything else. There is a bit of a drawback to that, in that you can write very unmaintainable, terrible apps because it doesn’t provide that structure for you, but it does give you the freedom to
do a lot of things that are kind of difficult to do in large MVC frameworks.

Jess: So obviously, Sinatra is quite small in size, in terms of lines of code. Why exactly is that?

John: Well, the only reason it’s so small is because it is a really focused framework. It doesn’t really do that much. It’s actually a lot smaller than it used to be when I first started using it, because over time people have honed in on what it’s for and cut it down to the bare minimum you need to build little web apps, though if you find that there’s things you need to do and there’s nothing in there that can help, there’s actually a lot of standard packages to install as well, like Sinatra-contrib is the main gem that includes things like cookie handling, so it might help us for that, and a few Rails-style view templates so that you can write cleaner HTML code for your app.

Jess: Cool. So what exactly would you use Sinatra for, then?

John: There are two main things I’m really fond of using it for. The first is for small, focused web services. If you’re building an authentication service, you’ve got a couple of websites and you need them all to talk to
the one authentication system or file processing system, is by having a really, really small framework with a small code base that does a very dedicated task, it makes for much cleaner code than if you have a larger framework involved. You’ve got to wade through a lot more code to find the core work that the system is actually doing.

The second thing that I’m really fond of is for doing MVPs of web applications. I know it’s fairly popular for people to use WordPress to spin off a couple of landing pages and an email signup form and to try out some marketing ideas, whereas I much prefer to use Sinatra for that, because then if it proves itself, it’s actually really easy to evolve a
Sinatra application into a larger application using other Ruby frameworks without losing all the work that you’ve already put in.

Jess: What skills do you need to use Sinatra then?

John: The two main skills you’ll need to be able to use Sinatra in any meaningful way is a little bit of Ruby knowledge and a little of HTML knowledge. Because it’s such a clean and easy-to-use framework, you don’t
actually have to have very advanced skills to work with it. It’s actually, I find, a really good environment for teaching people how to build web apps because it’s got the smallest representation of the idea of. “This is how
you hit a webpage and this is what comes back out the other side” and then you can learn more skills using the tool and then go up to one of the big frameworks later on.

Jess: What are some examples of Sinatra in the wild, then?

John: There are lots of examples you won’t have ever heard of, because a lot of people are just using it for hobby projects. And the other reason, GitHub are a huge user of Sinatra. Their main website has something like 22 Sinatra applications all wired together. Because it’s a small framework, it’s really good for isolating really small blocks, so it’s a really popular tool for internal tools, if you want to build an administration system, or a little web service to handle something on an API. It’s often behind the scenes so you’re not really seeing it.

Jess: Cool. Do you have any examples of Sinatra that you’ve put together?

John: Yeah, I was thinking I could show everyone how to build a little marketing page with maybe some kind of email registration form, if you’ve got something in private beta you want to get out to the public.

Jess: That’s great. Let’s check that out.

John: OK. Let’s look at this example of Sinatra. I’ve installed Sinatra using Bundler here, so I’m just going to fire up our server by running “bundle exec ruby app.rb”. So this is running now, and so let’s have a look at what we’ve got. It’s a little marketing landing page here that randomly generates a keyword for describing our product and allows you to register with an email address. And we submit that, that gets saved somewhere and we show a nice little “thank you” message. So let’s look at the code that makes that happen. Our Sinatra app has this file here that defines the actual Sinatra code itself, and a folder here for our HTML view templates.

Looking in here we’ve got a little bit of boilerplate up top, just to set up the Sinatra environment, and then the Sinatra DSL for defining our two end points. The first being the index page, there is that slash for the server, and the other which is where the form parses its data to. All we’re doing here is telling Sinatra to listen for a standard get request backslash, pick a keyword at random, and render out our view template. We load up index.erb. This is our view template, which you can see here is embedding our randomly chosen keyword, and then also saving that in the
form so that we know when people sign up which keyword they’re responding to.

You’ll notice you won’t see the HTML tag or any of the CSS in this file. It’s because Sinatra will automatically look for a file called layout.erb and will wrap the contents of the template with whatever’s in the layout file, so you can see here we’re defining all of our standard document stuff and then down here, where the yield keyword is, is where the content from the template we’ve requested will be rendered out. So that’s how we show our content in Sinatra, but let’s have a look at how we access data from the form. Everything that comes in from the form, every HTML post data parameter is put in the params hash here, so you can see we’re assigning a variable email and keyword, and we’re pulling that out of email and keyword here and here.

If we look again at the index, you can see the form inputs, names, keyword, and email. This is automatically generated from your markup. Then we’re doing some boring Ruby here, just to write out our email, keyword, and the current time of our file, and rendering the template again, so we should look at our CSV and see the email address we signed up before. This is a pretty naive approach to running an A/B test on a private beta signup form, but hopefully you can use this as a template to get started with Sinatra.

Thanks very much for watching. If you’d like to get hands on with Sinatra, make sure you check out our book Jump Start Sinatra, by Darren Jones.