WSGI servers (Gunicorn, uWSGI) in Flask - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does WSGI stand for and why is it important in Python web development?

WSGI stands for Web Server Gateway Interface. It is a standard interface between web servers and Python web applications or frameworks. It allows web servers to communicate with Python code in a consistent way.

beginner

What is Gunicorn and what role does it play when deploying a Flask app?

Gunicorn is a WSGI HTTP server for Python. It runs your Flask app and handles multiple requests by managing worker processes, making your app ready to serve many users efficiently.

intermediate

How does uWSGI differ from Gunicorn in serving Flask applications?

uWSGI is another WSGI server that supports more protocols and features than Gunicorn. It is highly configurable and can serve Python apps but also supports other languages. Gunicorn is simpler and focused on Python WSGI apps.

beginner

Why should you not use Flask's built-in server in production?

Flask's built-in server is meant for development only. It is single-threaded and not designed to handle many users or heavy traffic. WSGI servers like Gunicorn or uWSGI are made for production and can handle multiple requests safely.

intermediate

What is a worker process in the context of Gunicorn or uWSGI?

A worker process is a separate process that handles incoming web requests. Multiple workers allow your app to handle many users at the same time by running requests in parallel.

What is the main purpose of a WSGI server like Gunicorn?

A To serve static files only

B To replace the Flask framework

C To manage databases

D To run Python web applications and handle multiple requests

WSGI servers like Gunicorn run Python web apps and manage multiple user requests efficiently.

Which of these is NOT a reason to use uWSGI over Flask's built-in server?

A Simpler to set up than Flask's built-in server

B Better handling of multiple requests

C Supports multiple languages and protocols

D More configurable for production use

uWSGI is more complex to configure than Flask's built-in server, which is simple but not suitable for production.

What happens if you run a Flask app with its built-in server in production?

A It will handle heavy traffic efficiently

B It may crash or slow down under many users

C It automatically switches to Gunicorn

D It becomes a WSGI server

Flask's built-in server is not designed for production and can crash or slow down with many users.

In Gunicorn, what is the role of worker processes?

A To handle incoming web requests concurrently

B To manage database connections

C To update the Flask code automatically

D To serve static images

Worker processes allow Gunicorn to handle multiple web requests at the same time.

Which command would you use to start a Flask app with Gunicorn?

A uwsgi --http :5000 --module app:app

B flask run

C gunicorn app:app

D python app.py

The command 'gunicorn app:app' starts the Flask app using Gunicorn as the WSGI server.

Explain what a WSGI server is and why it is needed when deploying a Flask application.

Think about how web servers talk to Python apps.

Compare Gunicorn and uWSGI in terms of features and typical use cases for Flask apps.

Consider ease of use versus configurability.

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