DEV Community: Ananya S

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

How I Built an AI-Powered Incident RCA Platform with LangGraph and RAG

Ananya S — Tue, 26 May 2026 03:23:00 +0000

It’s 2:13 AM.

A payment API suddenly starts failing in production.

Customers can’t complete transactions. Alerts begin firing everywhere. Dashboards turn red. Kubernetes pods restart unexpectedly. Database connections start timing out.

And somewhere, an exhausted engineer opens Datadog and starts scrolling through thousands of logs trying to answer a single question:

“What actually broke?”

Modern systems generate enormous amounts of telemetry:

logs
alerts
traces
metrics
infrastructure events

The problem isn’t the lack of monitoring anymore.

The problem is:

making sense of the chaos quickly enough during an outage.

That idea became the starting point for OpsMind AI — an AI-powered incident root cause analysis platform inspired by real-world DevOps and Site Reliability Engineering workflows.

The goal was ambitious but simple:

Upload observability logs → identify probable root cause → generate remediation recommendations automatically.

The Core Problem

In modern distributed systems, a single failure rarely stays isolated.

A database lock might cause:

API latency spikes
gateway timeouts
downstream service crashes
Kubernetes restarts

During incidents, engineers manually jump between:

Grafana dashboards
Datadog alerts
New Relic traces
raw log streams

trying to correlate failures across services.

This process is:

time-consuming
mentally exhausting
highly dependent on experience

I wanted to explore whether multi-agent AI systems could assist in this process.

Not just summarizing logs.

But actually:

retrieving similar historical incidents
classifying incident severity
reconstructing event timelines
identifying affected services
generating RCA explanations
suggesting remediation steps

Enter OpsMind AI

OpsMind AI simulates an AI-driven observability assistant for SRE and DevOps teams.

The platform processes observability logs through a LangGraph-based multi-agent workflow that orchestrates specialized agents for different operational tasks.

Instead of relying on a single monolithic LLM prompt, the system breaks incident investigation into multiple coordinated reasoning stages.

System Architecture

The workflow begins by ingesting logs from simulated monitoring platforms such as:

Datadog
Grafana
New Relic

The logs are normalized and passed into a multi-agent orchestration pipeline.

The architecture consists of:

Retrieval Agent

Searches historical incidents using FAISS vector similarity search.

Incident Classification Agent

Identifies:

incident type
severity level
monitoring source

RCA Agent

Performs root cause analysis and generates remediation recommendations using LLM reasoning.

Timeline & Impact Analysis

Reconstructs operational event sequences and identifies affected downstream services.

Evaluation Layer

Measures:

retrieval accuracy
RCA quality
latency
incident correlation confidence

The frontend dashboard was built using Streamlit to simulate an operational observability console.

Why RAG Was Important Here

One of the most interesting parts of the project was integrating retrieval-augmented generation.

Production incidents often repeat patterns:

database pool exhaustion
API rate limiting
Kubernetes OOM crashes
retry storms
deadlocks

Instead of asking the LLM to reason from scratch every time, OpsMind AI retrieves semantically similar historical incidents from a FAISS vector database and uses them as contextual memory during RCA generation.

This significantly improved the consistency of generated analyses.

Building the Multi-Agent Workflow

The orchestration layer uses LangGraph to model incident analysis as a graph of specialized AI agents.

This made the workflow:

modular
explainable
easier to visualize

One thing I particularly enjoyed was building the animated agent execution dashboard where each agent executes sequentially:

Retrieval Agent
Classification Agent
RCA Agent
Timeline Agent
Impact Analysis Agent

Watching the workflow execute in real time made the system feel much closer to an actual operational AI assistant rather than just another chatbot interface.

Simulating Real Production Incidents

Since real enterprise observability data isn’t publicly available, I generated synthetic production-style incident logs for:

Kubernetes CrashLoopBackOff failures
database connection exhaustion
API rate limiting failures
downstream gateway crashes

The architecture was intentionally designed so that simulated connectors can later be replaced with real monitoring APIs.

Evaluation Was Surprisingly Hard

One unexpected realization during development:

Building the RCA pipeline was easier than evaluating it.

It’s very easy to generate convincing AI explanations.

