Both Sinatra and Rails are Ruby Frameworks, which let you get your Ruby apps online. But even though they serve the same purpose, they go about it very differently.
Let’s say you have an ideal image in your mind of what you want your framework to be. A dream house, if you will, with each room being a different directory.
Using Sinatra, you’d start with the raw ingredients and build up your app from the ground up. As such, you’d have only what you need and probably not much more. Anything else that you want to add on you’d need to build yourself. Things are a little more compact.
Sinatra only has a couple of “rooms” in its house, but Rails is a bit more robust. Instead of building a house from scratch, it’s more like you’re inheriting a huge mansion. There’s a lot there for you to explore. Some rooms you may not need to go into at all. Others you may only want to use only parts of. Generally, though, it seems like if something could be in a different room, it will be.
To explore the difference between the two frameworks, let’s think of the front door as the http request from the client, the foyer as where the routes are checked, the living room as where instructions are held for each route, the kitchen as the models, the dining room as the database, and the bedroom as the views.
Going room by room, both Sinatra and Rails would start with the user sending an http request from the browser, and the route being checked against a list of possible routes. This is our equivalent of going through the front door. In Sinatra, the http request would find itself straight in the living room. In Rails, it would step through the front door and into a foyer – a dedicated routes.rb file. Only after the routes were checked and deemed valid would it be allowed into the living room.
The living room is the heart of the app in both cases. In Sinatra it would be the app.rb, which has multiple purposes. In Rails it would be the controller, which has instructions for what should be done when. Sinatra’s app.rb is like a foyer and living room rolled into one. If you wanted to, you could have your Sinatra app be a one-room apartment with a pull-out couch by also putting your views in your app.rb – type a string instead of directing to an erb or haml document and that will be what’s displayed on the page.
Rails, not being one to skimp on space, after the controller checks the instructions it follows them to the kitchen and dining room, pulling data from the database through the models. While models and databases can be used in Sinatra, it’s not required. It’s entirely up to you as you build your app. But in Rails, the rooms at least are standard when you move in.
Once the data is received, it’s returned to the controller and assigned to variables. This is then passed along to the necessary views. Both Sinatra and Rails have views, but as mentioned Rails requires these to be in another directory. The view renders the html that will be passed to the browser, and both Sinatra and Rails pass this string of html back through the controller, and back outside to the client to render in the browser.