Why dependency injection matters in FastAPI - Visual Breakdown

Concept Flow - Why dependency injection matters

Define Dependency

↓

Inject Dependency into Function

↓

FastAPI Resolves Dependency

↓

Function Uses Dependency

↓

Return Response

This flow shows how FastAPI uses dependency injection to provide needed components to functions automatically.

Execution Sample

FastAPI

from fastapi import Depends, FastAPI
app = FastAPI()

def get_db():
    return "db_connection"

@app.get("/")
def read_root(db=Depends(get_db)):
    return {"db": db}

This code defines a dependency get_db and injects it into the read_root endpoint automatically.

Execution Table

Step	Action	Dependency Resolved	Function Parameter	Output
1	FastAPI starts request handling	None yet	None yet	Waiting for request
2	Request to '/' received	Calls get_db()	db=Depends(get_db)	db = 'db_connection'
3	Inject db into read_root	db_connection	db='db_connection'	Returns {"db": "db_connection"}
4	Response sent to client	N/A	N/A	{"db": "db_connection"}

💡 Request handled and response returned, dependency injection completed successfully

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
db	None	"db_connection"	"db_connection"	"db_connection"

Key Moments - 2 Insights

Why does FastAPI call get_db() automatically without us calling it?

FastAPI detects the Depends(get_db) in the function parameter and calls get_db() to provide the value before running read_root, as shown in step 2 and 3 of the execution_table.

What if get_db() returned a different value each time?

FastAPI will call get_db() on every request, injecting the fresh value each time, ensuring the function always gets the current dependency, as seen in step 2.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'db' when read_root runs?

A None

B "db_connection"

C "Depends(get_db)"

D An error

💡 Hint

Check step 3 in the execution_table where 'db' is injected into read_root.

At which step does FastAPI call the dependency function get_db()?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Dependency Resolved' column in the execution_table.

If get_db() returned None, what would be the output at step 3?

A {"db": None}

B {"db": "db_connection"}

C An error would occur

D Output would be empty

💡 Hint

Refer to how the 'db' variable is injected in step 3 of the execution_table.

Concept Snapshot

Dependency Injection in FastAPI:
- Define dependencies as functions (e.g., get_db).
- Use Depends() in endpoint parameters to declare dependencies.
- FastAPI calls dependencies automatically before endpoint runs.
- Injected values are passed as function arguments.
- This makes code cleaner, testable, and reusable.

Full Transcript

Dependency injection in FastAPI means you write small functions that provide needed resources, like a database connection. You then tell FastAPI to use these functions by adding Depends() in your endpoint parameters. When a request comes in, FastAPI calls these dependency functions automatically and passes their results into your endpoint functions. This way, your endpoint code stays simple and focused on its job. The execution table shows FastAPI calling get_db, injecting its result into read_root, and returning the response. This automatic wiring is why dependency injection matters: it keeps your code clean and easy to manage.

Practice

1. Why is dependency injection important in FastAPI applications?

easy

A. It forces you to write all code inside one big function.

B. It automatically generates HTML pages for your API.

C. It speeds up the server by caching all responses.

D. It helps keep code clean and makes components easy to share or replace.

Solution

1. Step 1: Understand the purpose of dependency injection

   Dependency injection allows you to provide parts like services or database connections to your functions without hardcoding them.

2. Step 2: Recognize benefits in FastAPI

   This makes your code cleaner and more flexible, as you can easily swap or share components.

3. Final Answer:

   It helps keep code clean and makes components easy to share or replace. -> Option D

4. Quick Check:

   Dependency injection = clean, flexible code [OK]

Hint: Think: clean code and easy swapping [OK]

Common Mistakes:

• Confusing dependency injection with caching
• Thinking it generates HTML automatically
• Believing it forces monolithic code

2. Which of the following is the correct way to declare a dependency in a FastAPI path operation?

easy

A. def read_data(db = Depends(get_db)):

B. def read_data(db: Depends = get_db):

