DEV Community: Ananya S

Introducing NovaDesk AI: Building a Stateful Hotel Concierge with LangGraph

Ananya S — Mon, 09 Nov 2026 15:15:40 +0000

When you start learning Agentic AI, you quickly hit a wall. Most tutorials show you how to build a basic chatbot that can search the web or call a simple calculator tool. But building a system that can actually manage multi-step processes, route intents, and remember context requires a massive leap in complexity.

I wanted to dive deep into Agentic AI and LangGraph, but I needed the right playground. If a project is too simple, you don't actually learn the orchestration framework. If it requires heavy domain logic (like the complex mortgage analytics I deal with at work), you spend all your time writing business rules instead of AI agents.

Enter NovaDesk AI: a fully stateful, hotel customer conceirge system.

Before we get into what it does, you can see the final system in action here:
🎥 YouTube:

💻 Github:

Anucool419 / NovaDesk_AI

🛎️ AI Hotel Concierge (LangGraph + FastAPI)

An enterprise-grade, stateful AI agent built to simulate a virtual hotel front desk. Unlike basic Q&A chatbots, this system bridges the gap between unstructured natural language and strict database transactions, allowing users to query policies, check room availability, book rooms, and request room service seamlessly.

This project demonstrates advanced AI engineering concepts including Agentic Orchestration (LangGraph), Advanced RAG (HyDE & Query Rewriting), State & Memory Management, and Human-in-the-Loop (HITL) security via FastAPI.

🏗️ Architecture Overview

The system is broken down into three main layers:

Frontend (Chainlit): Provides a clean, conversational chat UI.

Orchestration Brain (LangGraph): Manages conversation state, memory, guardrails, and decision routing.

Action Execution (FastAPI): Serves as the toolkit for the agent, exposing REST endpoints to interact securely with the SQLite database.

System Architecture

✨ Key Features

