Sinatra who???

As the title implies, when I first saw the word Sinatra appear on my course calendar, I did a double take. It seemed to be a bit of an odd name for a software to have, but who am I to question. Apparently the name derives from the American singer, Frank Sinatra.

<Frank Sinatra (chairman of the board) for having so much class he deserves a web-framework named after him>

Enough with the rambling! Let’s dive and learn What Sinatra is, Why and How it could be useful to building a full web-application.


Sinatra is a DSL, a Domain Specific Language. It is a language that’s written to solve some issues or concerns with a specific domain/language. DSL is specific to a particular language. One thing to note here is that Sinatra is specific to the Ruby language and it can solve some of the issues within the language. Remember that Sinatra is not a language!

WHY do we use SINATRA?

Sinatra is a great library to learn when you’re entering full stack web-development. In order for us to learn Rails, using Sinatra will act as training wheels for Rails. Although it is not quite popular due to its old age and simpler library, it will come in handy when the concepts Rails abstract the Sinatra concepts.It is great when you want to create a quick web application in Ruby.

How do we use SINATRA?

Sinatra can do a lot of things but it is great for learning the basics of HTTP and routing. It can create routes and render different pages based on those routes. Before I share more usages of Sinatra, let’s quickly review some of the keywords.

  1. Requests & Response Flows: Types of requests being made in the application and how we (developers) respond. Both Sinatra and Rails process the response.
  2. Client vs Server: Client is the user, the one who’s requesting and the server is the application, sending the response.
  3. Routing: Routes are the backbone of an application. They guide how clients will navigate the actions we define for your application. Sinatra is quite flexible with routing! Here are some
  4. HTTP Methods: Correspond to Create Read Update and Delete operations. (CRUD)

GET- Requesting data.
Client: “Hey get me something! Show me a lists of posts/comments!”

POST- Creating data.
Client: “Here’s my comment/photo/post!” Server: “Alrighty, I’ll take care of your added data and add it to the database.”

PATCH- Modifying a part of the data, Partially changing data.
Client: “Change my nickname to something else, but leave my bio!”

PUT- Take the entire record and update the entire record.
Client: *no example provided due to the lacking usage of this method*

DELETE- Delete data
Client: “Delete this ugly selfie! I don’t want to see it on my post anymore!”

HOW does All of this Come Along?

Confused Lady Meme in the Honor of This Confusing Phase

We create a new class Application and then inherit from Sinatra::Base. The Controllers will define our routes and behave like a middleman between models and views. We will ask the Controller, “Hey Model, You need to grab ‘this’ and store it!” One thing to note is that a View and model should never directly communicate!!! View should never directly perform data base queries!

class ApplicationController < Sinatra::Base get '/' do 
"Frank Sinatra was here."

Start spreading the news of this Classy web-development dressed in a DSL, because I want to be a part of it…New York, New York!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store