Forem: Naved Shaikh

Stop Writing Manual Validation: Pydantic + FastAPI

Naved Shaikh — Thu, 05 Feb 2026 07:38:37 +0000

One of the biggest time-sinks in web development is writing if/else statements to check if a request body is valid.

In the Node.js post I shared earlier, we talked about structure. Today, let’s talk about Safety. In Python, we use Pydantic models to handle the "boring stuff" automatically.

The Manual Way (Avoid this)

@app.post("/login")
def login(data: dict):
    if "email" not in data:
        return {"error": "Email is required"}
    # ... more messy checks

The FastAPI Way (Do this)
By defining a class, FastAPI will automatically return a 422 Unprocessable Entity error if the user sends bad data. You don't have to write a single if statement.

from pydantic import BaseModel, EmailStr

class LoginSchema(BaseModel):
    email: EmailStr
    password: str
    remember_me: bool = False  # Default value

@app.post("/login")
def login(data: LoginSchema):
    # data is already validated and typed here!
    return {"message": f"Welcome {data.email}"}

Why this wins:

Type Safety: Your IDE knows exactly what data.email is.
Auto Docs: Your Swagger UI updates instantly to show the required fields.
Cleaner Code: Your business logic stays separate from your validation logic.

If you’re moving from Express to FastAPI, Pydantic is the "killer feature" you’ll wish you had sooner.

[Boost]

Naved Shaikh — Sat, 24 Jan 2026 10:41:52 +0000

FastAPI Architecture: Clean, Scalable & Self-Documenting

Naved Shaikh ・ Jan 24

#python #fastapi #beginners #webdev

FastAPI Architecture: Clean, Scalable & Self-Documenting

Naved Shaikh — Sat, 24 Jan 2026 10:40:07 +0000

Conventional wisdom for Python APIs often leads us to massive main.py files or overly complex Django structures. Like many of you, I've struggled with finding the "Goldilocks" zone a setup that is light enough to get code out the door but structured enough not to break when the team grows.

In this post, I'll show you my preferred setup for a FastAPI microservice. We’ll focus on keeping logic separated, handling errors gracefully, and my favourite part letting Python’s type hints do 90% of the documentation work for us.

The Philosophy: Type Safety is Documentation
In Express, we often use JSDoc to explain our code. In Python, we have Type Hints. By using Pydantic models, FastAPI doesn't just check your data; it automatically generates a professional Swagger UI without you writing a single line of extra documentation.

1) The Project Structure
For a scalable micro service, I move away from the "all-in-one" file. Here is the blueprint:

.
├── app/
│   ├── main.py          # Entry point
│   ├── routes/          # API Endpoints (equivalent to Express Routes)
│   ├── schemas/         # Pydantic Models (Data validation)
│   └── services/        # Business logic (equivalent to Controllers)
├── requirements.txt
└── .env                 # Environment variables

2) Defining Data (The Schemas)
Instead of manual validation, we define what our data looks like. This replaces the need for complex comments because the code is the spec.

# app/schemas/user.py
from pydantic import BaseModel, EmailStr

class UserBase(BaseModel):
    username: str
    email: EmailStr

class UserCreate(UserBase):
    password: str

class UserResponse(UserBase):
    id: int

    class Config:
        from_attributes = True

3) The "Base Router" Logic
In Express, we often use classes to group logic. In FastAPI, we use APIRouter. It allows us to modularisation the app easily.

# app/routes/user_routes.py
from fastapi import APIRouter, HTTPException
from app.schemas.user import UserResponse, UserCreate

router = APIRouter(prefix="/users", tags=["Users"])

@router.get("/", response_model=list[UserResponse])
async def get_users():
    # This acts as your controller logic
    return [{"id": 1, "username": "dev_user", "email": "user@example.com"}]

@router.post("/", response_model=UserResponse)
async def create_user(user: UserCreate):
    # Business logic goes here
    return {**user.model_dump(), "id": 2}

4) Middleware: The Silent Hero
Just like Express middle ware, FastAPI lets us intercept requests. Here’s a simple "Process Time" middle ware to log how fast your API is:

# app/main.py
import time
from fastapi import FastAPI, Request

app = FastAPI(title="My Scalable API")

@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    start_time = time.time()
    response = await call_next(request)
    process_time = time.time() - start_time
    response.headers["X-Process-Time"] = str(process_time)
    return response

# Include our routes
from app.routes import user_routes
app.include_router(user_routes.router)

5) Automatic Docs (No More Out-of-Sync Swagger)
One of the biggest pain points in Express is keeping swagger.json updated. With this Python setup, you simply run your server

