Sometimes you may want to set up sessions "outside" of the Sinatra app, such as in the config. In that case, you can still set up session based protection by passing the :session option:. There are three predefined environments : "development" , "production" and "test". The default value is "development". In the "production" and "test" environments, templates are cached by default. You can use predefined methods: development? Error handlers run within the same context as routes and before filters, which means you get all the goodies it has to offer, like haml , erb , halt , etc.
The error handler is invoked any time an exception is raised from a route block or a filter. The exception object can be obtained from the sinatra. Sinatra rides on Rack , a minimal standard interface for Ruby web frameworks. Sinatra makes building Rack middleware pipelines a cinch via a top-level use method:.
The semantics of use are identical to those defined for the Rack::Builder DSL most frequently used from rackup files. Rack is distributed with a variety of standard middleware for logging, debugging, URL routing, authentication, and session handling. Sinatra uses many of these components automatically based on configuration so you typically don't have to use them explicitly.
You can find useful middleware in rack , rack-contrib , or in the Rack wiki. Sinatra tests can be written using any Rack-based testing library or framework. Rack::Test is recommended:. Note: If you are using Sinatra in the modular style, replace Sinatra::Application above with the class name of your app. Defining your app at the top-level works well for micro-apps but has considerable drawbacks when building reusable components such as Rack middleware, Rails metal, simple libraries with a server component, or even Sinatra extensions.
The top-level assumes a micro-app style configuration e. That's where Sinatra::Base comes into play:. The methods available to Sinatra::Base subclasses are exactly the same as those available via the top-level DSL.
Most top-level apps can be converted to Sinatra::Base components with two modifications:. Sinatra::Base is a blank slate. Most options are disabled by default, including the built-in server. See Configuring Settings for details on available options and their behavior.
If you want behavior more similar to when you define your app at the top level also known as Classic style , you can subclass Sinatra::Application :. Contrary to common belief, there is nothing wrong with the classic style. If it suits your application, you do not have to switch to a modular application. The main disadvantage of using the classic style rather than the modular style is that you will only have one Sinatra application per Ruby process. If you plan to use more than one, switch to the modular style.
There is no reason you cannot mix the modular and classic styles. If switching from one style to the other, you should be aware of slightly different default settings:. There are two common options for starting a modular app, actively starting with run! There is no need to switch to a config. Not only is Sinatra able to use other Rack middleware, any Sinatra application can, in turn, be added in front of any Rack endpoint as middleware itself.
Sometimes you want to create new applications at runtime without having to assign them to a constant. You can do this with Sinatra. This is especially useful for testing Sinatra extensions or using Sinatra in your own library. Every Sinatra application corresponds to a subclass of Sinatra::Base. If you are using the top-level DSL require 'sinatra' , then this class is Sinatra::Application , otherwise it is the subclass you created explicitly. At the class level, you have methods like get or before , but you cannot access the request or session objects, as there is only a single application class for all requests.
For every incoming request, a new instance of your application class is created, and all handler blocks run in that scope. From within this scope you can access the request and session objects or call rendering methods like erb or haml. You can access the application scope from within the request scope via the settings helper:.
The delegation scope just forwards methods to the class scope. However, it does not behave exactly like the class scope, as you do not have the class binding. You can explicitly add method delegations by calling Sinatra::Delegator. Have a look at the code for yourself: here's the Sinatra::Delegator mixin being extending the main object. Paraphrasing from this StackOverflow answer by Konstantin.
Sinatra doesn't impose any concurrency model but leaves that to the underlying Rack handler server like Puma or WEBrick. Sinatra itself is thread-safe, so there won't be any problem if the Rack handler uses a threaded model of concurrency. This would mean that when starting the server, you'd have to specify the correct invocation method for the specific Rack handler.
The following example is a demonstration of how to start a multi-threaded Rainbows server:. The following Ruby implementations are not officially supported but still are known to run Sinatra:. Not being officially supported means if things only break there and not on a supported platform, we assume it's not our issue but theirs.
Adding Postgres and ActiveRecord Getting started - adding dependencies to your project. Set up a project Rake file Getting started - adding activerecord rake commands. Making Migrations Migration files are small Ruby scripts that make changes to your database. Database Schemas Schemas define the structure of your database table and allow ActiveRecord to structure requests and changes for data. Connecting Tables to ActiveRecord models Use Models to map a database table onto native ruby objects.
Deploying with a Database How to deploy your project to Heroku and add a database. Basically it's wrapping around a database used by a legacy app, and exposing REST web services to other apps internally so they can interact with the legacy app without having to access the DB directly.
Take my answer with a bit of a grain of salt because I haven't actually deployed a sinatra application before , but sinatra's "sweet spot" is micro-apps: tiny little applications where a full MVC framework would be overkill.
With Sinatra, you can build an entire web app with a single file of code. An example of a "micro app" is rubular note, however, that I have no idea what framework it's written in. Rubular does one thing, and one thing very well. Using rails would be overkill. I personally think Sinatra is an excellent fit for APIs. Each version could be a different Sinatra app mounted at a different endpoint and you can run it inside of your Rails app. Stack Overflow for Teams — Collaborate and share knowledge with a private group.
Create a free Team What is Teams? Collectives on Stack Overflow. Once we have Mongodb, we need to install mongoid. To do so, we can just run the following command:. Next, we need a configuration file to tell our application where to find the MongoDB database. Create the file mongoid. And here is the content of this configuration file. We just specify where our database is running for the development environment.
Now we need to update the server. We have three things to do to have functional models. Here is the complete code for the server. Note the changes we just mentioned and pay close attention to the Book class. We defined three fields for our books: title , author , isbn and excerpt. We also added some validations and a unique index on the ISBN which are meant to be unique. We can easily access a similar console for our Sinatra application using irb.
Once you are inside, run the command require '. Finally, here are some sample books to populate the database. Just run each command in irb to get them persisted inside the MongoDB database.
We added one more gem sinatra-contrib to use the namespace feature later on. Finally, run bundle install to get everything in place. From now on, we will use bundle exec ruby server. Note that we could also have created a config. Creating a namespace for our API endpoints is important if we want to be able to version it and add a v2 later, for example. We will add all the books endpoints inside this namespace block.
We also need to require sinatra-namespace to have the namespace feature. The minimum code for this endpoint is the following. All we do in this code is get all the books, serialize them to JSON and return them. Start or restart the server with bundle exec ruby server.
0コメント