Why background processing matters in Flask - Challenge Your Understanding

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a Flask route performs a long task synchronously?

Consider a Flask route that processes a long task directly in the request handler. What is the user experience during this time?

Flask

from flask import Flask
import time

app = Flask(__name__)

@app.route('/long-task')
def long_task():
    time.sleep(10)  # Simulates a long task
    return 'Task complete!'

A The user gets an error message because Flask does not support time.sleep().

B The user immediately sees 'Task complete!' and the task runs in the background.

C The server crashes because it cannot handle long tasks.

D The user waits for 10 seconds with no response until the task finishes, then sees 'Task complete!'.

💡 Hint

Think about what happens when the server is busy doing one thing.

When a Flask route runs a long task synchronously, the server holds the connection open and the user waits until the task finishes. No response is sent during the wait.

❓ state_output

intermediate

What is the output when using a background task with Flask and Celery?

Given a Flask app using Celery to run a background task, what will the user see immediately after triggering the task?

Flask

from flask import Flask, jsonify
from celery import Celery

app = Flask(__name__)
app.config['CELERY_BROKER_URL'] = 'redis://localhost:6379/0'
celery = Celery(app.name, broker=app.config['CELERY_BROKER_URL'])

@celery.task
def background_task():
    import time
    time.sleep(5)
    return 'Done'

@app.route('/start-task')
def start_task():
    task = background_task.delay()
    return jsonify({'task_id': task.id, 'status': 'started'})

A {"task_id": "<some_id>", "status": "started"}

B "Done"

C The server crashes due to missing Redis server.

D The user waits 5 seconds and then sees "Done".

💡 Hint

Background tasks let the server respond immediately.

The Flask route triggers the background task and immediately returns a JSON response with the task ID and status. The long task runs separately.

🔧 Debug

advanced

Why does this Flask app freeze on multiple long requests?

Examine the Flask app below. Why does it freeze or become unresponsive when multiple users access the /process route simultaneously?

Flask

from flask import Flask
import time

app = Flask(__name__)

@app.route('/process')
def process():
    time.sleep(10)  # Simulate long processing
    return 'Done'

if __name__ == '__main__':
    app.run()

A The app runs fine; freezing is caused by client-side issues.

B Flask's default server handles one request at a time, so concurrent requests wait and cause freezing.

C The time.sleep(10) causes a syntax error, freezing the app.

D Flask automatically runs each request in a new thread, so freezing is impossible.

💡 Hint

Think about how Flask's built-in server handles requests.

Flask's built-in development server is single-threaded by default, so it processes one request at a time. Long tasks block other requests, causing freezing.

🧠 Conceptual

advanced

Why use background processing in web apps?

Which of the following is the best reason to use background processing in a Flask web app?

A To improve user experience by handling long tasks without blocking the main server thread.

B To avoid writing any code for handling requests.

C To make the app run slower and use more memory.

D To prevent users from accessing the app during maintenance.

💡 Hint

Think about what users feel when waiting for slow tasks.

Background processing lets the app handle long tasks separately, so users get quick responses and the server stays responsive.

📝 Syntax

expert

Which Flask code snippet correctly starts a background task using threading?

Choose the code that correctly starts a background task in Flask using Python's threading module without blocking the main request.

Flask

from flask import Flask
import threading
import time

app = Flask(__name__)

def background_task():
    time.sleep(5)
    print('Background task done')

@app.route('/start')
def start():
    # Which option correctly starts the background task?
    pass

A

threading.start_new_thread(background_task)
return 'Task started!'

B

background_task()
return 'Task started!'

C

threading.Thread(target=background_task).start()
return 'Task started!'

D

threading.Thread(background_task()).start()
return 'Task started!'

💡 Hint

Remember how to create and start a thread properly.

Option C correctly creates a Thread object with the target function and starts it. Option C runs the task synchronously. Option C calls the function immediately and passes its result (None) to Thread. Option C uses a deprecated function incorrectly.