WSGI servers (Gunicorn, uWSGI) in Flask - Step-by-Step Execution

Concept Flow - WSGI servers (Gunicorn, uWSGI)

Start Flask App

↓

WSGI Server Receives HTTP Request

↓

WSGI Server Calls Flask App

↓

Flask App Processes Request

↓

Flask App Returns Response

↓

WSGI Server Sends HTTP Response

↓

Client Receives Response

The WSGI server acts as a middleman between the web and the Flask app, receiving requests, passing them to Flask, then sending back responses.

Execution Sample

Flask

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello from Flask!'

# Run with: gunicorn app:app

A simple Flask app that returns a greeting, served by Gunicorn as the WSGI server.

Execution Table

Step	Action	WSGI Server State	Flask App State	Response Sent
1	WSGI server starts and listens	Listening for requests	Not called yet	No response
2	HTTP request arrives	Request received	Not called yet	No response
3	WSGI server calls Flask app with request	Processing request	Running home() route	No response yet
4	Flask app returns 'Hello from Flask!'	Waiting to send response	Response ready	No response yet
5	WSGI server sends HTTP response to client	Idle, waiting for next request	Idle	Response sent: 'Hello from Flask!'
6	Client receives response	Idle	Idle	Response received by client

💡 Request cycle ends after response is sent and client receives it

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
WSGI Server State	Idle	Processing request	Waiting to send response	Idle	Idle
Flask App State	Not called	Running home()	Response ready	Idle	Idle
Response Sent	No	No	No	Yes	Yes

Key Moments - 3 Insights

Why does the WSGI server call the Flask app instead of handling the request itself?

The WSGI server acts like a waiter taking orders; it passes the request to Flask (the kitchen) to prepare the response. See execution_table step 3 where the server calls the Flask app.

When does the Flask app actually run the code to create the response?

The Flask app runs when the WSGI server calls it with the request, shown in step 3 and 4 of the execution_table where the home() function runs and returns the response.

What happens if the WSGI server does not send the response back to the client?

The client waits and sees no result. The cycle ends only after the server sends the response, as shown in step 5 and 6 where the response is sent and received.

Visual Quiz - 3 Questions

Look at the execution table, what is the WSGI server state at step 4?

A Listening for requests

B Idle

C Waiting to send response

D Request received

💡 Hint

Check the 'WSGI Server State' column at step 4 in the execution_table.

At which step does the Flask app finish processing and have the response ready?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Flask App State' column to see when the response is ready.

If the WSGI server never sends the response, what would the 'Response Sent' variable show after step 5?

A No

B Maybe

C Yes

D Error

💡 Hint

Refer to the 'Response Sent' variable in variable_tracker after step 5.

Concept Snapshot

WSGI servers like Gunicorn or uWSGI receive HTTP requests from clients.
They call the Flask app with the request.
Flask processes and returns a response.
The server sends this response back to the client.
This cycle repeats for each request.
WSGI servers act as the middleman between web and Flask.

Full Transcript

WSGI servers such as Gunicorn and uWSGI serve as intermediaries between the web and Flask applications. When a client sends an HTTP request, the WSGI server receives it and calls the Flask app with this request. The Flask app processes the request by running the appropriate route function and returns a response string. The WSGI server then sends this response back to the client. This process repeats for every incoming request, allowing Flask to focus on application logic while the WSGI server handles communication with the web. The execution table shows each step from server start, request receipt, Flask processing, to response delivery. Variables track the server and app states and when the response is sent. Understanding this flow helps beginners see how Flask apps run in real web environments using WSGI servers.

Practice

1. What is the main role of a WSGI server like Gunicorn or uWSGI when running a Flask application?

easy

A. To connect the Flask app to the web and handle multiple user requests efficiently

B. To write the Flask application code

C. To create the HTML templates for the Flask app

D. To manage the database connections directly

Solution

1. Step 1: Understand WSGI server purpose

   WSGI servers act as a bridge between the web and Flask app, managing requests.

2. Step 2: Identify what Gunicorn and uWSGI do

   They handle multiple users and serve the Flask app efficiently in production.

3. Final Answer:

   To connect the Flask app to the web and handle multiple user requests efficiently -> Option A

4. Quick Check:

   WSGI server role = Connect app and handle requests [OK]

Hint: WSGI servers link web and app, not write code [OK]

Common Mistakes:

• Thinking WSGI servers write app code
• Confusing WSGI with template engines
• Assuming WSGI manages databases

