Rails request & middlewares

Editor's Notes

• #3: I’m a software developer.
• #6: I’m a great fan of this watch, Casio f-91W.
• #9: In simple way, when we hit any url in the browser for some file, that browser converts that url into the request message and sends to the server and that request message is your actual request :) When you want to get some data from the server, you use GET method. When we want to create new data on the server, we use POST method. When we want to update data like username we use PUT method. For destroying the data we use DELETE verb. There are also other methods like, HEAD, PATCH, OPTIONS, CONNECT & ETC which HTTP protocol provides.
• #11: This is a basic and standard diagram of Rails Request Life Cycle. You can see here, When browser initiates the requests it goes to Web Server, From the Web Server It goes through the App server, From App Server, request enters into the Rails app. Now if you see in the Rails app, request goes through the series of middlewares, From there request goes to the routes file and Based on request, Rails decides which controller & action need to be executed from the routes file. Now in controller if there is any business logic, it goes to model and from there it will fetch data from database or store the data in the database. If there any view like html, then request goes to view. After processing it, controller sends back the response to Browser.
• #12: In this diagram, I’m showing how app server and rails app communicate with each other. Communications between App Server and Rails app happen using Rack. Rack is a gem and acts as an interface between them. We will see more on rack in next slides.
• #14: It recognises Ruby application request and then it forwards its request to app server.
• #16: 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 too. In production it does not scale too much so we need web server in between.
• #18: This is all about basics of Rails request life cycle. Now lets see how rails handles the request under the hood.
• #20: You can think of middlewares isolate the different stages of processing on the request and response. One of the best things of Rack, you customise request/response very easily, by chaining middleware components in between the app server and the rails app.
• #22: Before Rails 3, handling of session, parsing for parameters and etc were too difficult.
• #24: Rake is “Make for Ruby” and it is task runner for Ruby.
• #26: Argument environment is nothing but environmental variables hash like PATH_INFO, QURY_STRING, REMOTE_ADDR, REQUEST_URI and all that junk. You can say this environment variable has all information of the request.
• #27: Using low coupling, you can replace any component with another one without having to reimplement code.
• #29: Here is a simple example of rack application.
• #30: This is another way to write rack application using rackup command which is given by Rack. The only thing you need is, to write your code in config.ru and run it using rackup config.ru.
• #33: In this code, I have defined rack application using MyRackApp and I have defined one middleware using MyMiddleware class. When you want to apply middleware to your rack application you have use ‘use’ method of Rack. When request comes, it comes from top to bottom. Means from the middleware to the actual rack application. Always remember that, middleware’s initialize method always takes an argument i.e. app that app is nothing but your next middleware or next rack application.
• #35: 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.
• #39: Many of Action Dispatcher’s internal components are implemented as Rack middleware.
• #41: You can inspect middleware stack of your rails application by using
• #42: This list is quite big, So I’m not going to explain what each of these middleware does here. But there is one middleware, I think most of you have seen it, that is CheckPending. Anyone knows what it does?
• #44: Lets write one middleware in the rails app. I mostly prefer to write middleware in config/initializers folder. In this middleware, mostly in call method, if request_path is ‘say_hello’, then this middleware will send this response back to the client. So here, our rails app will get called. If request_path ‘say_hello’ then our rails app gets called. To add this middleware in rails’s middleware stack, we need to set middleware to config.middleware.use or….config.middleware.insert_after But when we use this config.middleware.use then that middleware will get applied at the bottom of rails middleware series.