uvicorn app.main:app --reload

Navigate to /docs, and you’ll find a fully interactive, beautifully themed Swagger UI. Because we used Pydantic models and type hints, the documentation cannot go out of sync. If you change a field in your code, it changes in the docs automatically.

6) Keeping it Clean: Linting & Formatting
To keep the code quality high (and catch errors early), I always include these two in my Python workflow:

Ruff: An incredibly fast Python linter and formatter (replaces Flake8 and Black).
MyPy: For static type checking to ensure your type hints are actually correct.

This setup isn't "the only way," but it provides a foundation that handles 99% of micro service needs. It’s simple enough for a prototype but strict enough for production.

Your Python Code is Slow in 2026. Here's Why (And its not Python fault)

Naved Shaikh — Mon, 19 Jan 2026 13:41:16 +0000

You've mastered the basics. You write clean functions, understand classes, and can debug your way out of most problems.

But your Python code still feels... heavy. It chews through RAM like candy. It crawls when processing real-world datasets. And when you deploy it, the cloud bill makes your CFO wince.

Here's the secret: It's not Python's fault.

In 2026, everyone can get AI to spit out working code in seconds. But the real differentiation the gap between junior and senior, between expensive and efficient—comes down to mastering patterns that AI often gets wrong.

These three "advanced beginner" patterns will transform your code from functional to professional overnight.

The RAM Killer You're Probably Using Right Now Let me guess—you're processing large datasets with list comprehensions like this:

# The Memory Hog (Don't Do This)
data = [process(x) for x in range(1_000_000)]  # 🚨 Instantly loads 1M items into RAM

This creates a complete list in memory before you even start working with the first item. For large datasets, this can crash your program or bring your server to its knees.

# The Memory Savior (Do This Instead)
data = (process(x) for x in range(1_000_000))  # ✅ Yields one item at a time

# Use it like this:
for item in data:
    process_item(item)

Why This Matters: Generators use lazy evaluation. They produce items one at a time, only when needed. Your memory usage stays flat whether you're processing 1,000 or 10,000,000 records.

The Silent Resource Leak That's Costing You Money How do you handle files, database connections, or network sockets? If you're still writing:

file = open('data.txt')
try:
    content = file.read()
finally:
    file.close()

You're playing with fire. One crash, one missed exception, and resources leak. Memory piles up. Connections stay open. In production, this causes gradual degradation until everything grinds to a halt.

The Solution: Context Managers (The with Statement)

# The Professional Way (Always Do This)
with open('data.txt') as file:
    content = file.read()
# File automatically closes here, even if an error occurs

This isn't just for files. Use it for:

Database connections
Thread locks
Network sockets
Custom resources (you can even build your own with enter and exit)

Why This Matters: Context managers guarantee cleanup. They're Python's way of saying "I'll handle the messy parts, you focus on the logic." In 2026's containerised, micro services world, resource leaks are the silent killers of production systems.

The String Concatenation Trap That Slows Everything Down This might be the most common performance mistake in Python:

# The Slow Way (Exponential Slowdown)
result = ""
for line in thousands_of_lines:
    result += line  # 🚨 Creates a NEW string object every single time

Strings in Python are immutable. Every += operation creates an entirely new string object and copies all the data over. With thousands of lines, this becomes O(n²) in disguise.

The Solution: The Join Pattern

# The Fast Way (Linear Time)
parts = []
for line in thousands_of_lines:
    parts.append(line)
result = "".join(parts)  # ✅ Single allocation, single copy

# Or as a one-liner with a generator expression:
result = "".join(process(line) for line in thousands_of_lines)

Real-World Impact: I've seen logging libraries speed up by 40x just by fixing this pattern. In data pipelines processing millions of records, this one change can save hours of compute time.

10 Python Concepts That Finally “Clicked”

Naved Shaikh — Fri, 16 Jan 2026 07:38:47 +0000

We’ve all been there: you think you know Python, and then a weird bug keeps you up until 2 AM. For the longest time, I thought I was an “expert” because I knew the syntax. But the real breakthroughs happened when I stopped memorising and started understanding the why.

Here are the 10 “light-bulb moments” that changed how I write code.

1. Mutable vs. Immutable Objects
The classic “Why is my list changing?!” moment.

Immutable (int, str, tuple): When you change it, Python creates a new object.
Mutable (list, dict, set): You’re modifying the original object in place.

def add_item(items, value):
    items.append(value)
    return items

my_list = [1, 2, 3]
add_item(my_list, 4)
print(my_list)  # [1, 2, 3, 4] - The original list was modified!