It’s much harder to measure:

whether the RCA is actually correct
whether retrieval is meaningful
whether severity classification is reliable

That’s why I added an evaluation layer measuring:

Retrieval Accuracy
RCA Match Accuracy
Severity Accuracy
Average Latency
Correlation Confidence

Adding evaluation made the project feel significantly more engineering-focused rather than simply prompt-driven.

Tech Stack

Python
Streamlit
LangGraph
FAISS
SentenceTransformers
Groq LLM API
Pandas

Building Under Hackathon Constraints

OpsMind AI was originally built during a short-duration engineering hackathon focused on AI agents and developer infrastructure workflows.

One interesting challenge was balancing:

ambitious system design ideas
realistic implementation scope
evaluation reliability
UI polish
deployment constraints

I wanted the project to feel less like a simple LLM wrapper and more like an actual operational intelligence platform, which is why I focused heavily on:

multi-agent orchestration
retrieval systems
evaluation metrics
workflow visualization
observability-inspired architecture

Even within a constrained timeline, building the system end-to-end — from synthetic telemetry generation to agent orchestration and evaluation — was an incredibly valuable learning experience.

What I Learned

This project taught me a lot about:

observability systems
multi-agent orchestration
RAG pipelines
AI evaluation strategies
operational intelligence workflows

More importantly, it changed how I think about AI systems.

The interesting challenge wasn’t generating text.

It was designing systems that:

reason through operational data
coordinate specialized agents
retrieve contextual memory
produce actionable outputs

That feels much closer to how real-world AI systems will evolve.

Demo & Repository

GitHub Repository

https://github.com/Anucool419/OpsMind-AI

Demo Video

Future Improvements

Some things I’d love to explore next:

real-time telemetry ingestion
live Datadog/New Relic integrations
Slack incident alerting
autonomous remediation workflows
distributed tracing support
long-term incident memory systems

Conclusion

What started as a simple idea — “Can AI help investigate production incidents faster?” — turned into a much deeper exploration of how intelligent systems can assist engineering operations.

The most interesting part of building OpsMind AI wasn’t the UI or even the LLM integration.

It was understanding how modern operational systems actually behave:

cascading failures
noisy telemetry
infrastructure dependencies
repeated incident patterns
operational uncertainty

This project made me realize that the future of AI in engineering is not just about chat interfaces.

It’s about building systems that can:

reason over complex environments
retrieve operational memory
coordinate specialized agents
assist humans during high-pressure decision making

OpsMind AI is still a prototype, but building it gave me a much deeper appreciation for:

observability engineering
SRE workflows
AI orchestration systems
evaluation-driven AI development

And honestly, that combination of AI + systems engineering is one of the most exciting areas to explore right now. Do suggest any improvements you think I should make or share your experiences.

Thanks for reading.

🚀 This AI Tells You What to Study for Exams

Ananya S — Mon, 04 May 2026 17:45:51 +0000

Consider this:

It’s 3 days before your exam.
You have 5 units. 2 are huge. 1 is confusing.
And you’re thinking:

“What do I actually study?”

So you open past papers.

You start spotting patterns… maybe.

But it’s slow. Inconsistent. And honestly — a bit of guessing.

💡 What if that entire process was automated?

What if you could:

Upload past papers 📄
Instantly see what matters most
Identify high-weightage topics
Know what’s missing from your prep
Get a day-wise study plan

And that's the solution I built and prototyped in 6 hours during a GenAI hackathon

🎯 Introducing: AI Exam Strategist

A system that analyzes past question papers and turns them into actionable study strategy.

Not just summaries. Not just answers.

👉 Actual decision-making support for exams.

🧠 What It Does

📂 Multi-Paper Analysis

Upload multiple past papers → the system processes them together and extracts meaningful patterns.

🔍 Pattern Detection

Finds frequently asked topics
Classifies difficulty levels
Identifies year-wise trends

👉 Helps you focus on topics with the highest exam impact

📚 Syllabus Mapping

Upload your syllabus → instantly see:

✅ Topics already appearing in exams
❌ Topics not covered (potential blind spots)

📊 Visual Insights