2. Which of the following is the correct command to start a Flask app using Gunicorn on port 8000?

easy

A. gunicorn app.py --port 8000

B. gunicorn run app --port=8000

C. gunicorn -w 4 -b 0.0.0.0:8000 app:app

D. gunicorn app:app --workers=2 --port=8000

Solution

1. Step 1: Recall Gunicorn syntax

   Gunicorn uses '-w' for workers and '-b' for binding address and port.

2. Step 2: Check correct app reference and port

   Correct format is 'gunicorn -w 4 -b 0.0.0.0:8000 app:app' to run app with 4 workers on port 8000.

3. Final Answer:

   gunicorn -w 4 -b 0.0.0.0:8000 app:app -> Option C

4. Quick Check:

   Gunicorn uses -w and -b flags [OK]

Hint: Gunicorn uses -w for workers and -b for bind address [OK]

Common Mistakes:

• Using --port instead of -b for binding
• Incorrect app reference like app.py instead of app:app
• Wrong flag order or missing workers

3. Given the command gunicorn -w 3 -b 127.0.0.1:5000 app:app, what will happen when you try to access the Flask app from another computer on the network?

medium

A. The app will be accessible from any computer on the network

B. The app will automatically bind to all interfaces

C. The app will refuse all connections and crash

D. The app will only be accessible from the local machine (127.0.0.1)

Solution

1. Step 1: Understand binding address 127.0.0.1

   Binding to 127.0.0.1 means the server listens only on localhost, not external network.

2. Step 2: Check network accessibility

   Other computers cannot access the app because it is not bound to the external IP or 0.0.0.0.

3. Final Answer:

   The app will only be accessible from the local machine (127.0.0.1) -> Option D

4. Quick Check:

   127.0.0.1 = localhost only [OK]

Hint: 127.0.0.1 binds only local access, not network [OK]

Common Mistakes:

• Assuming 127.0.0.1 allows network access
• Thinking Gunicorn auto-binds to all interfaces
• Confusing localhost with external IP

4. You run uwsgi --http :5000 --module app:app but get an error saying the module 'app' cannot be found. What is the most likely cause?

medium

A. The app.py file is missing or not in the current directory

B. The uWSGI command requires the --wsgi-file option instead of --module

C. The port 5000 is already in use by another process

D. The Flask app is not installed properly

Solution

1. Step 1: Understand module loading in uWSGI

   Using --module expects a Python module named 'app' with an 'app' variable inside.

2. Step 2: Check file presence and location

   If 'app.py' is missing or not in the current directory, uWSGI cannot find the module.

3. Final Answer:

   The app.py file is missing or not in the current directory -> Option A

4. Quick Check:

   Missing app.py causes module not found error [OK]

Hint: Check app.py file exists in current folder [OK]

Common Mistakes:

• Confusing --module with --wsgi-file
• Assuming port conflicts cause module errors
• Ignoring file location issues

5. You want to deploy a Flask app with uWSGI to handle 8 worker processes and bind it to all network interfaces on port 8080. Which command correctly achieves this?

hard

A. uwsgi --http 0.0.0.0:8080 --workers 8 --module app:app

B. uwsgi --http :8080 --processes 8 --module app:app --master

C. uwsgi --socket 0.0.0.0:8080 --processes 8 --wsgi-file app.py

D. uwsgi --http 127.0.0.1:8080 --workers 8 --module app:app

Solution

1. Step 1: Identify correct uWSGI flags for HTTP and workers

   --http :8080 binds to all interfaces on port 8080; --processes 8 sets 8 worker processes.

2. Step 2: Confirm module and master process usage

   --module app:app correctly points to the Flask app; --master enables master process for better management.

3. Step 3: Eliminate incorrect options

   A: uwsgi --http 0.0.0.0:8080 --workers 8 --module app:app uses invalid --workers flag (use --processes); B: uwsgi --http 127.0.0.1:8080 --workers 8 --module app:app binds only to localhost; C: uwsgi --socket 0.0.0.0:8080 --processes 8 --wsgi-file app.py uses --socket which is for socket mode, not HTTP.

4. Final Answer:

   uwsgi --http :8080 --processes 8 --module app:app --master -> Option B

5. Quick Check:

   Use --http :port and --processes with --master for production [OK]

Hint: Use --http :port and --processes with --master for uWSGI [OK]

Common Mistakes:

• Using --workers instead of --processes
• Confusing --socket with --http
• Binding only to 127.0.0.1 for network apps