How the Web Server and Application Server Work in Rails App

In a Ruby on Rails application, two major components work together to handle client requests: the Web Server and the Application Server. Understanding their roles and interactions is essential for deploying and maintaining a Rails application.

1. Web Server

A web server manages incoming HTTP requests from clients (browsers, mobile devices, APIs) and forwards them to the appropriate application server. It serves as a gateway between the user and the application.

Role of Web Server:

• Listens to incoming HTTP requests (like GET, POST, PUT, DELETE).
• Routes the requests to the application server.
• Serves static files like CSS, JavaScript, images, etc.
• Can handle load balancing and SSL termination.

Common Web Servers Used with Rails:

• Nginx
• Apache

Example Setup with Nginx

In a production Rails app, Nginx typically listens to port 80 (HTTP) or 443 (HTTPS) and forwards the request to the application server.

Nginx Configuration Example:

server {
  listen 80;
  server_name myapp.com;

  location / {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

In this example:

• Nginx listens on port 80.
• It forwards the request to localhost:3000 (the application server).
• It sets headers to pass client information.

2. Application Server

The application server handles the core logic of your Rails application. It processes incoming requests, executes the Ruby on Rails code, interacts with the database, and generates the response.

Role of Application Server:

• Receives requests from the web server.
• Processes business logic using the Rails framework.
• Queries or updates the database as needed.
• Generates HTML/JSON responses and sends them back to the web server.

Common Application Servers Used with Rails:

• Puma (default in Rails 5+)
• Unicorn
• Passenger

Example Setup with Puma

In the development environment, Puma runs on port 3000 by default.

# config/puma.rb
port ENV.fetch("PORT") { 3000 }
environment ENV.fetch("RAILS_ENV") { "development" }

Puma will:

• Start a Ruby on Rails application.
• Listen to requests on port 3000.
• Process those requests and return responses.

3. Flow of a Request in Rails Application

Here’s a step-by-step flow of how a request is handled in a Rails application:

1. Client Request: A user visits https://myapp.com/posts.
2. Web Server: Nginx receives the request on port 80 and forwards it to Puma on port 3000.
3. Application Server: Puma processes the request, executes Rails code, retrieves data from the database, and renders a response.
4. Response: The response is passed back to Nginx, which sends it to the client’s browser.

4. Why Separate Web and Application Servers?>

• Scalability: The web server can manage multiple incoming requests and distribute them across multiple application servers.
• Performance: Serving static files and SSL termination is faster with a web server.
• Security: The web server acts as a shield to protect the application server from direct internet access.

5. Example of a Full Request Flow

Imagine a user accesses a blog post at https://myapp.com/posts/1:

1. Web Server:

-> Receives the request at myapp.com/posts/1.
-> Forwards it to Puma (localhost:3000).

2. Application Server:

-> Handles the request using Rails controllers.
-> Queries the database for the post.
-> Renders the post in HTML format.

3. Web Server:

Sends the HTML response back to the client.

This architecture ensures that Rails applications remain scalable, secure, and high-performing.

Also Read:

Active Model Serializers with Rails API