Topic frequency charts
Difficulty distribution
Topic vs difficulty breakdown
Year-wise trends

👉 Patterns become obvious at a glance

🧠 Smart Study Planner

Generates a day-wise plan based on:

available time
topic importance

👉 Designed for maximum ROI under time constraints

📝 Practice Question Generator

Select a topic → generate relevant practice questions instantly.

💬 AI Assistant

Ask:

“What should I prioritize?”

Get answers grounded in your own analyzed data.

🏗️ Tech Stack

FastAPI → backend APIs
Streamlit → interactive UI
Groq API (LLM) → classification & generation
LangGraph → structured workflow orchestration
Pandas → data processing

⚙️ How It Works

Upload Papers → Extract Questions → Classify (Topic + Difficulty)
→ Analyze Patterns → Map with Syllabus → Generate Insights
→ Create Study Plan → Practice + AI Chat

🤔 Did I Use RAG?

Not in this version.

Since the dataset is relatively small, I used:
👉 context injection (passing structured analysis directly to the LLM)

This keeps the system fast and simple.

For larger-scale usage, this can evolve into a RAG-based system with vector search.

📏 Evaluation (Keeping It Real)

I added a basic evaluation layer to understand how the system behaves.

Used a small, manually created dataset
Measured:
- Topic classification
- Difficulty classification

⚠️ Important:

Accuracy may appear low if you try it yourself
Because:
- dataset is small
- matching is strict (semantic matches may be marked wrong)

👉 The goal wasn’t perfect scoring —
but to validate the system’s reasoning and consistency

🧠 What I Learned

Building GenAI systems is more about pipelines than prompts
LLM outputs are messy — normalization is critical
Evaluation in AI is not straightforward
Simple approaches (like context injection) can outperform complex ones for MVPs
Speed + clarity > overengineering

🔮 Future Improvements

OCR for scanned PDFs
Semantic topic matching using embeddings
Persistent memory across sessions
Scalable deployment

🎥 Demo & Links

🔗 GitHub: https://github.com/Anucool419/AI-Exam_Strategist
🎥 Demo Video: https://www.loom.com/share/04005565701e45d1855d1fa13bcee73a
🌐 Live App: https://ai-examstrategist-ryjarq6usrfbsd85gipexy.streamlit.app/

⚠️ Note: The live demo UI is deployed, but the backend runs locally. Full functionality is shown in the demo video.

🏁 Final Thoughts

Exams aren’t just about how much you study.

They’re about:

what you choose to study
how you prioritize
how well you use limited time

And right now, students are expected to figure that out manually.

This project explores a simple idea:

What if AI could guide those decisions?

Not replace studying.
Not shortcut learning.

But make preparation more focused, more intentional, and more efficient.

Because sometimes, the smartest move…
is knowing what not to study.

In ~6 hours, this went from an idea to a working system.

It’s not perfect — but it solves a real problem:

Maximizing study ROI when time is limited

Would love your thoughts 👇

🚀 I Built an AI-Powered Fest Assistant with Agents, RAG & Planning (Pragyan @ NITT)

Ananya S — Tue, 14 Apr 2026 17:57:01 +0000

I deleted Instagram more than a year ago, and honestly, it saved me from a lot of distractions.

But there was an unexpected downside.

A lot of informal, real-time information — especially during college events — still lives there.

During our college fest, for example:

Event schedules
Last-minute updates
Food stall announcements
Informal activities

…everything gets posted on Instagram.

At the same time:

Fest details and significance are on the official website
Food stall info is on a separate app
The entire 3-day schedule is compressed into a few posts

There’s no single place to get a clear, structured view of everything.

And that’s when it hit me:

Most college fests have websites.
Some even have apps.

But none of them actually help you navigate the fest intelligently.

They give information.
They don’t give guidance.

But I wanted to build something smarter —
an AI assistant that actually understands queries, plans your day, and even helps you find teammates.

So, I built Pragyan Mentor Assistant — an AI-powered system for navigating a techno-managerial fest.

🎯 Problem

During college fests like Pragyan (NIT Trichy):
There are

There are dozens of events, workshops, and shows
Information is scattered across PDFs, sites, and posters
Users don’t know:
- what to attend
- what matches their interests
- how to plan their time
- who to team up with

