A Web Server vs. An App Server

When you research how to deploy your Rails app, you’ll see a lot of names: Apache,Unicorn, Puma, Phusion Passenger, Nginx, Rainbows, and many more. They all seem to fit under the “deploying Rails” category of software, but there’s a key difference between them. Some are “web servers,” and others are “app servers.”

Once you understand which is which, and where each category fits in your system, deployment will make a lot more sense. But the categories aren’t always clear.

What’s a web server, and how is it different than an app server? Can you use one without the other? And where does Rack fit in?

What’s a web server?

A web server is a program that takes a request to your website from a user and does some processing on it. Then, it might give the request to your Rails app.Nginx and Apache are the two big web servers you’ll run into.

If the request is for something that doesn’t change often, like CSS, JavaScript, or images, your Rails app probably doesn’t need to see it. The web server can handle the request itself, without even talking to your app. It’ll usually be faster that way.

Web servers can handle SSL requests, serve static files and assets, compress requests, and do lots of other things that almost every website needs. And if your Rails app does need to handle a request, the web server will pass it on to your app server.

What’s an app server?

An app server is the thing that actually runs your Rails app. Your app server loads your code and keeps your app in memory. When your app server gets a request from your web server, it tells your Rails app about it. After your app is done handling the request, the app server sends the response back to the web server (and eventually to the user).

You can run most app servers by themselves, without a web server in front of it. That’s probably what you do in development mode! In production, though, you’ll usually have a web server in front. It’ll handle multiple apps at once, render your assets faster, and deal with a lot of the processing you’ll do on every request.

There are a ton of app servers for Rails apps, including Mongrel (which isn’t used much anymore), Unicorn, Thin, Rainbows, and Puma. Each has different advantages and different philosophies. But in the end, they all accomplish the same thing – keeping your Rails app running and handling requests.

What about Passenger?

Phusion Passenger is a little unique. In “standalone mode,” it can act just like an app server. But it can also be built right into a web server, so you don’t need a separate app server to run your Rails apps.

This can be really convenient. Especially if you’re planning to run a bunch of apps and don’t want to spend time setting up an app server for each one. After installing Passenger, you just point the web server directly at your Rails app (instead of an app server), and your Rails app will start handling requests!

Passenger is a nice option, but having a separate app server can be still be good. Keeping the app server separate gives you the flexibility to choose an app server that best fits your needs, and you can run and scale it on its own. Still, I’m going to try it again the next time I deploy a new small app. I’m hoping it’ll make it easier to deploy future apps to the same server.

What about Rack?

Rack is the magic that lets any of these app servers run your Rails app. (Or Sinatra app, or Padrino app, or…)

You can think of Rack as a common language that Ruby web frameworks (like Rails) and app servers both speak. Because each side knows the same language, it means Rails can talk to Unicorn and Unicorn to Rails, without having either Rails or Unicorn know anything about the other.

How do they relate?

So, how does this all fit together?

Out of these pieces, a web request will hit your web server first. If the request is something Rails can handle, the web server will do some processing on the request, and hand it off to the app server. The app server uses Rack to talk to your Rails app. When your app is done with the request, your Rails app sends the response back through the app server and the web server to the person using your app.

More specifically, Nginx might pass a request to Unicorn. Unicorn gives the request to Rack, which gives it to the Rails router, which gives it to the right controller. Then, your response just goes back through the other way.

This overview might be simplified. But even just knowing these categories will help you put the software you run into into the right mental buckets.

After you understand how app servers and web servers fit together, it’ll be a lot easier to debug server problems when you have them. You’ll know all the different places you could look, and how they interact. And once the next interesting app server arrives, it’ll be even easier for you to swap it in!

Credits : http://www.justinweiss.com/blog/2015/07/15/a-web-server-vs-an-app-server/

All rights reserved by : Justin

Difference between collection route and member route in ruby on rails?

What is the difference between collection routes and member routes in Rails?

For example,

resources :photos do
  member do
    get :preview