2. The Danger of Default Mutable Arguments
This one is a rite of passage. If you use a list as a default argument, Python evaluates it once when the function is defined, not every time it’s called.

The Bug:

def add_to_list(val, items=[]):
    items.append(val)
    return items

print(add_to_list(1)) # [1]
print(add_to_list(2)) # [1, 2] - Wait, what?

The Fix: Always use None as the default.

3. Pass-by-Object-Reference
Is Python “pass-by-value” or “pass-by-reference”? Actually, it’s pass-by-object-reference. Think of variables as tags stuck onto objects. If you pass a mutable object (like a list) to a function, the function gets a tag for that same object. If it’s immutable (like an integer), the function can’t change the original.

4. is vs ==
I used to use these interchangeably. Huge mistake.

== checks if the values are the same.
is checks if they are the exact same object in memory.

a = [1, 2]
b = [1, 2]
print(a == b) # True
print(a is b) # False (Two different lists that happen to look the same)

5. Iterators and Generators
I used to build massive lists just to loop through them. Then I discovered Generators. Instead of storing 1 million items in RAM, a generator calculates them on the fly using yield.

def countdown(n):
    while n > 0:
        yield n
        n -= 1

for i in countdown(3):
    print(i) # Memory efficient and fast.

6. List Comprehensions vs. Generator Expressions
They look almost identical, but the brackets matter:

[x for x in range(100)] → List: Memory hog, builds the whole
thing now.
(x for x in range(100)) → Generator: Lazy, builds items only
when you ask for them.

7. Context Managers (with)
We’ve all forgotten to close a file or a database connection. Using with ensures that even if your code crashes, Python cleans up after itself. It’s not just for files; you can use it for locks, sockets, and custom cleanup using __enter__ and __exit__.

8. The “Magic” of *args and **kwargs
These used to look like hieroglyphics to me. Now, I see them as the key to flexible code.

*args = list of positional arguments.
**kwargs = dictionary of named arguments. They allow you to write
functions that can handle any number of inputs.

9. Decorators
Decorators are just functions that wrap other functions to add extra behaviour (like logging or timing). Once you realise a decorator is just a function returning another function, the “magic” disappears and the power remains.

def log_call(func):
    def wrapper(*args, **kwargs):
        print(f"Executing {func.__name__}...")
        return func(*args, **kwargs)
    return wrapper

@log_call
def greet(name):
    print(f"Hi {name}")

10. if __name__ == "__main__":
This isn’t just boilerplate. It tells Python: “Only run this code if I executed this specific file.” If I import this file elsewhere, the code under this block won't run. It’s the difference between a library and a script.

"Just a small change," they said. It will be "easy," they said. 🫠

Naved Shaikh — Tue, 13 Jan 2026 13:03:50 +0000

Me, starting a new project: Optimistic, caffeinated, ready to build the future.✨

Me, finding out it's a codebase from 2008 with no documentation and comments like "DO NOT TOUCH THIS OR EVERYTHING BREAKS": 💀
We've all been there. That moment when a "quick fix" turns into an archaeological dig of ancient dependencies.

Stop telling me Python is "too slow" for the 2026 backend.

Naved Shaikh — Mon, 12 Jan 2026 05:51:48 +0000

It’s the most tired argument in engineering.
"Python can’t scale."
"The GIL is a bottleneck."
"Switch to Go or Rust for real performance."

Here is what people are missing:
In 2026, developer velocity > millisecond execution.

I recently optimised a Flask-based AI inference engine on AWS. We didn't switch languages. We changed the architecture:

Async Evolution: We moved to the latest FastAPI/Pydantic V3 wrappers.
AWS Lambda Powertools: Optimised cold starts by 40% using LLM-based caching.
Database Bottlenecks: It’s almost never the Python code. It’s your unindexed MySQL queries and lack of connection pooling.

Execution is cheap. Engineering time is expensive.

Unless you are building a HFT platform, Python isn't your problem. Your system design is.

Build for clarity first. Scale for performance second.

Are you still choosing languages based on "speed benchmarks" or "shipping speed"? Let’s debate in the comments. 👇

Your AI Forgets Everything. Here’s the Fix Silicon Valley Doesn’t Want You to Know.

Naved Shaikh — Fri, 09 Jan 2026 14:53:37 +0000

You’ve built a “smart” AI agent. It can reason, search, and execute tasks.

But every time a user returns? It acts like a stranger. It forgets their name, their preferences, their last project everything.

It has goldfish memory. And it’s killing your product.

In 2026, the biggest problem isn’t making AI smarter it’s making it remember.