👉 Traditional apps = static information
👉 I wanted intelligent interaction

💡 Solution

I built a multi-tool AI assistant that can:

🎉 Answer questions about events, workshops, proshows
🍔 Show food stalls & mess menu
🧠 Recommend activities based on user intent
📅 Plan your schedule
🤝 Match you with like-minded participants/Suggest potential teammates (prototype)
📚 Answer fest-related questions using RAG

🧠 System Design

Instead of a simple chatbot, I designed it as a tool-using agent system.

🔹 Tools

fetch_events
fetch_workshops
fetch_food_stall
fetch_mess_menu
pragyan_bot (RAG-based)
smart_recommender
planner
buddy_matcher

🔹 Agent Flow

User query
LLM decides:

Which tool to call
1. Tool executes
2. Response is generated in natural language

📚 Retrieval Approach

This system uses a hybrid retrieval strategy at the system level:

Structured retrieval (keyword-based)
- Direct tool calls for events/workshops
- Fast and deterministic
Semantic retrieval (RAG)
- Vector search over fest documents
- Handles open-ended queries

👉 This combination allows both precision and flexibility

📚 RAG (Retrieval Augmented Generation)

To handle fest knowledge:

Used:
- Text files (events, shows, lectures, FAQs)
Built:
- FAISS vector store
Retrieval:
- Semantic search on query
Response:
- Context-aware answers

🧠 Memory

Using:

InMemorySaver() (LangGraph)

👉 Enables:

remembering user preferences
better recommendations
conversational continuity

🤖 Smart Features

🎯 Recommendations

Understands intent like:

"What should I attend if I like tech and fun?"

📅 Planner Agent

"Plan my next 3 hours"

Generates a structured schedule based on:

time
interests
available events

🤝 Buddy Matching (Prototype)

Matches based on:

interests
level
context (e.g. case study competitions)

Uses a small dataset to demonstrate logic

🖥️ UI

Built with Streamlit:

Chat-based interface
Quick action buttons
Structured responses

🚀 Deployment

Deployed on Render (free tier)
Environment variables for API security

🎥 Demo

👉 https://www.loom.com/share/13f87025a9154a55b80fc240bfc91ba2

🛠️ Tech Stack

Python
LangChain
OpenAI API
FAISS
Streamlit
Render

⚠️ Challenges Faced

RAG retrieval quality (chunking + parsing issues)
Tool selection accuracy
Structuring multi-agent workflow
Deployment + API key handling

🔄 Ongoing Improvements

Some features I’m actively working on:

Adding database-backed user profiles for real buddy matching
Improving RAG with better retrieval and evaluation
Expanding dataset coverage for more complete fest information
Exploring true hybrid retrieval + reranking

📈 What I Learned

Building agents > building chatbots
RAG needs data structuring, not just embeddings
UI matters a lot for perceived intelligence
Deployment and debugging are part of the real challenge

🔗 Links

🔒 Live demo available on request

💭 Final Thoughts

This project made me realize:

👉 The future isn’t just about LLMs
👉 It’s about systems built around them

If you have suggestions or ideas to improve this, I’d love to hear them!

Stop Calling FAISS a Database: The VectorStore vs. VectorDB Showdown🧠⚡

Ananya S — Tue, 17 Mar 2026 16:40:58 +0000

If you’ve been building with LangChain, you’ve probably used Chroma or FAISS and called them "databases." But in a production environment, that distinction could be the difference between a smooth app and a total system crash.

As AI Engineers, we need to know when to use a lightweight VectorStore and when to upgrade to a full Vector Database.

What is a VectorStore? (The Engine)

A VectorStore is a specialized data structure or a local library. Its primary job is simple: Calculate the distance between vectors as fast as possible.

Best for: Prototypes, local research, and small datasets.
Pros: Zero latency (runs in-process), easy to set up, free.
Cons: If your app restarts, your data might vanish (if not saved to disk). It doesn't scale across multiple servers easily.

Popular Choice: FAISS (by Meta). It's incredibly fast but lacks "database" features like user authentication or real-time updates.

from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

# 1. Initialize Embeddings
embeddings = OpenAIEmbeddings()

