Module 1 Exercises: Applying the Theory

Now that you understand the "Why" and "What" of FastAPI, it's time to test your knowledge. These exercises are designed to help you think like a FastAPI architect.

Exercise 1: Identifying Use Cases

Look at the following four hypothetical projects. Decide whether FastAPI, Django, or Flask would be the most suitable choice and provide a brief justification (1-2 sentences).

Project A: A simple personal blog where you only need to post articles once a week. You want a built-in admin panel to manage posts without writing any code.
Project B: A high-frequency trading bot interface that needs to handle 20,000 WebSocket messages per second and update a dashboard in real-time.
Project C: An AI-powered image generation API where users send a prompt (text) and get back a high-resolution image generated by a Stable Diffusion model.
Project D: A tiny one-off script that exposes a single "Health Check" endpoint for a legacy server. You don't want to install any dependencies.

Exercise 2: The Async Flow

Imagine you are building an API that needs to do three things when a user registers:

Save the user to a Database (takes 50ms).
Send a Welcome Email via an external SMTP service (takes 500ms).
Generate an Initial AI Avatar using a background service (takes 1000ms).

Questions:

If you were using a WSGI (Synchronous) framework like Flask, how long would the user have to wait for the response?
How does FastAPI's ASGI architecture change this wait time if you use background_tasks?

Exercise 3: Architectural Sketch

Draw (or describe) a simple architecture diagram for an AI Agent System built with FastAPI. Include the following components:

User Browser
FastAPI Endpoint
Pydantic Validation Layer
External LLM API (e.g., OpenAI or Bedrock)
Vector Database (for memory)

Self-Correction / Discussion

Exercise 1 Answers (Guidance):

Project A: Django. Why? The built-in Admin panel and "batteries-included" nature are perfect for content management systems.
Project B: FastAPI. Why? Native ASGI and WebSocket support are designed for this exact level of concurrency.
Project C: FastAPI. Why? The async nature handles the "long-waiting" image generation without blocking other users, and Pydantic ensures the prompts are valid.
Project D: Flask (or even simpler, http.server). Why? For a single endpoint without dependencies, the overhead of FastAPI or Django is unnecessary.

Summary of Module 1

You have mastered the foundations:

The transition from WSGI (Sync) to ASGI (Async).
The power of Starlette and Pydantic.
The real-world dominance of FastAPI in AI and ML.

Congratulations! You are ready to move on to Module 2: Python and Web API Foundations, where we will refresh the Python skills needed to write elite-level FastAPI code.