Sinatra: Up and Running

Chapter 3. A Peek Behind the Curtain

At this point you should be feeling fairly comfortable writing Sinatra applications. So far, we’ve focused primarily on the classic approach, where a single application exists in a single process. That’s only scratching the surface of Sinatra’s potential, however. Let’s take a deeper look at how Sinatra actually works. Once you understand what is going on backstage, it becomes significantly easier to take full advantage of the available API (or even extend it). To gain this understanding, we’ll dig into the source code and take a guided tour of what’s actually going on.

Note

Sinatra follows Semantic Versioning, which basically states that Sinatra will not break backwards compatibility unless the major version (the first number of the version) is increased. So, any application written for Sinatra 1.2.3 will still work with Sinatra 1.3.0. Semantic Versioning requires an official and complete API specification. For Sinatra, this happens to be the README, which you can find here: http://www.sinatrarb.com/intro. You can learn more about Semantic Versioning at http://semver.org/.

Application and Delegation

Let’s start with a quick experiment. We saw earlier in the book how parameters are passed into routes and extracted in the context of the route via the params hash; for example, in a simple login form we may find params[:username] and params[:password].

We mentioned previously that the various route definitions in a Sinatra app (get '/home', post '/login' ...