# 2. Create the VectorStore (In-memory)
texts = ["AI is transforming civil engineering", "LangChain is a framework for LLMs"]
vector_store = FAISS.from_texts(texts, embeddings)

# 3. Search (Fast, but only local)
query = "What is LangChain?"
results = vector_store.similarity_search(query)

# 4. Persistence (Manual step required)
vector_store.save_local("my_faiss_index") 
# To use it later, you must load_local() manually

What is a Vector Database? (The Full System)

A Vector Database is a production-ready management system. It uses a vector store under the hood but wraps it in the features we expect from enterprise software.

Best for: Production apps, multi-user systems, and massive datasets (millions of vectors).

The "Extras" you get:

Persistence: Your data lives on a server, not just in your RAM.
Metadata Filtering: The ability to say "Find similar vectors, but only for documents created in 2024."
Scalability: It can handle billions of vectors by spreading them across different "pods" or nodes.

Popular Choice: Pinecone or Weaviate.

from langchain_pinecone import PineconeVectorStore
from pinecone import Pinecone

# 1. Initialize Cloud Client
pc = Pinecone(api_key="YOUR_PINECONE_API_KEY")
index_name = "my-production-index"

# 2. Connect to the Index (Data lives on Pinecone's servers)
vector_db = PineconeVectorStore.from_texts(
    texts=["B.Tech students at NITT are building AI agents"],
    embedding=OpenAIEmbeddings(),
    index_name=index_name
)

# 3. Search (API Call to the cloud)
# Anyone with the API key can now query this from any device
results = vector_db.similarity_search("Who is building agents?")

Key Observation: There is no "save" step. The moment you run from_texts, the data is permanently stored in the cloud. You can delete your local code, and the data remains accessible.

Feature	VectorStore (e.g., FAISS, Chroma)	Vector Database (e.g., Pinecone, Milvus)
Architecture	A library that runs inside your application code.	A standalone distributed system running on a server.
Data Persistence	Mostly In-Memory. Data is lost when the script ends.	Persistent by default. Data is stored on cloud/disk.
Scalability	Limited by your machine's RAM/Disk. Hard to scale.	Built for Horizontal Scaling. Handles billions of vectors.
Multi-tenancy	No built-in support for isolated users.	High. Supports multiple users and isolated indexes.
CRUD Operations	Hard to update specific vectors without rebuilding.	Full Create, Read, Update, Delete support via API.
Metadata	Basic filtering capabilities.	Advanced Metadata Filtering (e.g., Filter by date).
Cost	Free (Uses your local resources).	Tiered. Free tiers available, then paid.

Let's Discuss!
Are you currently using a local store like Chroma or have you made the jump to a cloud database? What's the biggest challenge you've faced with vector scaling? Drop a comment below! 👇

Decoding Embedding Models: Why Your RAG Is Only as Good as Your Vectors 🚀

Ananya S — Mon, 09 Mar 2026 17:36:43 +0000

As an AI Engineer, the first major decision you make in a RAG (Retrieval-Augmented Generation) pipeline isn't which LLM to use—it's which Embedding Model will represent your data. If your vectors are low-quality, your retrieval will fail, and even a top-tier LLM can't save a response based on the wrong context.

🏗️ What exactly is an Embedding?

Embedding models take text tokens and map them into a multi-dimensional coordinate system (vectors).

Dimensions: These represent the "features" the model understands. Different models represent words in vectors of different dimensions.

Semantic Proximity: In a good model, the vector for "King" and "Queen" will be mathematically closer than "King" and "Keyboard."

🌟 Popular Embedding Models: Hugging Face

Hugging Face models are the go-to for privacy, local deployment, and cost-efficiency. Here are the top picks:

1. all-MiniLM-L6-v2

Dimensions: 384
Description: Fast, efficient, and good quality.
Use Case: General purpose; ideal for real-time applications.

2. all-mpnet-base-v2

Dimensions: 768
Description: The best quality in the MiniLM family, though slower than L6. More dimensions lead to an improvement in accuracy.
Use Case: When quality matters more than speed.

3. all-MiniLM-L12-v2

