![Rack::Lock
• Sets env["rack.multithread"] flag to false
and wraps the application within a Mutex.
• Rack::Lock locks every request inside a mutex,
so that every request will effectively be
executed synchronously.](https://image.slidesharecdn.com/railsrequestmiddlewares-150307013714-conversion-gate01/85/Rails-Request-Middlewares-25-320.jpg)
![Rack::MethodOverride
• Allows the method to be overridden if
params[:_method] is set. This is the middleware
which supports the PUT and DELETE HTTP method
types.
• Rails forms convert PUT/DELTE request into the
POST request and passes the param[:_method]
which may be has values like ‘PUT’ & ‘DELETE’ etc.
• Then this middle converts the post request, into
proper request PUT/DELETE which user has initiated
for.](https://image.slidesharecdn.com/railsrequestmiddlewares-150307013714-conversion-gate01/85/Rails-Request-Middlewares-28-320.jpg)
![ActiveRecord::ConnectionAdapters::ConnectionManagement
• Cleans active connections after each request.
• It will not clean the active connections if
env[‘rack.test’] set to true.](https://image.slidesharecdn.com/railsrequestmiddlewares-150307013714-conversion-gate01/85/Rails-Request-Middlewares-37-320.jpg)
![RailsRequest::Application.routes
• Here RailsRequest will be different based on your Rails app
• This code returns the instance of ActionDispatch::Routing::RouteSet class
which is also a Rack application.
• After this, request goes to config/routes.rb file and from there it enters into
your MVC.
• Controller creates response & sends back it again to these middlewares stack.
• Middlewares may be can filter that response if necessary.
• Finally response goes to client through the app server & web server.
• How does Rails handle the routes and create the response in a way of [status,
header, body]? Well, that’s the topic for another talk.](https://image.slidesharecdn.com/railsrequestmiddlewares-150307013714-conversion-gate01/85/Rails-Request-Middlewares-48-320.jpg)
Rails Request & Middlewares
- 1. Rails Request & Middlewares Santosh Wadghule | @mechanicles BigBinary
- 2. What is a request?
- 3. Request is a… • It is set of instructions that tells a server what kind of response we want. • In simple way, when we hit any url in the browser for some file, that is your actual request :) • It is a part of HTTP (request/response) protocol. • HTTP uses one of the verbs like GET, POST, PUT & DELETE when you perform the request to the server.
- 4. Rails Request Life Cycle
- 5. The Greatest of the Great Greek Geniuses!
- 6. Rails Request Life Cycle Browser Web Server App Server Routes Controller Model View Database Rails App Middlewares
- 7. What is a Web Server? • Web Server is strictly HTTP based, it just takes HTTP requests and sends back HTTP responses to the clients(browsers). • It is mostly designed to serve static files. • It also has other functionality like request pipeline, load balancing etc. App servers lack these functionalities. • E.g. Ngnix, Apache
- 8. What is an App Server? • App Server actually runs your Rails app. • App Server is mostly known for to serve dynamic pages. • Web Server forwards its request to the App Server, and App Server in turn forwards that request to the Rails app. • In development mode, App Server can play role of web server. In production it does not scale too much so we need web server in between. • Webrick, Passenger, Mongrel, Unicorn, Thin & etc.
- 9. Request to Rails app • Rails isn’t just one application, it has lots of independent Rack applications (middlewares). • When request comes to the Rails app, it goes through the list of middleware series. • Last part of that series, sends request to the routes file. • Based on request, Rails decides which controller & action need to be executed from the routes. • After executing the controller’s action, Rails sends back response to the the client. • Web Server & App Server actually handle the job of sending response to the proper client.
- 10. What is a Middleware? • Middleware is Rack application. • Middleware is basically a filter for request and response. • So middlewares isolate the different stages of processing on the request and response.
- 11. Rails Middlewares Web Server Rails App A B C D Routes Controller Models Views Here A, B, C & D are middlewares Each of these does processing on request & response
- 12. Why Rails uses Middlewares? • Before Rails 3, Rails provides, like handling of session, parsing for parameters and etc were very tightly coupled. • As Rails was growing, apps built on Rails had more demanding requirements. For some apps, Rails gave lots of additional stuffs by default, which was not required like cookies/flash. For some other apps, to implement new filter on the the request/response was not possible. • In Rails 3 and after, all these issues have got solved by using a concept of Rack.
- 13. Rack
- 14. What is a Rack? • Rack is simple but powerful spec. Yes it is just spec. • It is not web framework or web server. • It is an interface that sits between your web server and your application. It wraps HTTP requests and responses in the simplest way possible, it unifies and distills the API for web servers, web frameworks and software in between (i.e. middleware) into a single method call. • Specification: A Rack application is a Ruby object (not a class) that responds to `call`. It takes exactly one argument, the environment and returns an Array of three values, The status, the headers, and the body. That’s it. • Rack is created by Christian Neukirchen.
- 15. Simple Rack App
- 16. Rack it up
- 17. What is Rack::Builder? • Rack::Builder implements a small DSL to iteratively construct Rack applications. • Rack::Builder is the thing that glues Rack middlewares and application together and convert them into single entity/rack application. • Under the hood, ‘rackup’ command converts your config.ru script to an instance of Rack::Builder. • Think of Rack::Builder object as stack in which your actual rack application is at bottom and all middlewares on top of it. The whole stack you can call it as rack application too.
- 18. Rails’ Rack::Builder • Same like Rack::Builder, we have similar concept in Rails, it is called as ActionDispatch::MiddlewareStack. • Better flexibility and more features to meet Rails’ requirement. • Many of Action Dispatcher’s internal components are implemented as Rack middleware. • Rails::Application uses ActionDispatch::MiddlewareStack to combine various internal and external middlewares to form a complete Rails Rack application.
- 19. Inspecting Rails Middlewares • Rails provides a task for inspecting the middleware stack in use. • $ bin/rake middleware
- 20. $ bin/rake middleware Note: List of the middlewares may be different for your Rails app
- 21. Request’s entry to MVC • When request comes to your Rails app, it goes through these middlewares. From top to bottom. • At the bottom, request enters into the your Rails’ MVC area.
- 22. Lets go through these middlewares and understand what these middlewares do
- 23. Rack::Sendfile • Sets server specific X-Sendfile header. • Configure this via config.action_dispatch.x_sendfile_header option • The Sendfile middleware intercepts responses whose body is being served from a file and replaces it with a server specific X-Sendfile header. The web server is then responsible for writing the file contents to the client. • This reduces the amount of work required by the Ruby backend and takes advantage of the web server's optimized file delivery code.
- 24. ActionDispatch::Static • This middleware will attempt to return the contents of a file's body from disk in the response. If a file is not found on disk, the request will be delegated to the application stack. This middleware is commonly initialized to serve assets from a server's `public/` directory. • Used to serve static files. Disabled if config.serve_static_files is false.
- 25. Rack::Lock • Sets env["rack.multithread"] flag to false and wraps the application within a Mutex. • Rack::Lock locks every request inside a mutex, so that every request will effectively be executed synchronously.
- 26. ActiveSupport::Cache::Strategy::LocalCache::Middleware • From doc It says, “Caches that implement LocalCache will be backed by an in-memory cache for the duration of a block. Repeated calls to the cache for the same key will hit the in-memory cache for faster access”. • This cache is not thread safe.
- 27. Rack::Runtime • Sets an "X-Runtime" response header, indicating the response time of the request, in seconds.
- 28. Rack::MethodOverride • Allows the method to be overridden if params[:_method] is set. This is the middleware which supports the PUT and DELETE HTTP method types. • Rails forms convert PUT/DELTE request into the POST request and passes the param[:_method] which may be has values like ‘PUT’ & ‘DELETE’ etc. • Then this middle converts the post request, into proper request PUT/DELETE which user has initiated for.
- 29. ActionDispatch::RequestId • Assigns a unique id to the request. • Sends back this unique id in X-Request-ID response header.
- 30. Rails::Rack::Logger • Notifies the logs that the request has began. After request is complete, flushes all the logs.
- 31. ActionDispatch::ShowExceptions • This middleware rescues any exception returned by the application and calls an exceptions app that will wrap it in a format for the end user.
- 32. ActionDispatch::DebugExceptions • This middleware is responsible for logging exceptions and showing a debugging page in case the request is local.
- 33. ActionDispatch::RemoteIp • It captures the remote IP address. • Checks for IP spoofing attacks.
- 34. ActionDispatch::Reloader • Provides prepare and cleanup callbacks, intended to assist with code reloading during development.
- 35. ActionDispatch::Callbacks • Provides callbacks to be executed before and after dispatching the request.
- 36. ActiveRecord::Migration::CheckPending • Checks pending migrations and raises ActiveRecord::PendingMigrationError if any migrations are pending.
- 37. ActiveRecord::ConnectionAdapters::ConnectionManagement • Cleans active connections after each request. • It will not clean the active connections if env[‘rack.test’] set to true.
- 38. ActiveRecord::QueryCache • Enables the Active Record query cache for request. • It clears the cache after executing the request.
- 39. ActionDispatch::Cookies • Sets cookies for the request.
- 40. ActionDispatch::Session::CookieStore • Responsible for storing the session in cookies. • It is dramatically faster than the alternatives.
- 41. ActionDispatch::Flash • Sets up the flash keys. • Only available if config.action_controller.session_store is set to a value.
- 42. ActionDispatch::ParamsParser • Parses out parameters from the request into params.
- 43. Rack::Head • Rack::Head returns an empty body for all HEAD requests. It leaves all other requests unchanged. • Converts HEAD requests to GET requests and serves them as so.
- 44. Rack::ConditionalGet • Adds support for "Conditional GET" so that server responds with nothing if page wasn't changed.
- 45. Rack::ETag • Adds ETag header on all String bodies. ETags are used to validate cache.
- 46. Warden::Manager • The middleware for Rack Authentication. • It injects an authentication object into the rack environment hash
- 47. Rack::Deflater • This middleware enables compression of http responses. • Supports these compression algorithms(gzip, deflate, identity)
- 48. RailsRequest::Application.routes • Here RailsRequest will be different based on your Rails app • This code returns the instance of ActionDispatch::Routing::RouteSet class which is also a Rack application. • After this, request goes to config/routes.rb file and from there it enters into your MVC. • Controller creates response & sends back it again to these middlewares stack. • Middlewares may be can filter that response if necessary. • Finally response goes to client through the app server & web server. • How does Rails handle the routes and create the response in a way of [status, header, body]? Well, that’s the topic for another talk.
- 49. Thanks :)