resources :photos do
  collection do
    get :search


A member route will require an ID, because it acts on a member. A collection route doesn’t because it acts on a collection of objects. Preview is an example of a member route, because it acts on (and displays) a single object. Search is an example of a collection route, because it acts on (and displays) a collection of objects.

Practically: How it makes URI:

member {get 'preview'} will generate:

preview_photo_path(@photo) # /photos/1/preview

collection {get 'search'} will generate:

search_photos_path # /photos/search

How to Style Kaminari Pagination With Twitter Bootstrap 3 or other themes

By default, Kaminari will generate a list of nav wrapped under a div, which is totally different to the ul li structures of Bootstrap pagination.

No problemo! we could tweak this. Now we need to tell bootstrap to generate template files:

rails generate kaminari:views bootstrap

After hit this command in terminal, if you get message like below:

no such theme: bootstrap
 avaliable themes: bootstrap2, bootstrap3, bourbon, foundation, github, google, materialize, purecss, semantic_ui

Then run command again with your theme

rails generate kaminari:views materialize

which create various fields under app/views/kaminari.

Thats it. Now you can edit files as per your requirements

Pagination With Kaminari for rails


The will_paginate gem has long since been the most popular gem used when it comes to pagination. However it is not the only gem out there. Kaminari is another very popular pagination gem. In this article we will show you how to use it in your application. Let’s get started.

Rails Application Setup

To begin using the kaminari gem, we must first add it to our gemfile. Open up your gemfile and add in the line listed below.

gem 'kaminari', '~> 0.16.1'

Now run a bundle install to install the gem.

Terminal Commands:
bundle install

Next, let’s create a model called Post. The post model in this example will represent a blog post. Run the commands below to create the post model now.

Terminal Commands:
rails g model Post title body:string
rake db:migrate

Great, we need some seed data. Open your db/seeds.rb file and modify it so that it looks like the code listed below.

(1..100).each do |i|
  Post.create!(title: "Lipsum Post #{i}", body: %{
      Nullam hendrerit iaculis sodales. Curabitur varius nibh arcu, id molestie nibh fermentum vitae. Cras quis semper dui. Cras porttitor urna sit amet risus vehicula tempor. Maecenas quis tempor ligula. Donec et nibh eu leo volutpat placerat. Fusce vulputate elit in nisi pretium, vel fermentum mi fermentum. Mauris scelerisque, lectus non luctus ultricies, urna eros tincidunt risus, at varius sapien diam id erat.

Now run a rake db:seed to add the seed data.

Terminal Commands:
rake db:seed

Great, now we need to add a controller called Posts that we will use to render the posts. Run the command below to create this controller now.

rails g controller Posts index

Now let’s modify our routes file to set a site root. Open up your config/routes.rb file and modify it so that it looks like the code listed below.

Rails.application.routes.draw do
  root to: "posts#index"

Great, now open up your Posts controller and modify it so that it looks like the code listed below.

class PostsController < ApplicationController
  def index
    @posts = Post.page(params[:page]).per(10)

As you can see, the first bit of our pagination code is here. The page method tells kaminari what page we are on. The per method tells kaminari how many items we wish to have per page.

Now let’s open up the index view for our Posts controller and modify it so that it looks like the code listed below.

<hr />
<% @posts.each do |post| %>
  <h2><%= post.title %></h2>
  <%= post.body %>
<% end %>
<hr />
<%= paginate @posts %>
<%= page_entries_info @posts %>

The paginate helper is the line actually responsible for rendering the pagination links. Thepage_entries_info helper displays a line similar to Displaying posts 1 - 10 of 100 in total. This can be extremely helpful in letting the user know how many items there are in the list.

Rails – order by hour

Could be two things. First,

This code is deprecated:

Model.find(:all, :order => ...)

should be:


Find is no longer supported with the :all, :order, and many other options.

@records_sort_by_time = Schedule.order("TIME(start_time)").all.group_by{|t| t.start_time.strftime("%R") }// %R will give hh:mm from date-time