Dimensions: 384
Description: Slightly better than L6 but a bit slower.
Use Case: A solid balance of speed and quality.

4. multi-qa-MiniLM-L6-cos-v1

Dimensions: 384
Description: Optimized specifically for question-answering.
Use Case: Q&A systems and semantic search.

5. paraphrase-multilingual-MiniLM-L12-v2

Dimensions: 384
Description: Supports 50+ languages.
Use Case: Global and multilingual applications.

💰 The OpenAI Standard

If you need massive scale and the highest "reasoning" in your vectors without managing infrastructure:

text-embedding-3-small

Dimensions: 1536
Cost: ~$0.02 per 1M tokens.
Description: Highly cost-effective with improved accuracy over older models. It also supports Matryoshka Representation Learning, allowing you to trim dimensions (e.g., to 512) to save storage costs without losing much performance.

2. text-embedding-3-large

Dimensions: 3072
Cost: ~$0.13 per 1M tokens.
Description: The most powerful model available. It captures incredibly fine-grained nuances in text.
Feature: Like the "small" version, it supports Matryoshka Representation Learning, which means you can shorten the vector to 256 or 1024 dimensions to save database space while keeping most of the accuracy.
Use Case: Enterprise-level research, legal document analysis, or complex medical data.

3. text-embedding-ada-002

Dimensions: 1536
Cost: ~$0.10 per 1M tokens.
Description: The previous industry standard. While still reliable, it is now considered legacy compared to the "v3" family.
Use Case: Mostly seen in older "legacy" AI systems. For any new project in 2026, you should skip this and go straight to text-embedding-3-small.

⚖️ How to Choose?

Strict Privacy/On-Prem? ➔ Hugging Face (Local).

Real-time/Low Latency? ➔ all-MiniLM-L6-v2.

Multilingual Data? ➔ paraphrase-multilingual-MiniLM-L12-v2.

Enterprise Scale & Accuracy? ➔ text-embedding-3-small.

🚀 Conclusion

In 2026, picking the right embedding model is about balancing latency, cost, and accuracy. Don't just pick the one with the most dimensions—pick the one that fits your specific data and hardware.

What's your go-to embedding model for production? Let's discuss in the comments!

🧠 Your LLM Isn’t an Agent — Until It Has Tools, Memory, and Structure (LangChain Deep Dive)

Ananya S — Mon, 02 Mar 2026 17:09:48 +0000

Most “AI apps” today are just:

Prompt → LLM → Text Response

That’s not an agent.

That’s autocomplete with branding.

A real AI agent can:

🛠 Use tools
🧠 Remember context
📦 Return structured outputs
🔁 Reason across multiple steps

With modern LangChain, building this is surprisingly clean.

Let’s build one properly.

🚀 The Architecture of a Real Agent

A production-ready AI agent has four core components:

Model – the brain
Tools – capabilities
Structured outputs – reliability and formatting
Memory – continuity

If you’re missing one of these, you’re not building a system — you’re running a demo.

1️⃣ The Brain: Modern Agent Setup

We start with create_agent() — the current way to build agents in LangChain.

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

Low temperature = more deterministic reasoning.

Now let’s give it capabilities.

2️⃣ Tools: Giving the Agent Superpowers

Tools are just Python functions with clear docstrings.
The docstring matters — it’s how the model decides when to use the tool.

from langchain.tools import tool

@tool
def calculate_revenue(price: float, quantity: int) -> float:
    """Calculate total revenue given price per unit and quantity sold."""
    return price * quantity


@tool
def get_exchange_rate(currency: str) -> float:
    """Get the USD exchange rate for a given currency code."""
    rates = {"EUR": 1.1, "GBP": 1.25}
    return rates.get(currency.upper(), 1.0)

Now we assemble the agent:

agent = create_agent(
    model=llm,
    tools=[calculate_revenue, get_exchange_rate],
    system_prompt="You are a financial analysis assistant."
)

That’s it.

The agent now:

Decides when math is needed
Calls tools autonomously
Observes results
Produces a final answer

No manual routing logic.

3️⃣ Structured Outputs: Stop Parsing Strings

If you're still doing regex on LLM responses, stop.

Modern agents can return structured data using schemas.