While most teams dump PDFs into vector databases hoping for magic, the real breakthrough is happening behind closed doors. The winners aren’t building smarter chatbots. They’re building AI that learns like a human.

The Memory Breakthrough: From First Date to Long-Term Relationship

Standard RAG gives your AI a textbook. What it needs is a diary.

The new architecture? Entity-Based Long-Term Memory. Instead of treating every conversation as isolated, we teach AI to build a living, breathing Knowledge Graph for each user.

Here’s the 4-step loop changing everything:

Extract – The AI listens for who and what matters: “Sarah prefers
dark mode.” “Project Atlas is due June 15.”
Store – Facts connect in a web of relationships, not a dump of text.
Reflect – A “janitor” model cleans up after each chat, merging new
and old memories.
Recall – Next time Sarah says “Hi,” the AI doesn’t search—it
remembers.

Why Your Current System is Failing You

The Old Way (What You’re Probably Doing):
User: “Update the Q2 dashboard.”
AI: Searches every document containing “dashboard”
Response: “Here’s how to build a dashboard from scratch.”

The New Way (What Users Actually Want):
User: “Update the Q2 dashboard.”
AI: Remembers this user leads sales, prefers real-time charts, and last month asked for competitor overlays
Response: “Updating the European sales dashboard with live data. Should I include the competitor pricing overlay you found useful last time?”

One is a tool. The other is a colleague who pays attention.

The 2026 Stack That Actually Works
Forget chasing bigger models. The real innovation is in the memory layer:

Vector Database = Your AI’s library (what it knows)
Knowledge Graph = Your AI’s experience (who it knows)

The teams winning right now are combining both giving AI not just information, but context.

The Question Keeping CEOs Awake at Night
Is your AI still having the same conversation on loop? Or is it getting smarter with every interaction?

The difference between a chatbot and a true digital teammate isn’t intelligence it’s memory.

Why Your AI Is Suddenly Making You Wait. ⏳

Naved Shaikh — Wed, 07 Jan 2026 07:00:43 +0000

Have you noticed that AI is getting... slower?

In 2024, you hit enter and the text appeared instantly. Now, in 2026, models like OpenAI’s o1 or DeepSeek-R1 often pause for 10, 20, or even 60 seconds. A "Thinking" bar pulses on the screen while you wait.

It’s not a slow internet connection. It’s a massive shift in how AI works.

The Shift: From "Guessing" to "Reasoning"

Old AI models were "Fast Guessers." They predicted the next word based on patterns. They were instant, but they often "hallucinated" (lied) because they didn't double-check their own logic.

New AI models are "Slow Thinkers." They now have a "Hidden Loop" where they:

Draft a plan internally.
Verify their own steps.
Correct errors before they ever show you a result.

This makes them much more accurate for maths, coding, and complex strategy. But it also makes them overkill for simple tasks.

How to Choose Your AI "Speed":

You don't always need a "Thinking" model. To save time and credits, follow this simple rule:

👉 Use "Fast" Models (Instant) for creativity and routine.

Best for: Summarising an email, writing a social post, or checking grammar.

👉 Use "Thinking" Models (10s–60s wait) for accuracy and logic.

Best for: Complex coding, solving maths problems, or deep technical research.

If the answer requires Creativity, go Fast. If the answer requires Accuracy, go Slow.

2025 Was for Playing. 2026 Is for Paying. 📉📈

Naved Shaikh — Fri, 02 Jan 2026 05:53:51 +0000

Happy New Year.

If 2025 was the "Year of the Chatbot," 2026 is officially the "Year of the Agent."

I’ve been analyzing the roadmap for the next 12 months, and the shift is massive. The "hype" phase is over. The "ROI" phase has begun.

Here are the 3 developments that will define your business this year:

The Death of "Chatting" Last year, you asked AI questions. This year, you will assign AI jobs. We are moving from "Write an email for me" to "Manage my inbox, reply to leads, and book meetings automatically." If your AI strategy is still just a text box, you are already behind.
Small Models > Big Models The obsession with "Trillion Parameter" giant models is fading. Smart companies in 2026 are using SLMs (Small Language Models). They are faster, cheaper, and run privately on your own data. You don't need a Ferrari to drive to the grocery store.
Privacy is the New Premium After the data leaks of 2025 (we all remember them), clients are done with "public" AI. The biggest competitive advantage in 2026 isn't how smart your AI is, but how safe it is.

My Prediction: By December 2026, 50% of the work you do today manually will be handled by an "Agent" working in the background while you sleep.

Are you entering 2026 with a 2025 playbook? Let's fix that.