C. def read_data(db: Depends(get_db)):

D. def read_data(db = get_db()):

Solution

1. Step 1: Recall FastAPI dependency syntax

   FastAPI uses Depends() inside the function parameter default value to declare dependencies.

2. Step 2: Check each option

   def read_data(db = Depends(get_db)): correctly uses db = Depends(get_db). Others misuse type hints or call the function directly.

3. Final Answer:

   def read_data(db = Depends(get_db)): -> Option A

4. Quick Check:

   Depends() in default value = correct syntax [OK]

Hint: Use Depends() as default parameter value [OK]

Common Mistakes:

• Calling the dependency function instead of passing it
• Using Depends as a type hint incorrectly
• Assigning dependency without Depends()

3. Given this FastAPI code snippet, what will be printed when accessing the endpoint?

from fastapi import FastAPI, Depends
app = FastAPI()

def get_number():
    return 42

@app.get("/number")
def read_number(num: int = Depends(get_number)):
    print(f"Number is {num}")
    return {"number": num}

medium

A. Number is 42 printed in console, response JSON {"number": 42}

B. Number is 0 printed in console, response JSON {"number": 0}

C. Error because get_number is not awaited

D. Response JSON {"number": null} with no print

Solution

1. Step 1: Understand dependency injection behavior

   The get_number function returns 42 and is injected as the parameter num.

2. Step 2: Trace the endpoint execution

   When the endpoint is called, it prints "Number is 42" and returns JSON with number 42.

3. Final Answer:

   Number is 42 printed in console, response JSON {"number": 42} -> Option A

4. Quick Check:

   Depends injects 42, prints and returns it [OK]

Hint: Dependency returns 42, so print shows 42 [OK]

Common Mistakes:

• Thinking dependency must be async
• Expecting default 0 instead of injected value
• Confusing print output with response content

4. What is wrong with this FastAPI dependency usage?

def get_db():
    return "db_connection"

@app.get("/items")
def read_items(db = get_db()):
    return {"db": db}

medium

A. The function get_db is missing async keyword.

B. The dependency function is called immediately instead of injected.

C. The endpoint is missing a return statement.

D. Depends() is used incorrectly inside the function body.

Solution

1. Step 1: Identify how dependency should be declared

   Dependencies must be passed as Depends(get_db), not by calling get_db() directly.

2. Step 2: Explain the problem in the code

   Calling get_db() runs it once at startup, not per request, losing flexibility and benefits of injection.

3. Final Answer:

   The dependency function is called immediately instead of injected. -> Option B

4. Quick Check:

   Call vs Depends() matters for injection [OK]

Hint: Use Depends(), don't call dependency function [OK]

Common Mistakes:

• Calling dependency function instead of passing Depends()
• Confusing async requirement with dependency injection
• Ignoring missing return statement (it exists here)

5. You want to share a database connection across multiple endpoints in FastAPI using dependency injection. Which approach best ensures the connection is created once per request and properly closed after?

hard

A. Pass the connection as a query parameter to each endpoint.

B. Create the connection globally once outside any function and reuse it everywhere.

C. Use a dependency function with yield that opens the connection, yields it, then closes it after.

D. Call the connection function directly inside each endpoint without Depends.

Solution

1. Step 1: Understand lifecycle management with dependencies

   Using yield in a dependency function allows setup before yield and cleanup after the request finishes.

2. Step 2: Compare options for connection management

   Use a dependency function with yield that opens the connection, yields it, then closes it after. correctly manages connection per request lifecycle. Others either create global state or misuse parameters.

3. Final Answer:

   Use a dependency function with yield that opens the connection, yields it, then closes it after. -> Option C

4. Quick Check:

   Yield in dependency = setup and cleanup per request [OK]

Hint: Use yield in dependency for setup and cleanup [OK]

Common Mistakes:

• Using global connection risking concurrency issues
• Calling connection directly losing cleanup control
• Passing connection via query parameters insecurely