DEV Community: Saleh Azimidokht

The Hidden Cost of Django REST Framework Serializers

Saleh Azimidokht — Mon, 07 Sep 2026 08:21:04 +0000

Your Django REST Framework API can have fast database queries and still be slow.

That's one of the most confusing performance problems in Django applications.

You check PostgreSQL.

The queries look fast.

You optimize your views.

Everything seems fine.

But the endpoint is still taking hundreds of milliseconds—or even seconds.

One place developers often forget to investigate is the Django REST Framework serializer.

A serializer is not always just converting Python objects into JSON.

It can trigger database queries, access relationships, execute Python code, calculate fields, and recursively serialize nested objects.

And that's where things can get expensive.

The N+1 Query Problem Hiding Inside a Serializer

Consider a simple serializer:

class VehicleSerializer(serializers.ModelSerializer):
    customer_name = serializers.SerializerMethodField()

    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "customer_name",
        )

    def get_customer_name(self, obj):
        return obj.customer.name

Looks perfectly reasonable.

But where does obj.customer come from?

If the customer relationship hasn't been loaded, Django may execute another SQL query.

With 100 vehicles, you could end up with:

1 query   → fetch vehicles
100 queries → fetch customers

Total: 101 queries

That's the classic N+1 query problem.

And the dangerous part is that the serializer itself doesn't look like a database operation.

SerializerMethodField Is Not Free

SerializerMethodField is one of my favorite DRF features.

It's also one of the easiest ways to accidentally create expensive APIs.

Consider:

class ServiceSerializer(serializers.ModelSerializer):
    last_service = serializers.SerializerMethodField()

    def get_last_service(self, obj):
        return (
            Service.objects
            .filter(ownership=obj.ownership)
            .order_by("-created_at")
            .first()
        )

This performs a database query every time get_last_service() is called.

Serialize 500 services?

Potentially:

1 main query
+
500 additional queries
=
501 queries

The code is readable.

The API is correct.

And yet the performance can be terrible.

This is why correct code isn't necessarily efficient code.

The Fix Usually Isn't Inside the Serializer

One of the most important lessons I've learned when optimizing Django APIs is this:

The serializer should not be responsible for discovering data that the database could have prepared.

Instead of querying for every object, move the work into the QuerySet.

For example, you can use Subquery:

from django.db.models import OuterRef, Subquery

last_service = Service.objects.filter(
    ownership=OuterRef("ownership"),
).order_by("-created_at")

queryset = Vehicle.objects.annotate(
    last_service_id=Subquery(
        last_service.values("id")[:1]
    )
)

Now the database prepares the information as part of the main query.

Your serializer becomes simpler:

class VehicleSerializer(serializers.ModelSerializer):
    last_service_id = serializers.IntegerField(read_only=True)

    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "last_service_id",
        )

The architecture becomes:

Database
    ↓
Optimized QuerySet
    ↓
Annotations
    ↓
Serializer
    ↓
JSON

Instead of:

Database
    ↓
Serializer
    ↓
"Let's query something"
    ↓
Another query
    ↓
Another query
    ↓
Another query

select_related() vs prefetch_related()

When working with Django REST Framework serializers, you should always pay attention to the relationships being accessed.

For single-valued relationships:

ForeignKey
OneToOneField

use:

select_related()

For example:

vehicles = Vehicle.objects.select_related("customer")

Now Django can retrieve the vehicle and customer using a SQL JOIN.

For collections such as:

ManyToManyField
Reverse ForeignKey

use:

prefetch_related()

For example:

services = (
    Service.objects
    .prefetch_related("products")
)

A simple rule to remember:

ForeignKey / OneToOne
        ↓
select_related()

ManyToMany / Reverse FK
        ↓
prefetch_related()

These two methods are some of the most important tools for preventing N+1 queries in Django APIs. (DEV Community)

Nested Serializers Make Things Worse

Nested serializers are convenient.

But convenience can hide expensive database access.

Imagine:

class ProductSerializer(serializers.ModelSerializer):
    class Meta:
        model = Product
        fields = ("id", "name")


class ServiceSerializer(serializers.ModelSerializer):
    products = ProductSerializer(many=True)

    class Meta:
        model = Service
        fields = (
            "id",
            "products",
        )

Now imagine your API returns 1,000 services.

Every service needs its products.

Without prefetching, your API can start generating queries like:

Service query
Product query
Product query
Product query
...

And nested relationships can go even deeper:

Service
 ├── Customer
 │    └── Address
 └── Products
      └── Category

A response that looks innocent in JSON can represent a surprisingly expensive data-access pattern.

Don't Build One Giant Serializer

Another common mistake is trying to use one serializer for everything.

For example:

VehicleSerializer