from pydantic import BaseModel

class FinancialReport(BaseModel):
    revenue: float
    currency: str
    usd_value: float

Now we enforce structure:

structured_agent = create_agent(
    model=llm,
    tools=[calculate_revenue, get_exchange_rate],
    response_format=FinancialReport,
)

Now when you invoke:

response = structured_agent.invoke({
    "messages": [
        {"role": "user", "content": "I sold 120 units at 50 EUR each. Convert to USD."}
    ]
})

print(response)

You don’t get text.

You get validated data.
Using Pydantic structured output parsers ensures the datatype of the fields is based on how we defined it.

4️⃣ Memory: Making the Agent Stateful

Without memory, every request is a new message.

With memory, your agent becomes a collaborator.

In LangChain, memory can be plugged in via message history.

Example pattern:

chat_history = []

response = agent.invoke({
    "messages": chat_history + [
        {"role": "user", "content": "My product costs 20 USD."}
    ]
})

chat_history.extend(response["messages"])

response = agent.invoke({
    "messages": chat_history + [
        {"role": "user", "content": "Now calculate revenue for 300 units."}
    ]
})

Now the agent remembers:

Product price
Prior discussion
Contextual decisions

Memory transforms isolated responses into evolving workflows.

🧠 What’s Actually Happening Internally?

When you call:

agent.invoke(...)

The agent:

Reads conversation + system prompt
Plans next action
Chooses a tool (if needed)
Executes tool
Feeds result back into reasoning
Produces structured final output

This loop is grounded in tool-calling rather than fragile prompt tricks.

⚠️ Common Mistakes

Things beginner devs get wrong:

❌ Adding too many tools
❌ Writing vague tool descriptions
❌ Not enforcing structured outputs
❌ Forgetting observability/logging
❌ Letting the agent free-run without constraints

Agents are probabilistic planners — not deterministic scripts.

Design them intentionally.

🏗 The Big Shift in How We Build Software

Before agents:

APIs returned static responses
Business logic was deterministic
LLMs were “smart text generators”

After agents:

LLMs orchestrate execution
Tools become capabilities
Structure guarantees reliability
Memory enables continuity

You're no longer building chat interfaces.

You're building goal-driven systems.

🎯 Final Take

If your AI system:

Doesn’t use tools
Doesn’t enforce structure
Doesn’t maintain memory

It’s not an agent.

It’s autocomplete with better marketing.

With modern LangChain, the barrier to real agents is gone.

The question isn’t “Can we build agents?”

It’s:

What workflows are we ready to automate?

Do comment how you build agents and regarding any interesting types of agents you've built!

DEV Community: Ananya S

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

Verifying Passwords

Step 2: User Registration

What happens here?

Step 3: User Login

Step 4: Creating a JWT Token

Why do we need a secret key?

Generate Token Function

What does this function do?

Step 5: Generate Token During Login

Step 6: Protected Route

Authentication Flow Recap

Final Thoughts

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

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

Authentication

Authorization

To summarize:

Authentication and Authorization in AI Applications

Final Thoughts

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

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

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

Why Do We Need Data Validation?

The Problem Without Validation

Enter Pydantic

Your First Pydantic Model

Valid Request

Invalid Request

Using Pydantic with FastAPI

Understanding Validation Errors

Adding Constraints with Field()

Understanding the Constraints

Valid Request

Invalid Request

Optional Fields

Valid Request

Also Valid

Request Models vs Database Models

SQLAlchemy Model

Pydantic Model

Response Models

Why Pydantic Matters for AI Applications

How Validation Fits into the Request Lifecycle

Conclusion

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

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

The Problem with In-Memory Storage

What is SQLite?

What is SQLAlchemy?

What is an ORM?

Project Structure

database.py

models.py

schemas.py

main.py

Installing Dependencies

Step 1: Creating database.py

Understanding create_engine()

Understanding SessionLocal

Understanding Base

Creating Database Sessions

Why Do We Need get_db()?

Step 2: Creating models.py

Understanding the Model

Step 3: Creating schemas.py

Why Do We Need Schemas?

Step 4: Creating main.py

Creating Tables Automatically

CREATE Operation

What Happens Here?

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