Strict Domain Guardrails: A routing node intercepts prompts. If a user asks off-topic questions (e.g…

View on GitHub

This post is the introduction to a multi-part series where I will document the entire build—from architecture and LangGraph subgraphs to RAG optimization and memory management. But first, let’s look at what the system actually does.

What is NovaDesk AI?

NovaDesk AI isn't just a wrapper around an LLM prompt. It is a system designed to act like a real hotel concierge. It connects to a database, enforces booking policies, asks clarifying questions when information is missing, and remembers who you are.

Note: Now, we can use even a non-AI website to book rooms or request for cancellations. Except for asking questions and getting immediate and relevant answers (using RAG), this project may not require AI. But the advantage is, the customer can speak in natural language and get answers in natural language. Also, the purpose of this project was more about learning.

Here are the core capabilities I built into the system:

1. Smart Policy Q&A (RAG)

Users can ask unstructured questions about hotel policies (e.g., "What is the pet fee?" or "Can I get late checkout?"). The bot retrieves the exact answers from a knowledge base, handling multi-part and confusing queries without hallucinating.

2. Live Room Availability & Bookings

The bot is connected to a mock SQLite database. If a user asks for a room this weekend, the bot checks the database, confirms availability, and walks the user through the booking process. If the user forgets to provide an email or a name, the bot realizes the missing parameters and asks for them before executing the booking.

3. Stateful Cancellations

Handling cancellations requires precision. The bot can retrieve a user's current booking from the database and securely execute a cancellation subgraph, updating the backend instantly. The subgraph also includes HITL (Human-in-the-loop) to ensure cancellation can't occur automatically and requires admin approval.

4. Room Service Integration

As a fun extra feature, I built a room service tool. The bot recognizes when a user wants food, pulls from a predefined menu of dishes, and records the order.

5. Persistent Memory

A concierge shouldn't forget what you said two minutes ago. NovaDesk AI uses short-term and persistent memory so a user can say, "Actually, change that to two nights," and the bot understands the context perfectly.

The Tech Stack (At a Glance)

To make all of this happen, I used:

LangGraph: The brain of the operation, using nodes, edges, and subgraphs to orchestrate the AI's workflow predictably.
FastAPI: To build the endpoints that actually interact with the database.
SQLite: For the mock hotel backend.
Vector Database (FAISS): To store and retrieve policy documents.
LangGraph Memory: checkpointer and InMemorySaver to handle state.

Taking it Live

As a final milestone, I managed to deploy the FastAPI backend to Azure so it’s publicly accessible. Deployment is still a massive learning curve for me, and getting it live was an adventure of its own, but having a working production URL is incredibly satisfying!

What's Next in this Series?

Building this was a series of trial and error, and I want to share exactly what broke and how I fixed it. In the upcoming posts, I will be doing deep dives into specific engineering challenges:

Part 2: The RAG Evolution. Why basic RAG failed my Golden Dataset, and how I fixed it using Query Rewriters, HyDE, and Maximal Marginal Relevance (MMR).
Part 3: LangGraph Subgraphs. How I designed the routing architecture and connected LangGraph nodes to FastAPI endpoints for bookings and cancellations.
Part 4: Memory & State. How I managed short-term and persistent memory so the bot never loses track of the conversation.

If you are learning GenAI, LangGraph, or just want to see how to architect an agentic workflow, make sure to follow along!

Have you started experimenting with LangGraph yet, or are you still relying on standard LangChain agents? Let me know in the comments! 👇

FastAPI for AI Engineers - Part 10: Mastering FastAPI: Scaling with APIRouters and Background Tasks

Ananya S — Mon, 26 Oct 2026 14:30:00 +0000

If you have been following this series, you have likely noticed a glaring issue as your project grows: routing every endpoint through a single main.py file creates an unmaintainable, thousands-of-lines-long bottleneck. Debugging becomes a nightmare.

If you're new to the series check it out here:

Ananya S

May 29

FastAPI for AI Engineers — Part 1: Why Every AI Backend Is Moving Toward FastAPI

#ai #backend #api #fastapi

4 min read

To build production-grade applications, we need a modular architecture. Here is how to scale your FastAPI backend using APIRouter and handle slow AI processing with BackgroundTasks.

1. APIRouters: Organizing Your Monolith

Think of APIRouter as a mini-FastAPI instance. It allows you to split your endpoints across multiple files based on their domain, while main.py acts purely as the central traffic hub.

Imagine a Gen-AI Agent Orchestrator with three core tables: Users, Agents, and Tasks. Instead of dumping all CRUD operations into the main file, we create a routers/ directory with dedicated files: auth.py, agents.py, and tasks.py.

Inside tasks.py, we replace @app.get with @router.get:


from fastapi import APIRouter

router = APIRouter(prefix="/tasks", tags=["Tasks"])

@router.get("/")
def get_all_tasks():
    return {"message": "Returns all tasks"}

We do the same with agents.py and auth.py.With your endpoints modularized, your main.py reduces to a clean, readable entry point:


from fastapi import FastAPI
from .database import engine
from . import models
from .routers import auth, agents, tasks

models.Base.metadata.create_all(bind=engine)

app = FastAPI()

# Plug the modular routers into the main app
app.include_router(auth.router)
app.include_router(agents.router)
app.include_router(tasks.router)

This is how organized the endpoints look like in /docs after using APIRouter

2. Background Tasks: Beating AI Latency

When building AI applications, latency is your biggest enemy. If a user submits a prompt, sending that query to an LLM might take 10 to 15 seconds. If you process this synchronously inside your endpoint, the user's browser will hang and eventually throw a timeout error.

FastAPI’s BackgroundTasks solves this by decoupling the HTTP response from the heavy computation. You instantly return a "status: queued" message to keep the frontend happy, while the AI processing runs silently in the background.

First, define a standard Python function for the heavy lifting. Then, inject BackgroundTasks into your endpoint:


from fastapi import APIRouter, Depends, BackgroundTasks, HTTPException
from sqlalchemy.orm import Session
import time

from .. import models, schemas
from ..database import get_db, sessionL
from .auth import get_current_user


router = APIRouter(
    tags=["Tasks"]
)

# 2. The Background Function
# CRITICAL: Background tasks run independently, so they need their own fresh Database Session!

def simulate_ai_agent(task_id: int):
    db = sessionL() # Open a new database connection
    try:
        print(f"[BACKGROUND] Agent starting task {task_id}...", flush=True)
        time.sleep(10) # Simulate a slow LLM generating text

        # Update the task status to completed
        task = db.query(models.Tasks).filter(models.Tasks.id == task_id).first()
        if task:
            task.status = "completed"
            db.commit()
            print(f"[BACKGROUND] Task {task_id} marked as completed!", flush=True)
        else:
            print(f"[BACKGROUND] Task {task_id} was not found.", flush=True)
    except Exception as error:
        print(f"[BACKGROUND] Task {task_id} failed: {error!r}", flush=True)
        raise
    finally:
        db.close() # Always close the background session

@router.post('/agents/{agent_id}/tasks', response_model=schemas.TaskResponse)
def create_task(agent_id:int, task:schemas.TaskCreate, background_tasks:BackgroundTasks, current_user:dict=Depends(get_current_user), db:Session=Depends(get_db)):
    existing_agent=db.query(models.Agents).filter(models.Agents.id==agent_id).first()
    if not existing_agent:
        raise HTTPException(status_code=404, detail='Agent not found.')
    if existing_agent.owner_id!=current_user['id']:
        raise HTTPException(status_code=403, detail='Adding tasks to this agent is forbidden.')
    new_task=models.Tasks(
        description=task.description,
        status='queued',
        agent_id=agent_id
    )
    db.add(new_task)
    db.commit()
    db.refresh(new_task)
    background_tasks.add_task(simulate_ai_agent, new_task.id)
    print(f"[ROUTE] Task {new_task.id} queued for background processing.", flush=True)
    return new_task

@router.get('/tasks/{task_id}', response_model=schemas.TaskResponse)
def get_task(task_id: int, current_user: dict = Depends(get_current_user), db: Session = Depends(get_db)):
    existing_task = db.query(models.Tasks).filter(models.Tasks.id == task_id).first()
    if not existing_task:
        raise HTTPException(status_code=404, detail='Task not found.')

    existing_agent = db.query(models.Agents).filter(models.Agents.id == existing_task.agent_id).first()
    if not existing_agent or existing_agent.owner_id != current_user['id']:
        raise HTTPException(status_code=403, detail='Forbidden to view this task.')

    return existing_task

The task is created as shown below with status='queued

The terminal message shows the exact working of the background tasks. As you can see from the code, the background task of simulate_ai_agent is inside the create_task endpoint, yet the create_task endpoint finishes first by printing [ROUTE] Task task_id is queued for background processing and even executes the addition of the new task with agent. Only after new_task is returned the simulate_ai_agent function running in the background starts and returns its response.

After 10 seconds, when you check the task status, this is what you get:

When you write background_tasks.add_task(...) inside your create_task endpoint, you aren't running the function right then. You are basically handing FastAPI a sticky note that says, "As soon as you finish sending the HTTP response to the user, run this heavy function."

This is the exact sequence:

1. create_task registers the sticky note.

2. create_task hits return {"message": "Queued", ...}.

3. FastAPI sends the 200 OK response to the user (their screen instantly updates).

4. FastAPI looks at the sticky note and begins running the background function.

This is exactly why it is the perfect tool for AI APIs. The user never has to wait 15 seconds staring at a loading spinner for an LLM to generate a response; you give them their confirmation instantly, and the AI does its heavy lifting behind the scenes!

With APIRouter keeping your codebase modular and BackgroundTasks handling your heavy LLM compute, you now have the foundational architecture for a scalable AI backend. This wraps up our FastAPI series—you are now ready to start integrating complex AI orchestration into your endpoints.

With this, we reach the end of the series. Hope you guys enjoyed it and learnt a lot. Do share in the comments down below, what errors you faced while building endpoints or if you tried any of the exercises in my posts and found them helpful.

Stay tuned for upcoming posts!! 😊👍

FastAPI for AI Engineers - Part 9: Mastering HTTP Exceptions & Status Codes

Ananya S — Tue, 20 Oct 2026 15:10:53 +0000

If you have been following this FastAPI series, we have built CRUD operations, connected to a database, and secured our endpoints with JWTs. But what happens when things go wrong?

When a user searches for an item that doesn't exist, or tries to access a route without a token, your API needs to communicate the exact problem. Returning a generic 500 Internal Server Error or a standard 200 OK with an error message in the body is a bad practice.

Today, we are going to look at the most common HTTP status codes and how to raise them cleanly using FastAPI's HTTPException.

The Core Status Codes You Need to Know

HTTP status codes are grouped by their starting number.

2xx (Success): Everything worked perfectly.
4xx (Client Error): The user did something wrong (bad data, missing token, wrong URL).
5xx (Server Error): Your code broke.

Here are the four most critical 4xx errors you will use in FastAPI:

1. `404 Not Found`

Use this when a requested resource does not exist in your database.

from fastapi import FastAPI, HTTPException

app = FastAPI()

fake_db = {"1": "Apple", "2": "Banana"}

@app.get("/items/{item_id}")
def get_item(item_id: str):
    if item_id not in fake_db:
        raise HTTPException(
            status_code=404, 
            detail=f"Item with ID {item_id} does not exist."
        )
    return {"item": fake_db[item_id]}

2. `400 Bad Request`

Use this when the user sends a request that is syntactically correct but fails a business logic rule.

Note: If you use Pydantic models (like we covered in Part 4), FastAPI automatically handles basic validation errors (like ensuring an amount is a positive number) and throws a 422 Unprocessable Entity. You should reserve 400 for business rules your schema can't easily express, like checking an account balance.


from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

app = FastAPI()

# Mock database of account balances
account_balances = {"account_abc": 100}

class TransferRequest(BaseModel):
    account_id: str
    # Pydantic handles the > 0 check automatically, returning a 422 if it fails
    amount: int = Field(gt=0) 

@app.post("/transfer")
def transfer_funds(request: TransferRequest):
    current_balance = account_balances.get(request.account_id, 0)

    # We use a 400 here for business logic that Pydantic cannot know about
    if request.amount > current_balance:
        raise HTTPException(
            status_code=400, 
            detail="Insufficient funds for this transfer."
        )

    account_balances[request.account_id] -= request.amount
    return {
        "message": "Transfer successful", 
        "remaining_balance": account_balances[request.account_id]
    }

This is the 400 error, when we request an amount greater than what is present in our account balance.

This is 422 error, when we add integers where strings should be there.

3. `401 Unauthorized (Authentication)`

This is the error you throw when someone tries to access a protected route without a JWT token, or with an expired/invalid token. Think of this as: "I don't know who you are."

from fastapi import Header

@app.get("/profile")
def get_profile(authorization: str = Header(default=None)):
    if not authorization or not authorization.startswith("Bearer "):
        raise HTTPException(
            status_code=401, 
            detail="Missing or invalid authentication token",
            headers={"WWW-Authenticate": "Bearer"},
        )
    return {"user": "ZeroShotAnu"}

4. `403 Forbidden (Authorization)`

This is often confused with 401. You use 403 Forbidden when you know who the user is (their token is valid), but they do not have the permission to do what they are trying to do. Think of this as: "I know who you are, but you aren't an Admin."


@app.delete("/users/{user_id}")
def delete_user(user_id: str, current_user_role: str = "guest"):
    # The user is logged in, but they are just a guest
    if current_user_role != "admin":
        raise HTTPException(
            status_code=403, 
            detail="You do not have permission to delete users."
        )
    return {"message": "User deleted"}

Another example I tried here is, we already have this user existing and hence it is forbidden to create the same user again.

Error

So when I create a real new student,

it shows a success response:

🛡️ Security Pro-Tip: The 404 Fallback
If a user tries to access a specific private resource (like someone else's billing record), returning a 403 confirms that the record actually exists. To prevent attackers from guessing valid IDs in your database, highly secure APIs will often return a 404 Not Found instead, keeping the attacker entirely in the dark.

fake_db = {"invoice_88": {"owner": "Alice", "amount": 100}}

@app.get("/invoices/{invoice_id}")
def get_private_invoice(invoice_id: str, current_user: str = "Bob"):
    invoice = fake_db.get(invoice_id)

    # Hide both "doesn't exist" and "unauthorized" behind the same 404 error
    if not invoice or invoice["owner"] != current_user:
        raise HTTPException(
            status_code=404, 
            detail="Invoice not found."
        )
    return invoice

Why This Matters

Proper status codes make your API predictable. When a frontend developer (or an AI Agent) interacts with your API, they don't read the text in your detail message first; their code looks at the status_code to decide what to do next.

If they see a 401, they redirect the user to the login screen.

If they see a 404, they show a "Page Not Found" illustration.

The next post will be the last post in this series, we will learn about APIRouter and Background tasks. Hope you enjoyed this series.
Do ask any questions you have in the comments below.

FastAPI for AI Engineers - Part 8: Uploading Files with FastAPI

Ananya S — Mon, 31 Aug 2026 15:37:39 +0000

In the previous article, we learned how to secure our APIs using JWT Authentication and protect routes from unauthorized access.

Now let's explore another feature used in almost every AI application—file uploads.

If you've built applications like ChatGPT, document Q&A systems, resume analyzers, legal contract reviewers, or medical report analyzers, one thing is common across all of them:

The user uploads a file.

Without file uploads, there is nothing for the AI model to process.

If you haven't read the previous article, check it out first to continue the series:
Protecting routes with JWT Tokens

Why Do We Need File Uploads?

Consider some popular AI applications:

ChatGPT allows you to upload PDFs and images.
Resume analyzers require your resume.
Legal AI assistants analyze contracts.
Medical AI systems analyze lab reports.
RAG applications build knowledge bases from documents.

The workflow usually looks like this:

  User
   │
   ▼
Upload File
   │
   ▼
FastAPI
   │
   ▼
Save / Read File
   │
   ▼
Process using AI

FastAPI makes uploading files extremely simple.

Installing Required Package

FastAPI uses python-multipart to process uploaded files.

Install it using:

pip install python-multipart

Your First File Upload API

FastAPI provides two important classes:

File
UploadFile

Let's import them.

from fastapi import FastAPI, File, UploadFile

app = FastAPI()

Creating the Upload Endpoint

@app.post("/upload")
def upload_file(file: UploadFile):

    return {
        "filename": file.filename
    }

Run the application.

Open Swagger UI.

Click POST /upload.

You'll notice FastAPI automatically provides a file picker.

Upload a file.

Response:

{
    "filename": "resume.pdf"
}

Our API successfully received the uploaded file.

Understanding UploadFile

You might wonder:

Why didn't we simply use a string or bytes?

FastAPI provides the UploadFile class because it contains useful information about the uploaded file.

Some commonly used attributes are:

file.filename

Returns:

resume.pdf

file.content_type

Returns:

application/pdf

await file.read()

Reads the file contents.

These attributes become extremely useful when building AI applications.

Reading File Contents

Suppose we want to know how many bytes were uploaded.

@app.post("/upload")
async def upload_file(file: UploadFile):

    contents = await file.read()

    return {
        "filename": file.filename,
        "size": len(contents)
    }

Example response:

{
    "filename": "contract.pdf",
    "size": 254321
}

Notice that we changed the function to:

async def

This is because file.read() is an asynchronous operation.

Saving Uploaded Files

In many applications, we don't just read the file.

We save it for later processing.

@app.post("/upload")
async def upload_file(file: UploadFile):

    contents = await file.read()

    with open(file.filename, "wb") as f:
        f.write(contents)

    return {
        "message": "File uploaded successfully."
    }

Let's understand the code.

contents = await file.read()

Reads the uploaded file into memory.

with open(file.filename, "wb")

Creates a new file.

The "wb" mode means:

w → Write
b → Binary mode

Binary mode is important because PDFs, images, Word documents, and many other files are not plain text.

f.write(contents)

Writes the uploaded data to disk.

AI Workflow Example

Suppose a user uploads a legal contract.

   contract.pdf
        │
        ▼
FastAPI Upload Endpoint
        │
        ▼
     Save PDF
        │
        ▼
    Extract Text
        │
        ▼
Create Embeddings
        │
        ▼
Store in Vector Database
        │
        ▼
   Ask Questions

This is the same workflow followed by many Retrieval-Augmented Generation (RAG) applications.

Similarly,

Resume Analyzer:

Resume.pdf
      │
      ▼
Extract Text
      │
      ▼
Skill Extraction
      │
      ▼
  ATS Score

Medical Report Analyzer:

Blood_Report.pdf
        │
        ▼
OCR / Text Extraction
        │
        ▼
  LLM Analysis
        │
        ▼
  Health Summary

File uploads are the entry point for almost every document-based AI application.

UploadFile vs bytes

FastAPI also allows uploading files as raw bytes.

@app.post("/upload")
async def upload(file: bytes = File()):

    return {
        "size": len(file)
    }

Although this works, it is rarely used for large files.

UploadFile is generally preferred because:

It provides metadata such as filename and content type.
It is optimized for larger uploads.
It is more memory efficient.

For most production applications, UploadFile is the recommended choice.

Complete Example

from fastapi import FastAPI, UploadFile

app = FastAPI()

@app.post("/upload")
async def upload_file(file: UploadFile):

    contents = await file.read()

    with open(file.filename, "wb") as f:
        f.write(contents)

    return {
        "filename": file.filename,
        "content_type": file.content_type,
        "size": len(contents),
        "message": "Upload Successful"
    }

Workflow Recap

User Uploads File
        │
        ▼
FastAPI Receives Upload
        │
        ▼
UploadFile Object Created
        │
        ▼
    Read File
        │
        ▼
    Save File
        │
        ▼
AI Processing Begins

Final Thoughts

Uploading files is one of the most important capabilities of modern AI backends.

Whether you're building a chatbot over PDFs, a resume analyzer, a legal contract assistant, or a medical report analyzer, every application begins with accepting user files.

Today we learned how to:

Upload files using FastAPI
Understand the UploadFile object
Read uploaded files
Save files locally
Understand where file uploads fit into AI workflows

It's been some time since I've uploaded. We will continue with our FastAPI series in the upcoming posts.

I Built an End-to-End Mortgage Loan Analytics Dashboard with Python & Power BI

Ananya S — Mon, 13 Jul 2026 16:40:20 +0000

Business Intelligence isn't just about creating beautiful dashboards.

It's about transforming raw, messy data into meaningful business decisions.

To understand the complete analytics lifecycle, I built an end-to-end Mortgage Loan Portfolio Analytics Dashboard using Python, Power BI, Power Query, and DAX.

This project goes far beyond drag-and-drop visualizations—it covers data generation, ETL, dimensional modeling, KPI development, and executive dashboard design, closely mirroring how analytics teams work in real organizations.

Why I Built This Project

Financial institutions manage thousands of mortgage loans every year.

Business leaders constantly need answers to questions like:

Which regions have the highest loan exposure?
What is the portfolio default rate?
Which customers are at higher credit risk?
Are loan repayments improving over time?
Which loan officers manage the largest portfolios?

Without centralized reporting, these insights are scattered across multiple systems.

The goal of this project was to build a dashboard that converts raw mortgage data into actionable business intelligence.

Tech Stack

🐍 Python
Pandas
Faker
Excel
Power Query
Power BI
DAX
Git & GitHub

Each tool played a different role throughout the analytics pipeline instead of using Power BI alone.

Project Architecture

Python
      │
      ▼
Synthetic Mortgage Dataset
      │
      ▼
Excel Files
      │
      ▼
Power Query (ETL)
      │
      ▼
Star Schema Data Model
      │
      ▼
DAX Measures
      │
      ▼
Interactive Power BI Dashboard
      │
      ▼
Business Insights

This mirrors a real Business Intelligence workflow rather than simply importing a CSV into Power BI.

Step 1 — Generating Realistic Data

Instead of downloading a public dataset, I generated my own synthetic mortgage portfolio using Python.

The generated data includes:

1,000 customers
1,000 properties
1,500 mortgage loans
400,000 payment records
25 loan officers
Calendar dimension table

Creating the data myself gave me complete control over relationships and business scenarios while making the project feel closer to a production system.

Step 2 — Data Cleaning with Power Query

Real-world datasets are rarely perfect.

To simulate production data, I intentionally introduced quality issues before cleaning them.

The ETL process included:

Standardizing employment types
Standardizing province names
Removing duplicate IDs
Handling missing values
Correcting data types
Creating income bands
Creating property appreciation categories

Power Query became the primary ETL layer before any reporting began.

Step 3 — Building a Star Schema

One of the biggest improvements over beginner Power BI projects was using a proper dimensional model.

Instead of connecting tables randomly, I designed a Star Schema.

Fact tables:

Loans
Payments

Dimension tables:

Customers
Properties
Loan Officers
Calendar

This model keeps DAX simpler while improving report performance and scalability.

Step 4 — Writing Business KPIs with DAX

Dashboards are only as valuable as the metrics they expose.

Some of the measures I created include:

Portfolio KPIs

Total Portfolio
Total Loans
Total Customers
Average Loan Amount
Average Interest Rate
Average Credit Score

Risk KPIs

Default Rate
Delinquency Rate
Average Days Late

Payment KPIs

Monthly Payments
Total Payments Received
Cumulative Payments

Instead of focusing on visuals first, I focused on translating business questions into measurable KPIs.

Dashboard Pages

The report is divided into multiple business-focused dashboards.

Executive Overview

Provides leadership with an instant snapshot of:

Portfolio value
Default rate
Delinquency rate
Loan status
Monthly payment trends

Customer & Loan Analysis

Focuses on:

Income segmentation
Credit score analysis
Borrowing behavior
Loan officer performance

Risk & Payment Analysis

Shows:

Average days late
Geographic delinquency
Credit score vs risk
Property type risk

Interactive slicers and custom navigation make exploration much easier for end users. The reddish orange rectangles in the top left corner in each image are custom buttons made for navigation between dashboard pages with ease.

Business Insights

The dashboard uncovered several useful observations:

Most loans remain active, with a relatively low default rate.
Mortgage exposure is concentrated in a few provinces.
Medium-income borrowers form the largest customer segment.
Higher income generally correlates with larger loan sizes.
Payment delays exist across all regions rather than a single hotspot.
Loan officer portfolios are unevenly distributed, suggesting opportunities for workload balancing.

These are the kinds of insights executives actually use to guide lending strategy.

The Most Valuable Lesson

One of the most interesting discoveries wasn't about Power BI—it was about data validation.

During analysis, I noticed that the generated ActualPayment values didn't always align with the calculated mortgage payment.

Rather than hiding the issue, I documented it.

In real organizations, analysts spend a significant amount of time validating data before building reports.

Finding data quality issues is part of the job.

Sometimes the dashboard is the easiest part.

Skills Practiced

This project helped me gain hands-on experience with:

Python data generation
ETL using Power Query
Star Schema modeling
DAX development
KPI design
Business Intelligence reporting
Dashboard storytelling
Executive reporting
Data validation
Git & GitHub workflows

Final Thoughts

One misconception I had before starting this project was that Power BI was mostly about creating charts.

After building this dashboard, I realized the visuals are only the final layer.

Most of the effort goes into:

Understanding business requirements
Cleaning and validating data
Designing an efficient data model
Creating meaningful KPIs
Translating business questions into insights

That's what transforms a dashboard into a real decision-making tool.

GitHub Repository

You can explore the complete project, including the Python scripts, datasets, Power BI dashboard, and documentation here:

Repository: Mortgage Loan Analytics Dashboard

I'd love to hear your feedback or suggestions for improving the project!

FastAPI for AI Engineers - Part 7: Protecting Routes with JWT Tokens

Ananya S — Mon, 29 Jun 2026 16:51:57 +0000

In the previous article, we learned how to:

Register users
Hash passwords using bcrypt
Verify passwords during login
Generate JWT tokens

However, generating a token alone doesn't secure an application.

Anyone can still access endpoints unless we verify the token before granting access.

Today we'll learn how FastAPI identifies users from JWT tokens and protects routes from unauthorized access.

Do check out the previous post to understand this:

Ananya S

Jun 15

FastAPI for AI Engineers - Part 6: JWT Authentication in FastAPI

#ai #python #fastapi #backend

4 min read

The Problem

Suppose we have:

@app.get("/profile")
def get_profile():
    return {"message": "My profile"}

Anyone can access this endpoint.

There is no verification of:

Who is making the request
Whether they are logged in
Whether their token is valid

Authentication Flow

Login
   ↓
Generate JWT
   ↓
Store JWT
   ↓
Send JWT with Request
   ↓
Verify JWT
   ↓
Allow Access

Extracting the Token

OAuth2PasswordBearer

OAuth2PasswordBearer is a class provided by FastAPI to handle security and authentication using OAuth2 with the Password flow and Bearer tokens. This class simplifies the process of implementing secure authentication in your FastAPI application.

To use OAuth2PasswordBearer, you need to create an instance of it and pass the tokenUrl parameter, which specifies the URL where the client will send the username and password to obtain a token.

from fastapi.security import OAuth2PasswordBearer
oauth2_scheme = OAuth2PasswordBearer(
    tokenUrl="login"
)

When a request arrives:

Authorization: Bearer eyJhbGc...

FastAPI automatically extracts the token.

Decoding JWT Tokens

from jose import jwt
from jose import JWTError
def verify_token(token: str):

    try:
        payload = jwt.decode(
            token,
            SECRET_KEY,
            algorithms=[ALGORITHM]
        )

        username = payload.get("sub")

        return username

    except JWTError:
        return None

JWT contains:

{
  "sub": "suman",
  "exp": ...
}

We extract the username from "sub".

Creating get_current_user()

This is the most important concept.

from fastapi import Depends

def get_current_user(
    token: str = Depends(oauth2_scheme)
):

    username = verify_token(token)

    if username is None:
        raise Exception("Invalid token")

    return username

Every protected endpoint will use:

Depends(get_current_user)

This ensures that users who have registered and who's JWT token has been verified only they have access to the protected route.

Protecting Routes

@app.get("/profile")
def get_profile(
    current_user: str = Depends(
        get_current_user
    )
):

    return {
        "message": f"Welcome {current_user}"
    }

Now:

Valid Token (When access is granted as JWT token matches)

{
  "message": "Welcome suman"
}

Invalid Token (Access not granted)

{
  "detail": "Could not validate credentials"
}

Visual Flow

User Login
      ↓
JWT Token Generated
      ↓
Token Sent in Request
      ↓
FastAPI Extracts Token
      ↓
JWT Verification
      ↓
Current User Identified
      ↓
Protected Route Access

Conclusion

Today we learned:

OAuth2PasswordBearer
Extracting JWT tokens
Decoding JWT tokens
Creating get_current_user()
Protecting routes using Depends()

In the next article, we'll move beyond authentication and implement Role-Based Access Control (RBAC), allowing different users to have different permissions.

FastAPI for AI Engineers - Part 6: JWT Authentication in FastAPI

Ananya S — Mon, 15 Jun 2026 17:22:40 +0000

In the previous article, we explored the concepts of Authentication and Authorization.

We learned that:

Authentication answers "Who are you?"
Authorization answers "What are you allowed to do?"

Understanding the concepts is important, but real-world applications require actual implementation.

If you've ever used Gmail, LinkedIn, GitHub, or ChatGPT, you've already used authentication systems countless times.

You enter your username and password, the application verifies your identity, and you gain access to protected resources.

But how does this actually work behind the scenes?

In this article, we'll build a complete JWT Authentication system using FastAPI.

If you haven't read the previous article, check it out first:

Ananya S

Jun 12

FastAPI for AI Engineers - Part 5: Authentication vs Authorization (And Why Most Beginners Confuse Them)

#ai #python #fastapi #backend

3 min read

Why Do We Need Authentication?

Imagine building an AI-powered learning platform.

Without authentication:

Anyone could access any user's profile
Anyone could view another student's progress
Anyone could modify data belonging to other users

Clearly, this is a security problem.

Applications need a way to:

Verify user identity
Protect sensitive resources
Allow users to stay logged in

This is where JWT Authentication comes in.

What is JWT?

JWT stands for JSON Web Token.

A JWT is a secure token that contains information about a user.

Instead of sending a username and password with every request, the user sends a token.

Typical flow:

Register User
      ↓
   Login
      ↓
Verify Credentials
      ↓
Generate JWT Token
      ↓
Access Protected Routes

Installing Required Packages

pip install python-jose passlib[bcrypt]

We'll use:

passlib for password hashing
python-jose for JWT token generation and verification

Step 1: Hashing Passwords

Storing passwords in plain text is extremely dangerous.

Never do this:

users = {
    "rahul": "password123"
}

If the database is compromised, every user's password becomes visible.

Instead, we store a hashed version.

Creating a Password Hasher

from passlib.context import CryptContext

pwd_context = CryptContext(
    schemes=["bcrypt"],
    deprecated="auto"
)

What is CryptContext?

CryptContext manages password hashing algorithms.

In this example:

schemes=["bcrypt"]

we tell FastAPI to use the bcrypt hashing algorithm.

Hashing a Password

hashed_password = pwd_context.hash("password123")

print(hashed_password)

Output:

$2b$12$.....

Notice that the original password is no longer visible.

Verifying Passwords

When the user logs in:

pwd_context.verify(
    "password123",
    hashed_password
)

returns:

True

This allows us to verify passwords without storing them in plain text.

Step 2: User Registration

Let's create a simple registration endpoint.

from fastapi import FastAPI

app = FastAPI()

users = {}

@app.post("/register")
def register(username: str, password: str):

    hashed_password = pwd_context.hash(password)

    users[username] = hashed_password

    return {"message": "User registered successfully"}

What happens here?

User submits username and password
Password is hashed
Hash is stored instead of the original password

Step 3: User Login

Now let's verify credentials.

@app.post("/login")
def login(username: str, password: str):

    stored_password = users.get(username)

    if not stored_password:
        return {"message": "User not found"}

    if not pwd_context.verify(password, stored_password):
        return {"message": "Invalid credentials"}

    return {"message": "Login successful"}

At this point, users can log in successfully.

However, they still need to send their username and password with every request.

JWT solves this problem.

Step 4: Creating a JWT Token

from jose import jwt
from datetime import datetime, timedelta

SECRET_KEY = "mysecretkey"

ALGORITHM = "HS256"

Why do we need a secret key?

The secret key is used to sign tokens.

If someone modifies the token, the signature becomes invalid.

Generate Token Function

def create_access_token(data: dict):

    to_encode = data.copy()

    expire = datetime.utcnow() + timedelta(minutes=30)

    to_encode.update({"exp": expire})

    encoded_jwt = jwt.encode(
        to_encode,
        SECRET_KEY,
        algorithm=ALGORITHM
    )

    return encoded_jwt

What does this function do?

Copies user data
Adds an expiry time
Creates a signed JWT token
Returns the token

Step 5: Generate Token During Login

@app.post("/login")
def login(username: str, password: str):

    stored_password = users.get(username)

    if not stored_password:
        return {"message": "User not found"}

    if not pwd_context.verify(password, stored_password):
        return {"message": "Invalid credentials"}

    token = create_access_token(
        {"sub": username}
    )

    return {
        "access_token": token,
        "token_type": "bearer"
    }

Successful login now returns:

{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "token_type": "bearer"
}

Step 6: Protected Route

Now we can protect routes.

@app.get("/profile")
def get_profile():

    return {
        "message": "Protected profile data"
    }

Currently anyone can access it.

In production applications, FastAPI verifies the JWT token before allowing access.

We'll implement complete route protection in the next article.

For now, focus on understanding:

Registration
Password Hashing
Password Verification
JWT Generation

These form the foundation of every authentication system.

Authentication Flow Recap

Register User
      ↓
Hash Password
      ↓
Store Hash
      ↓
   Login
      ↓
Verify Password
      ↓
Generate JWT
      ↓
Access Protected Routes

Final Thoughts

Today we built the core components of JWT Authentication:

User Registration
Password Hashing
Password Verification
JWT Token Generation

A user can now register, log in, and receive a signed JWT token.

However, generating a token is only half the story.

The next step is learning how to validate tokens and protect routes using FastAPI dependencies.

In the next article, we'll implement JWT-based route protection and begin exploring Role-Based Access Control (RBAC).

FastAPI for AI Engineers - Part 5: Authentication vs Authorization (And Why Most Beginners Confuse Them)

Ananya S — Fri, 12 Jun 2026 17:23:27 +0000

In the previous article, we explored how Pydantic validates data before it enters our application.

For example, if an API expects a temperature value, sending text such as "Sunny" instead of a numeric value should be rejected.

Just as applications validate data before processing it, they must also validate users before granting access.

Not everyone should be able to access every endpoint or perform every action.

This brings us to two important concepts in backend development:

Authentication
Authorization

Although these terms are often used together, they solve different problems.

If you haven't read it already, check out the previous post to maintain continuity in the series and improve your understanding on FastAPI:

Ananya S

Jun 9

FastAPI for AI Engineers - Part 4: Stop Bad Data Before It Breaks Your API (Pydantic and Data Validation)

#ai #fastapi #backend #python

4 min read

Imagine entering an airport.

At the entrance, security checks your passport or government-issued ID to verify who you are.

This process is Authentication.

Once inside, not everyone can access every area.

Passengers can access waiting lounges, restaurants, and boarding gates.

Pilots, security personnel, and airport staff can access restricted areas that ordinary passengers cannot.

This process is Authorization.

The difference becomes clearer when we compare them side by side:

Authentication	Authorization
Verifies identity	Determines permissions
Answers "Who are you?"	Answers "What can you do?"
Happens first	Happens after authentication
Login credentials, tokens	Roles and permissions
Example: Logging into an app	Example: Accessing the admin dashboard

The following endpoint can be accessed by anyone:

from fastapi import FastAPI
app = FastAPI()

@app.get('/profile/')
def get_profile():
    return {'message': 'Your profile is here'}

There is no mechanism to verify who is making the request.

Whether the user is logged in or not, the endpoint remains accessible.

Authentication is the process of verifying a user's identity.

A typical authentication flow looks like this:

Login
  ↓
Username + Password
  ↓
Verify User
  ↓
Generate Token
  ↓
Access Protected Routes

Authentication


users = {
    "suman": "password123"
}

@app.post("/login")
def login(username: str, password: str):

    if users.get(username) == password:
        return {"message": "Login successful"}

    return {"message": "Invalid credentials"}

This is a simplified example used only to demonstrate the concept.

In real-world applications, passwords should never be stored in plain text and authentication is usually implemented using JWT tokens, OAuth, or other secure mechanisms.

Authentication confirms the identity of a user.

However, simply knowing who a user is does not determine what they are allowed to do.

This is where Authorization comes into play.

Authorization

users = {
    "suman": {
        "role": "admin"
    },
    "rahul": {
        "role": "student"
    }
}

@app.delete("/student/{id}")
def delete_student(id: int, current_user: dict):

    if current_user["role"] != "admin":
        return {"message": "Access denied"}

    return {"message": f"Student {id} deleted"}

To summarize:

Authentication -> Who are you?

Authorization -> What are you allowed to do?

Authentication and Authorization in AI Applications

Suppose you're building an AI-powered learning platform.

Authentication determines:

Which user is sending the request
Whether the user is logged in
Whether the access token is valid

Authorization determines:

Whether the user can access premium AI models
Whether the user can upload training datasets
Whether the user can view analytics dashboards
Whether the user can manage other users

Even if two users are authenticated, they may not have the same permissions.

This is why authentication and authorization are both essential in production AI systems.

User Request
      │
      ▼
Authentication
(Who are you?)
      │
      ▼
Authorization
(What can you do?)
      │
      ▼
Protected Resource

Final Thoughts

Authentication and Authorization are often mentioned together, but they solve different problems.

Authentication verifies identity.

Authorization determines permissions.

A user must first prove who they are before the system can decide what they are allowed to do.

In this article, we focused on understanding the concepts behind Authentication and Authorization.
JWT (JSON Web Tokens) is one of the most common approaches used to authenticate users in modern APIs.

In the next article, we'll move beyond theory and implement JWT-based Authentication in FastAPI step-by-step, allowing us to generate access tokens, protect routes, and identify users securely.

FastAPI for AI Engineers - Part 4: Stop Bad Data Before It Breaks Your API (Pydantic and Data Validation)

Ananya S — Tue, 09 Jun 2026 03:05:00 +0000

In the previous article, we connected our FastAPI application to a database using SQLite and SQLAlchemy.

We also used classes like:

class StudentCreate(BaseModel):
    name: str
    department: str
    cgpa: float

without fully understanding what was happening behind the scenes.

Today, we'll fix that.

If you haven't read it check it out:

FastAPI for AI Engineers - Part 3: Connecting to a database

Ananya S
Ananya S

Ananya S

Follow

Jun 6

FastAPI for AI Engineers - Part 3: Connecting to a database

#ai #fastapi #python #backend

7 reactions
2 comments

6 min read

Why Do We Need Data Validation?

Imagine you're building a weather application.

A user asks:

What is the temperature in Chennai?

A valid response might be:

35°C

But what if the API returns:

Sunny

This is clearly wrong.

Temperature should be represented as a number.

Even if the value itself is inaccurate, we still know that temperature must be numeric.

This is where validation becomes important.

Validation allows us to define rules about what data is acceptable before it enters our application.

For example:

Temperature should be numeric
Age cannot be negative
CGPA should be between 0 and 10
Email addresses should follow a valid format

Without validation, applications can receive invalid data and behave unexpectedly.

The Problem Without Validation

Consider a student registration API.

@app.post("/student")
def create_student(student):
    return student

A user could send:

{
    "name": "Ananya",
    "cgpa": "Excellent"
}

The API would accept it.

But a CGPA should be a number, not text.

As applications grow, manually checking every field becomes difficult.

We need a better solution.

Enter Pydantic

Pydantic is a Python library used for data validation.

FastAPI uses Pydantic extensively behind the scenes.

Instead of manually validating data, we define a schema.

from pydantic import BaseModel

class Student(BaseModel):
    name: str
    cgpa: float

Now FastAPI knows:

name must be a string
cgpa must be a floating-point number

Whenever data arrives, FastAPI automatically validates it.

Your First Pydantic Model

from pydantic import BaseModel

class Student(BaseModel):
    name: str
    department: str
    cgpa: float

Think of this model as a blueprint.

Any incoming request must follow this structure.

Valid Request

{
    "name": "Ananya",
    "department": "CSE",
    "cgpa": 8.9
}

Invalid Request

{
    "name": "Ananya",
    "department": "CSE",
    "cgpa": "Excellent"
}

FastAPI will reject the request automatically.

Using Pydantic with FastAPI

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Student(BaseModel):
    name: str
    department: str
    cgpa: float

@app.post("/student")
def create_student(student: Student):
    return student

Notice this line:

student: Student

FastAPI now expects the incoming request body to match the Student schema.

Understanding Validation Errors

Suppose we send:

{
    "name": "Ananya",
    "department": "CSE",
    "cgpa": "Excellent"
}

FastAPI returns a validation error before the request reaches our route.

You'll see an error similar to:

{
    "detail": [
        {
            "type": "float_parsing",
            "msg": "Input should be a valid number"
        }
    ]
}

Instead of failing silently, FastAPI clearly tells us what went wrong.

Adding Constraints with Field()

Validating types is useful.

But sometimes we need stricter rules.

For example:

CGPA should be between 0 and 10
Name should have a minimum length
Age should always be positive

Pydantic provides Field() for this purpose.

from pydantic import BaseModel, Field

class Student(BaseModel):

    name: str = Field(
        min_length=2,
        max_length=50
    )

    cgpa: float = Field(
        gt=0,
        lt=10
    )

Understanding the Constraints

cgpa: float = Field(gt=0, lt=10)

This means:

CGPA > 0
CGPA < 10

Valid Request

{
    "name": "Ananya",
    "cgpa": 8.9
}

Invalid Request

{
    "name": "Ananya",
    "cgpa": 15
}

FastAPI immediately rejects the request.

Optional Fields

Sometimes fields are not mandatory.

For example, a student may not have a department assigned yet.

from typing import Optional
from pydantic import BaseModel

class Student(BaseModel):

    name: str
    department: Optional[str] = None

Now the department field becomes optional.

Valid Request

{
    "name": "Ananya"
}

Also Valid

{
    "name": "Ananya",
    "department": "CSE"
}

Request Models vs Database Models

One question many beginners ask is:

Why do we need both schemas.py and models.py?

Let's understand the difference.

SQLAlchemy Model

class Student(Base):

    __tablename__ = "students"

    id = Column(Integer, primary_key=True)
    name = Column(String)
    cgpa = Column(Float)

This defines how data is stored in the database.

Pydantic Model

class StudentCreate(BaseModel):
    name: str
    cgpa: float

This defines how data enters our API.

Think of it this way:

Database Structure
        ≠
API Structure

They may look similar, but they serve different purposes.

Response Models

Pydantic can also control what data is returned from an API.

class StudentResponse(BaseModel):
    id: int
    name: str
    cgpa: float

@app.get(
    "/student/{id}",
    response_model=StudentResponse
)
def get_student(id: int):
    ...

This ensures the response always follows a consistent structure.

Why Pydantic Matters for AI Applications

Suppose you're building an LLM API.

Expected request:

{
    "prompt": "Explain FastAPI",
    "temperature": 0.7,
    "max_tokens": 500
}

Without validation, a user could send:

{
    "prompt": "Explain FastAPI",
    "temperature": "very creative",
    "max_tokens": "a lot"
}

and your application would have to deal with invalid data.

Pydantic prevents invalid requests from ever reaching your business logic.

This becomes especially important when building:

AI chatbots
RAG applications
Agentic systems
Model inference APIs
Multi-agent workflows

How Validation Fits into the Request Lifecycle

Client Request
      │
      ▼
Pydantic Validation
      │
      ▼
FastAPI Route
      │
      ▼
Business Logic
      │
      ▼
Database / LLM

Pydantic acts as the first line of defense.

Only valid data reaches the rest of the application.

Conclusion

Pydantic is one of the reasons FastAPI has become so popular. It allows us to build APIs that are safer, more predictable, and easier to maintain.

In the next article, we'll move into Authentication and Authorization and learn how to protect our APIs from unauthorized access.

FastAPI for AI Engineers - Part 3: Connecting to a database

Ananya S — Sat, 06 Jun 2026 06:27:51 +0000

In the previous article, we explored how to build our first CRUD API using FastAPI. While our API worked correctly, there was one major problem.

We were storing data inside Python lists, which exist only in memory.

If you've ever wondered how applications like Instagram, LinkedIn, or ChatGPT remember information even after a server restart, the answer is simple: databases.

In this article, we'll solve the problem of in-memory storage by connecting our FastAPI application to SQLite using SQLAlchemy.
If you haven't read the previous post, check it out:

Ananya S

Jun 1

FastAPI for AI Engineers - Part 2: Building Your First CRUD API

#ai #backend #fastapi #python

4 min read

By the end of this article, you'll understand:

Why in-memory storage is a problem
What SQLite is
What SQLAlchemy is
How ORM works
How to create database tables using Python classes
How to perform CRUD operations using a real database

The Problem with In-Memory Storage

Previously, our application stored students inside a Python list.

students = [
    {
        "id": 1,
        "name": "Ananya",
        "department": "CSE",
        "cgpa": 8.9
    }
]

This worked for learning CRUD operations.

However, consider what happens when the server restarts:

FastAPI Server Stops
        ↓
Python Memory Cleared
        ↓
All Student Data Lost

This is unacceptable in real-world applications.

We need a place where data can survive application restarts.

This is where databases come in.

What is SQLite?

SQLite is a lightweight relational database.

Unlike MySQL or PostgreSQL, SQLite doesn't require a separate database server.

Instead, everything is stored inside a single file.

students.db

Advantages of SQLite:

No installation required
Lightweight
Easy to learn
Perfect for local development
Great for small projects

For this article, we'll use SQLite.

What is SQLAlchemy?

Before SQLAlchemy, developers often wrote raw SQL queries.

Example:

SELECT * FROM students;

While SQL is powerful, writing queries everywhere quickly becomes difficult to maintain.

SQLAlchemy solves this problem using an ORM.

What is an ORM?

ORM stands for Object Relational Mapper.

It allows us to interact with database tables using Python classes.

Think of it like a translator.

Database	Python
Table	Class
Row	Object
Column	Attribute

For example:

Database table:

students

id     name     department     cgpa
1      Ananya   CSE            8.9

becomes:

class Student(Base):
    ...

Instead of writing SQL manually, we work with Python objects.

SQLAlchemy generates SQL behind the scenes.

Project Structure

Create the following structure:

project/
│
├── database.py
├── models.py
├── schemas.py
├── main.py
└── students.db

Each file has a specific responsibility.

database.py

Responsible for:

Database connection
Session creation
Base class creation

models.py

Responsible for:

Database tables

schemas.py

Responsible for:

Request validation
Response structure

main.py

Responsible for:

API routes
Business logic

Installing Dependencies

pip install sqlalchemy

If you haven't installed FastAPI yet:

pip install fastapi uvicorn

Step 1: Creating database.py

Create a file named database.py

from sqlalchemy import create_engine
from sqlalchemy.orm import declarative_base
from sqlalchemy.orm import sessionmaker

DATABASE_URL = "sqlite:///./students.db"

engine = create_engine(
    DATABASE_URL,
    connect_args={"check_same_thread": False} #allows the same connection to be used across threads
)

SessionLocal = sessionmaker(
    autocommit=False, 
    autoflush=False,
    bind=engine
)

Base = declarative_base()

Normally, SQLAlchemy uses transactional mode:
You make changes → they are staged in the session → you call commit() to persist them.
If autocommit is enabled, each statement is committed immediately (like SQLite’s default).
When autoflush=True (default), SQLAlchemy automatically flushes pending changes to the database before executing a query.
Flush means:
Synchronize in-memory changes with the database inside the current transaction.
Does not commit — changes are still rollback-able until you call commit().

Understanding create_engine()

engine = create_engine(...)

SQLAlchemy needs a way to communicate with the database.

The Engine object acts as the bridge between FastAPI and SQLite.

Whenever we:

insert data
retrieve data
update data
delete data

SQLAlchemy uses the engine to talk to the database.

Understanding SessionLocal

SessionLocal = sessionmaker(...)

A session represents a conversation with the database.

Imagine visiting a bank:

Start conversation
Perform transactions
End conversation

A database session works similarly.

Every database operation happens through a session.

Understanding Base

Base = declarative_base()

Every database model we create will inherit from Base.

SQLAlchemy uses Base to keep track of all models and create tables automatically.

Creating Database Sessions

Add this function below the previous code.

def get_db():

    db = SessionLocal()

    try:
        yield db

    finally:
        db.close()

Why Do We Need get_db()?

Without this function, every route would need to create and close sessions manually.

Example:

@app.get("/students")
def get_students():

    db = SessionLocal()

    # Database operations

    db.close()

This becomes repetitive.

Instead, FastAPI can automatically create and close sessions for us.

Later we'll use:

db: Session = Depends(get_db)

FastAPI will:

Create a session
Give it to the route
Close it automatically

This is called Dependency Injection.

Step 2: Creating models.py

Create a file named models.py

from sqlalchemy import Column, Integer, String, Float

from database import Base


class Student(Base):

    __tablename__ = "students"

    id = Column(Integer, primary_key=True, index=True)
    name = Column(String)
    department = Column(String)
    cgpa = Column(Float)

Understanding the Model

__tablename__ = "students"

This creates a table named:

students

id = Column(Integer, primary_key=True)

Creates the primary key.

Every student must have a unique ID.

name = Column(String)

Creates a text column.

The same applies to department.

cgpa = Column(Float)

Creates a floating-point column.

Step 3: Creating schemas.py

Create a file named schemas.py

from pydantic import BaseModel


class StudentCreate(BaseModel):
    name: str
    department: str
    cgpa: float


class StudentResponse(StudentCreate):
    id: int

    class Config:
        from_attributes = True

Why Do We Need Schemas?

Schemas define what data our API expects.

For now, think of schemas as blueprints.

We're using Pydantic behind the scenes.

We'll explore:

Validation
Optional fields
Custom validators
Response models

in a dedicated article later in this series.

Step 4: Creating main.py

from fastapi import FastAPI, Depends
from sqlalchemy.orm import Session

import models
import schemas

from database import engine, get_db

app = FastAPI()

models.Base.metadata.create_all(bind=engine)

Creating Tables Automatically

models.Base.metadata.create_all(bind=engine)

When FastAPI starts:

SQLAlchemy checks all models.
Looks for missing tables.
Creates them automatically.

Our Student table is now created inside SQLite.

CREATE Operation

@app.post("/student", response_model=schemas.StudentResponse)
def create_student(
    student: schemas.StudentCreate,
    db: Session = Depends(get_db)
):

    new_student = models.Student(
        name=student.name,
        department=student.department,
        cgpa=student.cgpa
    )

    db.add(new_student)

    db.commit()

    db.refresh(new_student)

    return new_student

What Happens Here?

db.add(new_student)

Adds the object to the session.

db.commit()

Permanently saves data to the database.

db.refresh(new_student)

Reloads the object from the database.

This is useful because the database automatically generates the ID.

READ Operation

Get all students.

@app.get("/students")
def get_students(
    db: Session = Depends(get_db)
):

    return db.query(models.Student).all()

Get a student by ID.

@app.get("/student/{id}")
def get_student(
    id: int,
    db: Session = Depends(get_db)
):

    return (
        db.query(models.Student)
        .filter(models.Student.id == id)
        .first()
    )

UPDATE Operation

@app.put("/student/{id}")
def update_student(
    id: int,
    updated_student: schemas.StudentCreate,
    db: Session = Depends(get_db)
):

    student = (
        db.query(models.Student)
        .filter(models.Student.id == id)
        .first()
    )

    if not student:
        return {"message": "Student not found"}

    student.name = updated_student.name
    student.department = updated_student.department
    student.cgpa = updated_student.cgpa

    db.commit()

    db.refresh(student)

    return student

DELETE Operation

@app.delete("/student/{id}")
def delete_student(
    id: int,
    db: Session = Depends(get_db)
):

    student = (
        db.query(models.Student)
        .filter(models.Student.id == id)
        .first()
    )

    if not student:
        return {"message": "Student not found"}

    db.delete(student)

    db.commit()

    return {"message": "Student deleted successfully"}

Running the Application

Start the server:

uvicorn main:app --reload

Open:

http://127.0.0.1:8000/docs

Use Swagger UI to:

Create students
Retrieve students
Update students
Delete students

SQLite vs MySQL

The good news is that SQLAlchemy makes switching databases extremely easy.

Current SQLite connection:

DATABASE_URL = "sqlite:///./students.db"

MySQL connection:

MYSQL_USER = "root"
DB_PASSWORD = "123456" # use your MySQL login password
MYSQL_HOST = 'localhost'
MYSQL_PORT = '3306'
MYSQL_DATABASE = 'fastapi_db'


DATABASE_URL = f"mysql+pymysql://{MYSQL_USER}:{DB_PASSWORD}@{MYSQL_HOST}:{MYSQL_PORT}/{MYSQL_DATABASE}"

Install the MySQL driver:

pip install pymysql

Everything else remains almost identical. Ensure you have MySQL in your desktop, open MySQL WorkBench and connect to database to see the database and tables in it. Ensure the database with the name 'fastapi_db' is already present in MySQL WorkBench.

This is one of the biggest advantages of using an ORM.

How Everything Works Together

Client Request
      │
      ▼
FastAPI Route
      │
      ▼
Pydantic Schema
      │
      ▼
Database Session
      │
      ▼
SQLAlchemy Model
      │
      ▼
SQLite / MySQL

When a user creates a student:

FastAPI receives the request
Pydantic validates the incoming data
A database session is created
SQLAlchemy converts the Python object into SQL
SQLite stores the data permanently

Conclusion

We've now moved beyond in-memory storage and built our first database-backed FastAPI application.
Most production AI applications use the same architecture, whether they're storing chat histories, user profiles, agent memory, evaluation results, or feedback data.

In the next article, we'll take a deeper look at Pydantic and understand how FastAPI validates incoming data automatically.

FastAPI for AI Engineers - Part 2: Building Your First CRUD API

Ananya S — Mon, 01 Jun 2026 17:06:06 +0000

In the previous article, we explored why FastAPI has become one of the most popular backend frameworks for modern AI applications.

If you haven't read the previous post, check it out: https://dev.to/zeroshotanu/fastapi-for-ai-engineers-part-1-why-every-ai-backend-is-moving-toward-fastapi-45fg

Now it's time to build something practical.

Most backend applications revolve around four basic operations:

Create
Read
Update
Delete

Together, these operations are known as CRUD.

Whether you're building:

a social media application,
an e-commerce platform,
a chatbot,
or an AI agent,

CRUD operations are the foundation of backend development.

In this article, we'll build a simple Student Management API while learning:

Path Parameters
Query Parameters
GET Requests
POST Requests
PUT Requests
DELETE Requests

Creating Sample Data

Let's start with a small dataset.

from fastapi import FastAPI

app = FastAPI()

students = [
    {
        "id": 1,
        "name": "Ananya",
        "department": "CSE",
        "cgpa": 8.9
    },
    {
        "id": 2,
        "name": "Rahul",
        "department": "ECE",
        "cgpa": 8.4
    },
    {
        "id": 3,
        "name": "Priya",
        "department": "IT",
        "cgpa": 9.1
    }
]

Run the application:

uvicorn main:app --reload

Open Swagger UI:

http://127.0.0.1:8000/docs

Path Parameters

A path parameter is part of the URL itself.

/student/2

Here, 2 is the path parameter.
Think of path parameters as:

"I know exactly which resource I want."

Examples:

/users/10
/products/25
/orders/1001
/student/2

Let's fetch a specific student using their ID.

@app.get("/student/{id}")
def get_student_info(id: int):

    for user in students:
        if user["id"] == id:
            return user

    return {"message": "Student not found"}

Request:

/student/2

Response:

{
    "id": 2,
    "name": "Rahul",
    "department": "ECE",
    "cgpa": 8.4
}

Query Parameters

A query parameter appears after the ? in a URL.

/student?department="CSE"

They are commonly used for:

filtering
searching
sorting
pagination

Let's implement the same endpoint using a query parameter.

@app.get("/students")
def get_students(department: str):

    filtered_students = []

    for student in students:
        if student["department"] == department:
            filtered_students.append(student)

    return filtered_students

Request:

/student?department="CSE"

Response:

{
    "id": 1,
    "name": "Ananya",
    "department": "CSE",
    "cgpa": 8.9
}

All students in CSE department would be filtered.
Query parameters are often optional and are used to modify, filter, or search results.

Path vs Query Parameters

Path Parameter	Query Parameter
Part of URL path	Appears after ?
Identifies a resource	Filters or searches
`/student/1`	`/student?id=1`

GET Request

GET requests are used to retrieve data.

@app.get("/students")
def get_all_students():
    return students

Response:

[
    {
        "id": 1,
        "name": "Ananya",
        "department": "CSE",
        "cgpa": 8.9
    },
    {
        "id": 2,
        "name": "Rahul",
        "department": "ECE",
        "cgpa": 8.4
    },
    {
        "id": 3,
        "name": "Priya",
        "department": "IT",
        "cgpa": 9.1
    }
]

Request Bodies with Pydantic

When users send data to our API, FastAPI needs a way to validate that the incoming data has the correct structure.

This is where Pydantic comes in.

Pydantic allows us to define the expected shape of incoming data using Python classes.

For example, every student should have:

an ID
a name
a department
a CGPA

We can define this structure using a Pydantic model.

from pydantic import BaseModel

class Student(BaseModel):
    id: int
    name: str
    department: str
    cgpa: float

Now FastAPI automatically validates incoming requests.

For example, this request is valid:

{
"id": 4,
"name": "Karthik",
"department": "AI",
"cgpa": 8.8
}

But if someone sends:

{
"id": "four",
"name": "Karthik"
}

FastAPI will automatically return a validation error because:

id should be an integer
required fields are missing

This saves us from writing validation code manually.
We'll explore Pydantic, validation, optional fields, custom validators, and advanced request handling in a dedicated article later in this series.

POST Request

POST requests are used to create new resources.

from pydantic import BaseModel

class Student(BaseModel):
    id: int
    name: str
    department: str
    cgpa: float

@app.post("/student")
def add_student(student: Student):

    students.append(student.dict())

    return {
        "message": "Student added successfully",
        "student": student
    }

Request Body:

{
    "id": 4,
    "name": "Karthik",
    "department": "AI",
    "cgpa": 8.8
}

PUT Request

PUT requests are used to update existing resources.

@app.put("/student/{id}")
def update_student(id: int, updated_student: Student):

    for index, user in enumerate(students):

        if user["id"] == id:

            students[index] = updated_student.dict()

            return {
                "message": "Student updated successfully",
                "student": updated_student
            }

    return {"message": "Student not found"}

Request:

PUT /student/2

DELETE Request

DELETE requests are used to remove resources.

@app.delete("/student/{id}")
def delete_student(id: int):

    for index, user in enumerate(students):

        if user["id"] == id:

            deleted_student = students.pop(index)

            return {
                "message": "Student deleted successfully",
                "student": deleted_student
            }

    return {"message": "Student not found"}

Request:

DELETE /student/3

CRUD Summary

Operation	HTTP Method
Create	POST
Read	GET
Update	PUT
Delete	DELETE

CRUD operations form the foundation of almost every backend application you'll build.

What's Next?

Right now, our data exists only in memory.

If the server restarts, everything disappears.

In the next article, we'll connect FastAPI with SQLite and MySQL so our application can store data permanently, just like real-world production systems.

FastAPI for AI Engineers — Part 1: Why Every AI Backend Is Moving Toward FastAPI

Ananya S — Fri, 29 May 2026 17:57:34 +0000

You open ChatGPT.

You type a prompt.

Within seconds:

your request reaches a backend server,
the backend communicates with an LLM,
retrieves memory,
queries vector databases,
processes context,
and streams responses back to you in real time.

Modern AI applications are no longer just “apps.”

They are systems made up of multiple services constantly communicating with each other through APIs.

And one framework has quietly become the default choice for building these modern AI backends:

FastAPI.

In this article, we’ll understand:

why APIs are essential,
why modern AI systems depend heavily on them,
what FastAPI actually is,
and why it became the preferred backend framework for AI engineers.

Modern Applications Are API Systems

Most applications today are distributed systems.

Your frontend, backend, database, authentication service, payment gateway, and AI models continuously exchange data with one another.

When you order food online:

Frontend → Backend API → Database → Response

When you use an AI chatbot:

User → FastAPI Backend → LLM → Vector DB → Response

Without APIs:

frontend applications would directly access databases,
systems would become tightly coupled,
security would become difficult,
scaling would become messy,
and AI applications would be extremely difficult to maintain.

APIs act as communication bridges between systems.

They define:

how requests are sent,
what data is expected,
and what responses should be returned.

Modern software runs on APIs.

Modern AI systems depend on them even more.

What Exactly Is an API?

API stands for Application Programming Interface.

In simple terms:

An API allows two software systems to communicate with each other.

For example:

a frontend sends a request,
the backend processes it,
and returns a response (usually JSON).

Example:

{
    "message": "Hello World"
}

Every major application you use today relies heavily on APIs:

Instagram
Netflix
Uber
Spotify
ChatGPT
AI agents
recommendation systems
RAG applications

APIs are the foundation of modern backend engineering.

Why AI Applications Changed Backend Development

Traditional web applications were already API-heavy.

But AI applications introduced entirely new backend challenges.

Modern AI systems constantly:

communicate with LLM APIs,
query vector databases,
retrieve embeddings,
stream responses,
interact with external tools,
and handle concurrent requests.

This created a need for backend frameworks that were:

lightweight,
fast,
asynchronous,
scalable,
and developer-friendly.

That’s where FastAPI entered.

What Is FastAPI?

FastAPI is a modern Python framework designed specifically for building APIs.

It became popular because it combines:

high performance,
async support,
automatic validation,
clean developer experience,
and excellent scalability.

FastAPI is built on top of:

Starlette → provides ASGI and async capabilities
Pydantic → handles data validation
Uvicorn → runs FastAPI applications efficiently

Together, this stack became perfect for modern AI systems.


        Client Request
               │
               ▼
         ┌─────────┐
         │ FastAPI │
         └────┬────┘
              │
     ┌────────┼────────┐
     ▼                 ▼
 Starlette         Pydantic
 (ASGI/Async)     (Validation)
              │
              ▼
           Uvicorn
        (ASGI Server)

Why FastAPI Became the Standard for AI Backends

1. Async Support

This is one of the biggest reasons FastAPI exploded in popularity.

AI applications constantly wait for:

LLM responses,
vector database retrieval,
external APIs,
embeddings,
cloud services.

FastAPI supports asynchronous programming using Python’s async and await.

Example:

async def generate_response():
    return {"message": "Async response"}

Instead of blocking the server while waiting for responses, FastAPI can efficiently handle multiple requests concurrently.

For AI systems, this matters a lot.

2. Built on Starlette

FastAPI uses Starlette underneath.

Starlette provides:

ASGI support,
middleware,
WebSockets,
background tasks,
async request handling.

This makes FastAPI much better suited for modern real-time AI applications compared to older synchronous architectures.

3. Powered by Uvicorn

FastAPI applications are commonly run using Uvicorn.

Start a FastAPI server using:

uvicorn main:app --reload

Here:

main → filename
app → FastAPI instance
--reload → automatically reloads during development

Uvicorn is an ASGI server optimized for high-performance asynchronous applications.

4. Automatic Swagger UI Documentation

One of FastAPI’s most loved features is automatic API documentation.

The moment you create routes, FastAPI automatically generates interactive API documentation for you.

Visit:

http://127.0.0.1:8000/docs

You can:

test endpoints,
send requests,
inspect responses,
and debug APIs directly from the browser.

This becomes incredibly useful when:

working with frontend developers,
building AI APIs,
or testing backend systems quickly.

5. Automatic Data Validation Using Pydantic

FastAPI uses Python type hints for validation.

Example:

from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int

If invalid data is sent, FastAPI automatically validates and rejects it.

This removes a huge amount of manual validation code developers previously had to write themselves.

Installing FastAPI

Install FastAPI and Uvicorn:

pip install fastapi uvicorn

Your First FastAPI Application

Create a file called main.py

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def home():
    return {"message": "Welcome to Dev.io"}

Run the server:

uvicorn main:app --reload

Open:

http://127.0.0.1:8000/docs

And you’ll see FastAPI’s automatically generated Swagger UI.

At this point, you already have:

a running backend server,
a working API,
and interactive API documentation.

With surprisingly little code.

Why FastAPI Matters for AI Engineers

FastAPI became extremely popular because modern AI applications are fundamentally API systems.

It is heavily used for:

RAG pipelines,
AI agents,
chatbot backends,
LangChain applications,
vector database APIs,
recommendation systems,
and model-serving APIs.

Modern AI engineering is not just about building models anymore.

It’s also about building scalable systems around those models.

And FastAPI fits perfectly into that ecosystem.

Final Thoughts

FastAPI didn’t become popular accidentally.

It became the framework of choice for AI engineers because modern AI systems are:

asynchronous,
API-driven,
performance-sensitive,
and highly modular.

Whether you're building:

AI agents,
chat systems,
RAG applications,
or production AI platforms,

FastAPI provides the exact architecture modern AI applications need.

What’s Next?

Right now, our API returns data, but it doesn’t actually store anything permanently.

In the next article, we’ll build real CRUD APIs using FastAPI and understand:

GET requests,
POST requests,
PUT requests,
DELETE requests,
and how backend applications manage data.

Then we’ll move toward integrating databases like SQLite and MySQL in the following parts of this series.

Check out the next post here:
https://dev.to/zeroshotanu/fastapi-for-ai-engineers-part-2-building-your-first-crud-api-lpl

DEV Community: Ananya S

Introducing NovaDesk AI: Building a Stateful Hotel Concierge with LangGraph

Anucool419 / NovaDesk_AI

🛎️ AI Hotel Concierge (LangGraph + FastAPI)

🏗️ Architecture Overview

System Architecture

✨ Key Features

What is NovaDesk AI?

1. Smart Policy Q&A (RAG)

2. Live Room Availability & Bookings

3. Stateful Cancellations

4. Room Service Integration

5. Persistent Memory

The Tech Stack (At a Glance)

Taking it Live

What's Next in this Series?

FastAPI for AI Engineers - Part 10: Mastering FastAPI: Scaling with APIRouters and Background Tasks

FastAPI for AI Engineers — Part 1: Why Every AI Backend Is Moving Toward FastAPI

1. APIRouters: Organizing Your Monolith

2. Background Tasks: Beating AI Latency

FastAPI for AI Engineers - Part 9: Mastering HTTP Exceptions & Status Codes

The Core Status Codes You Need to Know

1. 404 Not Found

2. 400 Bad Request

3. 401 Unauthorized (Authentication)

4. 403 Forbidden (Authorization)

Why This Matters

FastAPI for AI Engineers - Part 8: Uploading Files with FastAPI

Why Do We Need File Uploads?

Installing Required Package

Your First File Upload API

Creating the Upload Endpoint

Understanding UploadFile

Reading File Contents

Saving Uploaded Files

AI Workflow Example

UploadFile vs bytes

Complete Example

Workflow Recap

Final Thoughts

I Built an End-to-End Mortgage Loan Analytics Dashboard with Python & Power BI

Why I Built This Project

Tech Stack

Project Architecture

Step 1 — Generating Realistic Data

Step 2 — Data Cleaning with Power Query

Step 3 — Building a Star Schema

Step 4 — Writing Business KPIs with DAX

Portfolio KPIs

Risk KPIs

Payment KPIs

Dashboard Pages

Executive Overview

Customer & Loan Analysis

Risk & Payment Analysis

Business Insights

The Most Valuable Lesson

Skills Practiced

Final Thoughts

GitHub Repository

FastAPI for AI Engineers - Part 7: Protecting Routes with JWT Tokens

FastAPI for AI Engineers - Part 6: JWT Authentication in FastAPI

The Problem

Authentication Flow

Extracting the Token

OAuth2PasswordBearer

Decoding JWT Tokens

Creating get_current_user()

Protecting Routes

Visual Flow

Conclusion

FastAPI for AI Engineers - Part 6: JWT Authentication in FastAPI

FastAPI for AI Engineers - Part 5: Authentication vs Authorization (And Why Most Beginners Confuse Them)

Why Do We Need Authentication?

What is JWT?

Installing Required Packages

Step 1: Hashing Passwords

Creating a Password Hasher

What is CryptContext?

Hashing a Password

1. `404 Not Found`

2. `400 Bad Request`

3. `401 Unauthorized (Authentication)`

4. `403 Forbidden (Authorization)`

If you haven't read it check it out:

FastAPI for AI Engineers - Part 3: Connecting to a database

Ananya S
Ananya S

Ananya S

Follow

Jun 6

FastAPI for AI Engineers - Part 3: Connecting to a database

#ai #fastapi #python #backend

7 reactions
2 comments

6 min read