gets used for:

List endpoints
Detail endpoints
Create endpoints
Update endpoints
Admin endpoints
Search endpoints

Eventually, the serializer becomes huge.

A list endpoint might only need:

class VehicleListSerializer(serializers.ModelSerializer):
    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "color",
        )

While a detail endpoint can provide more information:

class VehicleDetailSerializer(serializers.ModelSerializer):
    customer = CustomerSerializer()

    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "color",
            "customer",
        )

This isn't unnecessary duplication.

It's API design.

A list endpoint shouldn't return an entire object graph just because the detail endpoint needs it.

Smaller Responses Are Usually Better

More data isn't always better.

Consider an API response containing:

Customer
 ├── Vehicles
 ├── Services
 ├── Invoices
 ├── Payments
 ├── Addresses
 └── Orders

It might look impressive.

But every additional relationship can increase:

Database work
Serialization time
Response size
Memory usage
Network transfer
Frontend processing

The API should return the data the client needs—not everything the database knows.

Measure Before Optimizing

This is probably the most important rule.

Don't look at a serializer and say:

"This probably causes performance problems."

Measure it.

For Django APIs, useful things to measure include:

SQL query count
SQL query duration
Serializer execution time
Total request duration
Response size
CPU usage

Tools such as Django Debug Toolbar, Django Silk, and APM platforms can help you find where the time is actually going.

Because sometimes the database isn't the bottleneck.

Imagine:

Database:       40 ms
View logic:     30 ms
Serialization: 650 ms
JSON rendering: 80 ms

Total:          800 ms

Optimizing a 40 ms database query isn't going to solve your 800 ms API response.

Profile the entire request.

A Simple DRF Performance Checklist

When a Django REST Framework endpoint becomes slow, I usually start here:

1. Count the queries

How many SQL queries does the endpoint execute?

2. Inspect SerializerMethodField

Look for database access inside:

get_<field_name>()

3. Inspect relationship access

Look for:

obj.customer
obj.owner
obj.category
obj.products.all()

4. Check select_related()

Are your ForeignKey and OneToOneField relationships loaded efficiently?

5. Check prefetch_related()

Are your ManyToMany and reverse relationships prefetched?

6. Look at annotations

Can a calculation be performed by the database instead of repeatedly inside Python?

7. Reduce nested data

Does the frontend actually need all those nested objects?

8. Separate serializers

Does the list endpoint really need the same serializer as the detail endpoint?

9. Measure again

Never assume the optimization worked.

Measure before and after.

The Real Cost of a Serializer

Django REST Framework serializers aren't inherently slow.

The problem is what we ask them to do.

A serializer becomes expensive when it:

Executes database queries repeatedly
Accesses unloaded relationships
Performs expensive Python calculations
Uses deeply nested serializers
Returns unnecessary data
Hides database access inside SerializerMethodField

The best optimization is often not changing the serializer.

It's changing the QuerySet behind it.

Think about your API like this:

Request
   ↓
View
   ↓
Optimized QuerySet
   ↓
Database
   ↓
Serializer
   ↓
Minimal JSON Response

Not:

Request
   ↓
View
   ↓
Huge QuerySet
   ↓
Serializer
   ↓
Query
   ↓
Query
   ↓
Query
   ↓
N+1
   ↓
Slow API

Final Thought

The next time you see a slow Django REST Framework endpoint, don't only inspect the SQL.

Inspect what happens after the QuerySet is evaluated.

Your database query might be fast.

Your serializer might be the expensive part.

And that hidden cost becomes much more visible as your dataset grows.

I wrote a deeper technical breakdown with more examples, optimization strategies, select_related(), prefetch_related(), annotations, nested serializers, and practical debugging techniques:

👉 The Hidden Cost of Django REST Framework Serializers

If you're building production Django APIs, understanding the relationship between QuerySets, serializers, and database queries can make a huge difference.

django #python #djangorestframework #drf #backend #api #webdevelopment #performance #database #programming

I Built a Signed Webhook Receiver for Cross-Server Communication

Saleh Azimidokht — Tue, 11 Aug 2026 12:05:48 +0000

Sometimes your application can reach an external service from one server, but not from another.

I ran into this problem while working on one of my projects. I needed my server in Iran to communicate with Telegram, but the connection wasn't reliable from inside Iran.

Instead of moving the whole application, I built a small intermediate service:

Signed Webhook Receiver

It is a lightweight FastAPI service that receives requests signed with an RSA private key and verifies them using the corresponding public key before processing them.

Your Server
     |
     | RSA Signed Request
     v
Webhook Receiver
     |
     | HTTP Request
     v
External Service

The receiver can be useful for:

Secure server-to-server communication
Webhooks and internal APIs
Acting as a controlled proxy/gateway
Connecting servers across different network environments
Payment integrations where a provider requires requests from an Iranian IP

For example, if your main application is hosted outside Iran but a payment gateway only accepts requests from Iranian IP addresses, an Iranian server can act as the intermediate gateway:

Foreign Server
      |
      | Signed Request
      v
Iranian Gateway Server
      |
      v
Payment Gateway

The important part is that this isn't an open proxy. Requests can be authenticated and the gateway can be restricted to specific operations and destinations.

The project is built with Python, FastAPI, Cryptography, Docker, and Traefik and is open source.

View the project on GitHub

I also wrote more technical notes and development articles on my website:

Building a Secure Webhook Receiver for Server-to-Server Communication | CyberHuginn

Designing a Gold Jewelry E-Commerce Database with Django

Saleh Azimidokht — Tue, 04 Aug 2026 05:04:51 +0000

When I accepted a project to build an online gold jewelry store, I thought it would be just another e-commerce platform.

Products. Orders. Payments.

Nothing unusual.

I couldn't have been more wrong.

A few hours into the database design, I realized the real challenge wasn't Django—it was understanding the business.

Unlike a regular online store, customers aren't buying a generic product. They're buying a very specific variation of that product.

A single ring, for example, can exist in multiple versions:

Different weights
Different karats
Different sizes
Different gemstones
Different making fees
Different prices
Different inventory

That simple observation completely changes how your database should be designed.

The Common Mistake

Many developers model their orders like this:

Order
 └── Product

That works perfectly for books, digital products, or simple inventory.

It completely falls apart for jewelry.

Because the customer isn't purchasing the Product.

They're purchasing one specific variation of that product.

The Missing Model

Instead of attaching orders directly to Product, I introduced another layer:

Product
    └── ProductVariable
            ├── Price
            ├── Stock
            ├── Making Fee
            ├── Weight
            ├── Karat
            └── Attributes

Now every purchasable item has its own inventory, pricing, and specifications while still belonging to the same parent product.

This approach also makes searching and filtering much easier because attributes become reusable across multiple products.

Start From Business Scenarios

Before writing models, I always walk through real business scenarios.

Questions like:

What exactly is the customer buying?
Can inventory differ between variations?
Can price change based on weight?
What happens when an item is out of stock?
Can customers order custom-made jewelry?

Those questions usually define your entities long before you write your first Django model.

This article only scratches the surface.

In the full version, I explain:

How to identify entities using Use Cases
Building an ER Diagram
Designing Django models
Modeling ProductVariable
Categories vs Tags
Product Attributes
Inventory management
Ordering and payment architecture
Real-world jewelry business scenarios

👉 Read the complete article here:

https://cyberhuginn.com/notes/designing-a-gold-jewelry-ecommerce-database-with-django

If you're building an e-commerce platform with Django, especially one that sells configurable products, this design pattern can save you from painful database refactoring later.

Why Every Small SaaS Needs Uptime Monitoring

Saleh Azimidokht — Sat, 01 Aug 2026 17:34:22 +0000

Building software has never been easier.

Keeping it online is the hard part.

Whether you're running a personal project, an internal API, a startup MVP, or a growing SaaS business, downtime can quickly become expensive. Users lose trust, support requests increase, and revenue disappears while you're unaware that something has gone wrong.

The worst part?

Most outages aren't discovered by monitoring systems.

They're discovered by users.

That realization is exactly what led me to build Bidar—a lightweight uptime monitoring platform focused on one simple goal:

Notify developers as soon as their services become unavailable.

The Hidden Cost of Downtime

It's easy to think of downtime as "just a server issue."

In reality, the impact is much broader.

Even a short outage can affect:

User trust
Customer satisfaction
Conversion rates
Search rankings
Team productivity
Brand reputation

Your users don't care whether the issue was caused by a failed deployment, DNS problem, database outage, or cloud provider incident.

They only know one thing:

Your service wasn't available when they needed it.

Why Manual Monitoring Doesn't Scale

In the beginning, many developers rely on manual checks.

They refresh the website.

They test an API endpoint.

They occasionally check server metrics.

That works for hobby projects.

It stops working when real users depend on your application.

You can't monitor your services 24 hours a day.

You can't wake up every hour to verify your API is still responding.

Automation eventually becomes a necessity.

What Should You Monitor?

A good monitoring solution should cover more than just your homepage.

Some of the most valuable things to monitor include:

Website availability
REST API endpoints
SSL certificate expiration
Response time
HTTP status codes
Critical customer-facing pages
Internal services

Monitoring the right endpoints allows you to detect problems before your customers notice them.

What Makes a Good Monitoring Tool?

After working on several backend systems, I've found that a monitoring solution doesn't need hundreds of features.