What is your #1 goal for AI adoption this year?

Stop Using Pip: Why I Switched to “uv” for Python Projects (10x Faster)

Naved Shaikh — Thu, 01 Jan 2026 10:49:06 +0000

If you are still waiting for pip install to finish or wrestling with poetry lock file conflicts, it is time to upgrade. Enter uv, the new Rust-based package manager that is taking the Python world by storm in 2025.

It doesn’t just replace pip; it replaces pip-tools, virtualenv, and even pyenv. Here is why you should switch and how to get started on Windows and Mac.

Why the Hype?
uv is fast. Ridiculously fast. Because it is written in Rust, it can resolve dependencies and install packages in milliseconds where pip takes seconds (or minutes).

Cold Install: ~10–100x faster than pip.
Warm Install: Instant.
Disk Usage: It uses a global cache, so you don’t save the same NumPy version 50 times on your disk.

Step 1: Installing uv
The installation is seamless. Windows (PowerShell):

irm https://astral.sh/uv/install.ps1 | iex

Mac/Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

Step 2: The “Magic” of uv run
This is the killer feature. You no longer need to manually create and activate virtual environments (source venv/bin/activate is dead).

With uv, you just create a script and run it. uv automatically creates a temporary environment, installs the imports, runs the script, and cleans up.

Try this: Create a file hello.py:

import requests
print(requests.get("https://api.github.com").status_code)

Run it:

uv run hello.py

uv detects you need requests, installs it in a cached environment, and runs the script instantly.

Step 3: Migrating a Project (requirements.txt)
Have an old project? You can use uv as a drop-in replacement for pip.

Old way:

pip install -r requirements.txt

New way:

uv pip install -r requirements.txt

It respects your existing venv but installs everything significantly faster.

Step 4: Initializing a New Project
For a robust setup (like Poetry), use:

uv init my-new-project
cd my-new-project
uv add pandas fastapi

This creates a pyproject.toml file automatically. No complex setup required.

In 2025, speed matters. uv removes the friction of managing Python environments, letting you focus on coding, not waiting.

Delete Your ChatGPT History. Right Now. 🚨

Naved Shaikh — Wed, 31 Dec 2025 07:11:29 +0000

You know that brilliant strategy doc you just pasted into ChatGPT? The confidential code snippet? The client email draft?

It’s no longer just yours.

Stop what you’re doing and check your chat history right now. Go ahead. I’ll wait.

What you’ll find might be the biggest, silent data leak your company has ever had.

Here’s the terrifying truth most people miss: Every conversation you have with a AI is a potential training data point. That proprietary workflow you asked it to optimise? The financial figures you pasted for summarization? The unreleased product description?

By default, they can all become part of the model’s permanent memory. Your private input today could surface in a competitor’s query tomorrow.

This Isn’t a Theory. It’s Already Happening.
Remember Samsung? In 2023, they banned internal use of ChatGPT after engineers accidentally fed it sensitive source code. The AI digested it. That code could now be woven into its understanding, potentially regurgitating it to anyone asking a similar technical question.

Your business is no different.

The Crowded Elevator Rule
Treat every AI chat window like a crowded public elevator. You wouldn’t discuss your quarterly losses, a new hire’s salary, or a merger plan there. So why are you typing it into ChatGPT?

AIs are designed to learn from the world. You are part of that world. Unless you explicitly opt out or use a private system, you are a contributor.

How to Protect Yourself (Right Now)

Delete Your History. Seriously, do it. For ChatGPT: Settings → Data Controls → Clear Chat History. Do this regularly.
Turn Off Training. In your settings, find the data controls and disable “Improve the model for everyone.” This doesn’t make it fully private, but it helps.
Use Private Modes. For sensitive work, use platforms that guarantee data privacy (like ChatGPT Team/Enterprise, or private Azure/Google Cloud instances).
Sanitize Your Inputs. Before pasting, scrub confidential names, exact figures, and unique identifiers. Use placeholders like “[CLIENT_NAME]” or “[PROPRIETARY_ALGORITHM].”

The Real Solution: Private Intelligence

If you’re using AI for real business work, you need a private environment. This means an AI system that runs within your own secure cloud, where your data never leaves your walls, and conversations are never used for training.

This is how enterprises actually scale AI with control and security.

The Bottom Line
AI is an incredible tool, but it has the memory of an elephant and the discretion of a town crier.

Don’t just be a user. Be a conscientious participant. Your company’s secrets depend on it.

Ask yourself this: What’s the most sensitive thing you’ve ever asked an AI? Would you say it in a room full of competitors?