It needs to do a few things really well.

Fast Detection

The sooner you're notified, the sooner you can fix the issue.

Reliable Alerts

Notifications should arrive immediately through the channels you actually use.

Easy Setup

Monitoring should take minutes—not hours.

Clear Results

The goal isn't generating pretty dashboards.

The goal is answering one question:

Is my service healthy?

Why I Built Bidar

While working on Django projects and APIs, I wanted a monitoring service that focused on uptime instead of trying to be a complete observability platform.

Many existing tools are incredibly powerful.

They also come with dozens of dashboards, metrics, traces, and features that smaller teams often don't need.

So I built Bidar.

Its philosophy is simple:

Add your website or API.
Configure monitoring.
Get notified when something goes wrong.

That's it.

No unnecessary complexity.

Just reliable uptime monitoring.

Who Is It For?

Bidar is especially useful for:

Indie Hackers
SaaS founders
Freelancers managing client websites
Small development teams
Backend developers
Anyone running production APIs

If uptime matters to your users, monitoring should matter to you.

Final Thoughts

Reliable software isn't just about writing good code.

It's also about knowing when things stop working.

Monitoring helps you detect issues faster, reduce downtime, and respond before your users start sending emails asking if your service is down.

If you're looking for a lightweight uptime monitoring platform, I'd love for you to check out Bidar.

🌐 Website: https://bidarhq.ir

I'm always looking for feedback from developers.

If there's a feature you'd like to see, let me know!

About the Author

I'm a backend developer focused on Django, distributed systems, developer tools, and open-source software.

Website: https://cyberhuginn.com

GitHub: https://github.com/cyberhuginn

I Built a Lightweight Health Check Package for Django

Saleh Azimidokht — Sat, 01 Aug 2026 17:30:06 +0000

While working on several Django projects, I often needed a simple endpoint to verify that the application was actually healthy—not just running.

Most existing solutions were either too heavy, required extra configuration, or didn’t provide the flexibility I wanted.

So I built django-healthkit.

What it does

The package lets you expose a health endpoint that can verify different parts of your application.

Current checks include:

Database connectivity
Cache availability
Disk usage
Memory usage
CPU usage

Configuration is intentionally simple:

HEALTH_CHECKS = [
    "database",
    "cache",
    "disk",
    "memory",
    "cpu",
]

Then expose the endpoint and you're ready to use it with:

Docker health checks
Kubernetes probes
Traefik
Nginx
Monitoring systems
Uptime monitoring services

Why I built it

My goal wasn't to create another monitoring platform.

I wanted a small package that answers one simple question:

Is my Django application actually healthy?

No dashboards.

No unnecessary dependencies.

Just a clean JSON response that can be consumed by automation.

What's next?

This is only the first release.

Some ideas planned for future versions:

Custom health checks
Async support
Response customization
More built-in system checks
Better integrations with monitoring tools

I'd love your feedback

If you're using Django, I'd really appreciate your thoughts.

What health checks are missing?
What features would make this useful in production?
Any ideas for improving the API?

About the author

I'm a backend developer focused on Django, distributed systems, developer tools, and open-source software.

Website: https://cyberhuginn.com

GitHub: https://github.com/cyberhuginn

DEV Community: Saleh Azimidokht

The Hidden Cost of Django REST Framework Serializers

The N+1 Query Problem Hiding Inside a Serializer

SerializerMethodField Is Not Free

The Fix Usually Isn't Inside the Serializer

select_related() vs prefetch_related()

Nested Serializers Make Things Worse

Don't Build One Giant Serializer

Smaller Responses Are Usually Better

Measure Before Optimizing

A Simple DRF Performance Checklist

1. Count the queries

2. Inspect SerializerMethodField

3. Inspect relationship access

4. Check select_related()

5. Check prefetch_related()

6. Look at annotations

7. Reduce nested data

8. Separate serializers

9. Measure again

The Real Cost of a Serializer

Final Thought

django #python #djangorestframework #drf #backend #api #webdevelopment #performance #database #programming

I Built a Signed Webhook Receiver for Cross-Server Communication

Designing a Gold Jewelry E-Commerce Database with Django

The Common Mistake

The Missing Model

Start From Business Scenarios

Why Every Small SaaS Needs Uptime Monitoring

The Hidden Cost of Downtime

Why Manual Monitoring Doesn't Scale

What Should You Monitor?

What Makes a Good Monitoring Tool?

Fast Detection

Reliable Alerts

Easy Setup

Clear Results

Why I Built Bidar

Who Is It For?

Final Thoughts

About the Author

I Built a Lightweight Health Check Package for Django

What it does

Why I built it

What's next?

I'd love your feedback

Links

About the author