The premise was almost too clean. The goal was modest: a test that clicks through creating a campaign the way a real user would, so we'd know the moment a merge broke it. You record that flow once with Playwright's codegen, paste the raw output into a Claude skill, and get back a structured test. No writing selectors by hand, no describing every button. Record, convert, done. I built that workflow, and it worked: the first test went green. That's the dangerous part — the surface really does deliver, which is exactly why you trust it before you've seen what's underneath.

The first cost: the app has to be built to be recorded

Codegen can only record what the page makes addressable. Point it at a button with visible text and you get a clean selector. Point it at a three-dot actions menu with no label, and you get getByRole('button').nth(5), an index that breaks the instant a row reorders. Point it at one of our react-select dropdowns and codegen records .emotion-class-nxiuxh-container > … > .emotion-class-11rjtvl, a chain of generated CSS classes that won't survive the next restyle.

So before you record anything, every interactive element in the flow needs a stable identifier added to the source. Not all of them had one. That meant an audit-and-prep pass through the components first, and another pass every time a new flow gets added later. The "record" step everyone pictures as step one is actually step two.

The second cost: conversion is its own negotiation

Say you've prepped the app and recorded the flow. The conversion still isn't one-click. The skill turns most of the recording into a clean test, then stops at the parts it can't resolve on its own: a selector it doesn't recognize, an element that's ambiguous, a dropdown that still came through as an emotion class. For each one it asks a question, and answering it means going back into the source: add an inputId here, a data-testid there, re-record or hand-patch. A recording is just a list of clicks. The real work is reconstructing the intent behind them, and that work lives half in the test file and half back in the components.

And that's the cost for a short flow. The flows actually worth testing aren't short.

The third cost: the most valuable tests are the most fragile

The whole point of end-to-end testing is the long flow — create a campaign, then a line item inside it, then a visual on top of that. Fifty to a hundred interactive elements in a single chain, the exact journey a real user takes and the exact journey no unit test can cover. That's where the value is. It's also where the fragility is, and it's the same property producing both: the test is long because the flow is long, and every step in it is something that can change. A relabeled field in the middle, a reordered step, a drawer that now opens differently — any one of them breaks the chain from that point on, and a single UI tweak can turn into hours of tracing which step actually moved. The Page Object Model helps here: fix the selector in one class and every test that uses it recovers. But it only softens the blow, it doesn't stop the punches. The flows you most want to protect are the ones that break most often.

The fourth cost: the test data you can't take back

The first three costs are all about getting a test written and keeping it green. The fourth is different in kind. It's about what a test leaves behind. A real campaign flow doesn't just touch our own database; it creates entities on TikTok and Facebook. Internal records you can clean up: record the ID, fire a delete in afterEach, and a nightly cron sweeps whatever a crashed run left orphaned. External entities you can't, at least not reliably. Each platform has its own deletion rules, its own delays, its own idea of what's even allowed. There's no scheduled job that dependably undoes them. And unlike the other three, this cost doesn't shrink as the suite matures. It's a standing risk that grows with every test that touches a real platform.

The cost doesn't end — that's the finding

Here's what ties the four together. A normal feature has a build cost, and then it's done. These costs don't behave that way. The prep, the conversion fixups, the broken chains, the orphaned external data — each one recurs every time the UI moves, and on this product the UI moves every release. You don't build the suite once and walk away. You keep paying for it, and the bill scales with exactly the velocity that makes the product worth testing.

That's why I stopped thinking I was one fix away from done. There was no "finish" to reach at the cost I'd assumed; I just hadn't seen that yet. So the recommendation I brought back wasn't a test suite. It was: pause E2E investment for now, and keep the groundwork in place — the Page Object structure, the recording workflow, the selector conventions, the conversion skill all stay, ready if we ever decide the trade is worth it. The investigation produced something better than the thing we set out to build: a clear-eyed reason not to build it yet, and that turned out to be worth more than the suite would have been.

If you're about to add Playwright to your project

Here's what to actually expect, in plain terms:

None of these are one-time. The setup is the part you can budget for; the rest you pay on every release.

App labels? Migration names? No.

This has been an open issue since ticket #1240, filed in 2006. The discussion already identified app-name completion as the tricky part. Twenty years later it still isn't in core.

I built django-completion to fix it. This article covers that.

The daily friction

The thing that bothered me wasn't forgetting command names. It was the two steps right after:

python manage.py migrate acc<Enter>           # too early — typo
python manage.py migrate accounts 0003<Tab>  # what's the exact filename?

Guessing migration names is the worst. They follow a pattern (0003_add_user_profile) but you have to check the filesystem or run showmigrations first. Either way, you've left the flow.

Why argparse completion doesn't reach this

Tools like argcomplete or Django's own django_bash_completion parse the command's argparse definition and surface flags: --verbosity, --settings, --no-input, etc.

What they can't surface is positional arguments that come from your project — app labels, migration names, test module paths. Those aren't declared in argparse. They're discovered at runtime by loading DJANGO_SETTINGS_MODULE and calling django.setup(), which initializes the full app registry.

Doing that on every keypress is the wrong tradeoff. On a medium-sized project, django.setup() takes 200–500ms. That's noticeable as input lag, and the approach doesn't compose well with virtual environments or uv.

What django-completion does differently

Instead of loading Django at completion time, the approach is inverted:

Discovery happens after commands run, not when Tab is pressed.

After any manage.py command finishes, django-completion rebuilds a small JSON cache at your project root. Tab completion reads that file. No Django import, no database access, no perceptible delay.

Install

pip install django-completion

Add to INSTALLED_APPS:

INSTALLED_APPS = [
    # ...
    "django_completion",
]

Run once to wire up the shell script:

python manage.py autocomplete install

Restart your terminal. Tab works.

All common invocation forms are covered:

manage.py migrate <TAB>
./manage.py migrate <TAB>
python manage.py migrate <TAB>
python3 manage.py migrate <TAB>
uv run python manage.py migrate <TAB>

How it works

After any management command finishes, AppConfig.ready() has patched BaseCommand.execute to spawn a background thread that rebuilds the cache if it's stale. The patch looks like this:

def patched(cmd_self, *args, **kwargs):
    try:
        return original_execute(cmd_self, *args, **kwargs)
    finally:
        thread = threading.Thread(target=maybe_refresh_cache)
        thread.start()

The thread writes .django-completion-cache.json to BASE_DIR — command names, app labels, per-command flags, migration filenames. A 60-second cooldown prevents redundant rebuilds when you run several commands in a row. The cache refresh doesn't block your command at all.

When you press Tab, the shell reads that file and passes the current line to a small Python helper that applies a declarative rule table:

_COMMAND_RULES = {
    "migrate":        CommandRule(pos2="migration_apps",  pos3="migration_names"),
    "showmigrations": CommandRule(pos2="migration_apps",  pos3="options"),
    "makemigrations": CommandRule(pos2="local_apps",      pos3="options"),
    "sqlmigrate":     CommandRule(pos2="migration_apps",  pos3="migration_names_no_zero"),
    "dumpdata":       CommandRule(pos2="all_apps",        pos3="options"),
    "test":           CommandRule(pos2="all_apps",        pos3="options"),
}

migrate at position 2 gets app labels filtered to those that have migrations. At position 3 it gets migration names for the app already typed, plus zero. A word starting with - always triggers flag completion. Commands not in the table fall back to flags only — a safe default for custom management commands.

Two smaller details worth naming: the shell script walks up from $PWD to find the cache file, so completion works from any subdirectory in your project. And makemigrations only surfaces local apps — ones inside BASE_DIR — so django.contrib.admin and friends don't clutter the list.

What's next

• Fish shell — the completion API is different from bash/zsh; the cache format is stable if anyone wants to write a Fish module

• PowerShell — out of scope for me personally, same offer

• Fuzzy matching — there's a stub in the codebase; not shipped yet

Try it

pip install django-completion

• GitHub: github.com/soldatov-ss/django-completion

• Docs: soldatov-ss.github.io/django-completion

• PyPI: pypi.org/project/django-completion

If it breaks on your setup — unusual BASE_DIR, custom MIGRATION_MODULES, monorepo layout — open an issue. Those edge cases are the interesting ones.

If it works, a ⭐ on GitHub helps other Django developers find it.

Let’s talk about the elephant in every Django project: that one models.py file. You know the one. It started pure and simple, a beautiful reflection of your database schema. Now, it's a 2,000-line behemoth, bloated with custom managers, @property decorators that hide monstrous queries, and save() methods that seem to have more side effects than a late-night infomercial product.

Your views are a mess, your business logic is scattered, and making any change feels like performing surgery with a butter knife. In this moment of desperation, a seemingly elegant solution appears: "selectors." Just pull all those messy queries out into a separate selectors.py file! It feels clean. It feels right.

But I'm here to tell you that selectors are a trap. They’re a quick fix that feels like progress but ultimately leads you down a path of architectural pain. There’s a better way, a more structured approach that will save you from future headaches: the Repository and Service patterns. Let’s break down why this combination wins, and why selectors just don’t hold up in the long run.

How We All Got Here

No one sets out to write messy code. We typically arrive here by following well-intentioned advice. In the Django world, the classic mantra is "fat models, thin views." The idea is to keep your views lean and push all the logic related to your data into the corresponding model.

And for a small project, this works beautifully! A User model with a method like is_profile_complete() is perfectly reasonable. But what happens when the logic gets more complex? Soon, you have user.get_recent_orders(), user.calculate_lifetime_value(), and user.send_password_reset_email(). Your model is no longer just a data structure; it's a tangled web of business rules, database queries, and external interactions.

This is when developers, rightly, look for a way to clean up. The selectors.py file is born. You create functions like user_get_active_with_recent_orders() and product_get_top_sellers(). The model slims down, the view calls a clean function—problem solved, right?

Not quite. Honestly, this is like sweeping a pile of dirt under the rug. The room looks cleaner at a glance, but you haven't actually dealt with the mess. You’ve just moved it. This separation is superficial, and as we’ll see, it creates a whole new set of problems.

Repository Pattern 101: Your Data's Bodyguard

So, what’s the alternative? Let’s start with the first piece of the puzzle: the Repository Pattern.

In the simplest terms, a repository is an abstraction layer that sits between your application's business logic and your database. Its one and only job is to handle data access. Think of it as a specialized agent for a particular model. If you need to get users, save a user, or delete a user, you talk to the UserRepository. You design it to serve your use cases, not to mirror every possible query.

Structure:

your_app/
  users/
    models.py
    repositories/
      __init__.py
      users.py
    services/
      __init__.py
      users.py

And here’s what that UserRepository might look like, inheriting from a BaseRepository (like the one here):

# your_app/users/repositories/users.py

from your_app.apps.common.repositories import BaseRepository 
from your_app.users.models import User
from typing import Optional


class UserRepository(BaseRepository):
    def get_by_id(self, user_id: int) -> Optional[User]:
        return self.filter(id=user_id).first()

    def get_by_email(self, email: str) -> Optional[User]:
        return self.filter(email=email).first()

Why this matters

• Clear contract. It provides a single, explicit interface for data operations. No more User.objects.filter(...) scattered across 20 different files. You centralize your query logic in one place.

• Centralized query intent. If a flow needs special prefetch or annotations, you add a method and keep it consistent.

• Test seams. You can pass a fake repository in tests. You can add caching or logging in one place without hunting through views.

The service layer, also known as the brain

If repositories are your data's bodyguards, services are the brain of the operation. Services sit above repositories to orchestrate business workflows and enforce rules. They are where your transactions should begin and end. If a business rule changes—like "premium users get priority processing"—you want one, and only one, place to make that change.

The best analogy is this: Repositories fetch the ingredients. Services follow the recipe to cook the meal.

A service doesn't know how the ingredients are fetched (that's the repository's job), and the view doesn't know how the meal is cooked. The view just says, "I'd like to order the 'New User Registration' please."

# users/services/users.py

from .repositories import UserRepository
# Assume a NotificationService exists elsewhere
from notifications.services import NotificationService

class UserService:
    def __init__(self, user_repo: UserRepository, notification_service: NotificationService):
        self.user_repo = user_repo
        self.notification_service = notification_service

    def register_user(self, email: str, name: str) -> User:
        # Business rule: check if user already exists
        if self.user_repo.get_by_email(email):
            raise ValueError("User with this email already exists.")

        # Step 1: Create the user via the repository
        user = self.user_repo.create(email=email, name=name)

        # Step 2: Orchestrate another action
        self.notification_service.send_welcome_email(user.email)

        return user

This is clean, transactional, and easy to follow.

The Real Risk of Selectors: A Slippery Slope

So if services are the brain, why not just use selectors for the data? The risk isn't that selectors are inherently bad, but that they are a slippery slope.

They lack a strong architectural boundary, making it too easy to add "just one little piece" of business logic. Over time, these small compromises turn your clean query file into a tangled, secondary business logic layer.

The Repository and Service pattern prevents this by creating explicit guardrails.

• Repositories have one job: get data.

• Services have one job: enforce business rules.

This clear separation makes the right path the easy path and prevents the slow decay of your architecture.

Admin actions, celery tasks, and the rest of the crew

Keep the same pattern everywhere. Admin actions call services. Celery tasks call services. Management commands call services. DRF viewsets and APIViews call services. One flow. One place for idempotency and retries. If a task runs twice, the service checks state and either skips or continues.

Wiring it together: init.py as a composition root

Once you have repositories and services, you still need to instantiate them somewhere. A clean way to handle this is to use the package's __init__.py as a composition root: one file that wires dependencies together and exports ready-to-use singletons.

users/
  services/
    __init__.py   ← wires everything here
    users.py
    notifications.py

# users/services/__init__.py

from .notifications import NotificationService
from .users import UserService
from users.repositories import user_repository

notification_service = NotificationService()
user_service = UserService(
    user_repo=user_repository,
    notification_service=notification_service,
)

__all__ = [
    "user_service",
    "notification_service",
]

Now callers import a single, already-wired object:

# instead of this
from users.services.users import UserService
user_service = UserService(user_repo=..., notification_service=...)

# just this
from users.services import user_service

This keeps instantiation in one place, hides the internal module structure, and makes the public API explicit via __all__.

One tradeoff to know: services are instantiated at import time. If a test needs different wiring — say, a fake repository — it can't swap the dependency before the module loads. The fix is unittest.mock.patch on the singleton, or instantiating locally in the test. Neither is painful, but it's worth knowing before you adopt the pattern.

Common questions you will hear on the team

• Can I keep a small helper on the model. Yes, if it only touches that model’s state.

• Do I always need a service. If a view is a straight read, repo to serializer can be fine. When you branch or change state, reach for a service.

• Do I need a repo per model. Start where it helps most. Big aggregates, heavy queries, hot paths. Let the layer grow with need.

• Can selectors live beside repos. If they exist, make them thin wrappers over repos, not a separate source of truth.

• How does this fit with DRF? Your viewset or APIView calls the service, then passes the result to a serializer. The service never touches the request object or serializer context. That boundary keeps your business logic framework-agnostic — the same service works from a Celery task or a management command without modification.

Why this matters on teams, not only in code

Clean layers make it easier to talk. A PM says, payment failed on retry. You look at one place. A junior asks, where should I put this logic. You have a ready answer. A reviewer reads a PR and knows exactly which patterns to expect. The shape of the system stays steady as the people change.

Also, repositories act like discreet places to teach performance. You can add little comments, like why you used select_for_update here, or why an index matters. New teammates learn by seeing the same pattern in many methods. That is softer than sending a long wiki doc that nobody reads twice.

Conclusion: Choose Clarity Over Convenience

Look, selectors aren't born from malice. They come from a good place: the desire to clean up messy code. They offer a moment of relief, a feeling of organization. But it’s a temporary fix. They are a crutch, not a long-term architectural strategy.

The Repository and Service patterns require a bit more discipline upfront. You have to think about your application's layers and enforce those boundaries Keep models slim. Put data access in repositories. Put rules in services. Own transactions at the service layer. Be consistent.

Welcome to the second half of our guide on DRF architecture. In Part 1, we established a clear rule: serializers are the guardians of your data. They handle validation, transformation, and representation. They ensure that the data entering your system is clean and the data leaving is well-formed.

But that’s only half the picture.

The ViewSet's Core Mission: Orchestration

Viewsets handle the HTTP journey. They don't care if a start_date is before an end_date — that's the serializer's job. They care about things like:

• Parsing the incoming request.
• Checking permissions and authentication.
• Calling the serializer to validate data.
• Triggering the save operation.
• Formatting the final Response with the right data and status code.

Let's explore the most common and powerful methods you can override.

The Big Showdown: create vs. perform_create

This is where so much confusion happens. Both seem to do the same thing! But their purpose is completely different, and choosing the right one is key to clean code.

• Override create(self, request, *args, **kwargs) when you need to change the orchestration of the request or the shape of the final response. Do you need to return a 202 Accepted instead of a 201 Created? Do you need to wrap the response in a { "data": ... } envelope? Do you need to do something before the serializer is even validated? That's a job for create.

• Override perform_create(self, serializer) when you just need to tweak how the object is saved. This is a much cleaner, more focused hook. The default create method calls this after validation is successful. It's the perfect place to inject the current user or tenant ID right before saving.

A practical rule of thumb: Always try to use perform_create first. Only override the full create method if you absolutely have to manipulate the HTTP response or the flow itself.

# In your OrderViewSet
class OrderViewSet(viewsets.ModelViewSet):
    # ... queryset and serializer_class definitions ...

    # This is the CLEAN way to stamp the user
    def perform_create(self, serializer):
        # The serializer is already validated here.
        serializer.save(customer=self.request.user)

    # Only override this if you need to change the whole dance
    def create(self, request, *args, **kwargs):
        # Maybe you need to check inventory before even trying to validate
        if not check_inventory(request.data):
            return Response({"error": "Item out of stock"}, status=status.HTTP_400_BAD_REQUEST)

        # Now call the original 'create' logic
        return super().create(request, *args, **kwargs)

This principle of separating the HTTP-level orchestration (create) from the persistence hook (perform_create) is key. Now, let's apply that same logic to updates.

The Update Trinity: update (PUT), partial_update (PATCH), and perform_update

Updates are more complex than creates because there are two different ways to do them: a full update (PUT) and a partial one (PATCH). DRF gives you three distinct methods to control this process.

First, let's get the flow right. It's a common point of confusion. The methods update and partial_update are peers; one does not call the other.

• A PUT request is routed to the update() method. After validation, update() calls perform_update() to save the changes. Flow: PUT Request → update() → perform_update() → serializer.save()

• A PATCH request is routed to the partial_update() method. After partial validation, partial_update() also calls perform_update() to save the changes. Flow: PATCH Request → partial_update() → perform_update() → serializer.save()

perform_update() is the shared, final step for both. With that in mind, here’s when to override each one.

When to Override perform_update(self, serializer)

This is your go-to hook for 90% of update logic. Override perform_update when you have code that must run for any update, whether it's a PUT or a PATCH. It keeps your code DRY (Don't Repeat Yourself) by providing a single place for shared save-time logic.

• Why Override? You need to stamp a field, clear a cache, or log an update without caring if it was a full or partial change.
• Example: You always want to record which user was the last person to modify an object.

def perform_update(self, serializer):
    # This logic runs for both PUT and PATCH, after validation.
    # It's the cleanest place for shared save-time hooks.
    serializer.save(last_updated_by=self.request.user)

When to Override partial_update(self, request, *args, **kwargs)

Override the partial_update method for logic that should only run during a partial change (PATCH). This is incredibly useful for implementing fine-grained permissions or triggering specific side effects when certain fields are modified

• Why Override? You want to allow different update rules for different fields, or you want to react to specific, targeted changes.
• Example: In a project management system, maybe anyone can PATCH a task's description, but only a manager can PATCH its due_date. Overriding partial_update is the perfect place to check for this.

def partial_update(self, request, *args, **kwargs):
    # Custom logic just for PATCH
    if 'due_date' in request.data and not request.user.is_manager:
        return Response({"error": "Only managers can change the due date."}, status=status.HTTP_403_FORBIDDEN)
    
    # Another example: trigger a notification ONLY if the status changes
    if 'status' in request.data:
        instance = self.get_object()
        old_status = instance.status
        new_status = request.data['status']
        if old_status != new_status:
            notify_team_of_status_change(instance, new_status)

    return super().partial_update(request, *args, **kwargs)

When to Override update(self, request, *args, **kwargs)

Override the update method when you need to add logic that is specific to a full resource replacement (PUT). Because PUT implies replacing the entire resource, you might have preconditions or post-conditions that don't apply to a simple PATCH.

• Why Override? You want to enforce a strict "all or nothing" replacement policy or perform an action that only makes sense when the entire object is changed.
• Example: Imagine you have a Settings object. You could override update to ensure that a PUT request truly contains every single required setting field, preventing users from accidentally wiping out settings by sending an incomplete object. You could also log a specific "Settings Overwritten" event that is more severe than a simple field change.

def update(self, request, *args, **kwargs):
    # Custom logic just for PUT
    if not all(key in request.data for key in ['theme', 'notifications', 'timezone']):
        return Response({"error": "A full update requires all setting keys."}, status=status.HTTP_400_BAD_REQUEST)
    
    # Log the major change
    log_settings_overwritten(user=request.user)
    
    return super().update(request, *args, **kwargs)

Other Useful ViewSet Hooks

Beyond create and update, other methods give you powerful control over the request lifecycle:

• list(): Override this when you need to reshape the entire list response beyond a simple array of objects, for example, by adding metadata or aggregation summaries.

• retrieve(): Perfect for when a single object's response needs extra context that depends on the request, like adding a can_edit flag for the current user.

• destroy(): The default just deletes the object. Override this to implement soft deletes, check for dependencies, or record an audit log event.

• get_queryset(): This is one of the most important overrides for performance and security. It’s where you scope the data (e.g., a user only sees their own invoices) and where you should add performance boosters like select_related and prefetch_related.

• get_serializer_class(): Your viewset's "chameleon." It lets you use different serializers for different actions (e.g., a summary for list, details for retrieve).

• get_permissions(): Great for when permissions change based on the action (e.g., anyone can GET, but only staff can POST).

The Decision Guide: Where Does This Logic Go?

Let’s boil everything from both articles down to a simple cheat sheet for a clean DRF architecture:

• Is it about the shape, structure, or validity of data?

  • Answer: Serializer (validate, validate_<field>, to_representation).

• Is it about managing the HTTP request/response flow, like returning a custom status code or handling action-specific permissions?

  • Answer: ViewSet action (create, update, list, etc.).

• Is it about changing how an object is saved after validation, for both PUT and PATCH?

  • Answer: ViewSet perform_* method (perform_create, perform_update).

• Is it about filtering the main list of objects based on the user or request?

  • Answer: ViewSet get_queryset method.

Keeping these boundaries clear isn't just an abstract architectural exercise. It’s a practical strategy for building software that can grow and adapt without collapsing under its own weight. Your team will thank you. And more importantly, your future self will, too.

Ask any Django developer where to put validation, formatting, and orchestration logic, and you’ll often get different answers — some say “just put it in the serializer,” others drop everything in the viewset.

This works… until it doesn’t. When your API grows, mixing concerns makes code brittle, hard to test, and painful to maintain. Knowing exactly when to override a serializer method and when to override a viewset method is key to keeping a codebase clean.

The Serializer's Core Mission

Think of your serializer as the security guard at the door of your database. It's responsible for three primary tasks:

1. Validation: Checking the ID of incoming data to ensure it's legitimate.
2. Transformation: Making sure the data is in the right format before being saved.
3. Representation: Deciding how the data should be presented when it's sent back out.

Its world is small and focused: just the data. Let's look at the tools it uses.

1) Serializer method overrides

Role Serializers control what may enter and how it leaves: validation, input normalization, output formatting.

validate_<field_name>(self, value) - field-level checks This is your go-to for single-field validation. Django's model fields and DRF's serializer fields handle the basics, like checking if a field is an integer or a valid email. But what about your specific business rules?

Use this when a single field has a rule that only it needs to worry about.

Example: Imagine you have a Product model with a discount_percentage field. For most products, any discount is fine. But for the "Electronics" category, you need to cap it at 50% to protect your margins.

validate(self, data) - cross-field validation Sometimes fields can't be validated in isolation. They have relationships; they depend on each other. validate is where your fields have a conversation. It runs after all the individual validate_<field> methods have passed.

Use this for cross-field validation. Example: A classic case is a PromoCampaign model with a start_date and an end_date. It makes no sense for the promotion to end before it even begins.

def validate(self, data):
    """
    Check that the start date is before the end date.
    """
    if data['start_date'] > data['end_date']:
        raise serializers.ValidationError("End date must occur after start date.")
    return data

Simple enough, right? This keeps your data integrity rules right next to the data definition.

create(self, validated_data) DRF's default create method is wonderfully simple: it just unpacks your validated data and calls YourModel.objects.create(**validated_data). But sometimes "simple" isn't enough.

• Override create when you need to control exactly how a new object instance comes into being. This could mean:
• Creating related objects in the same transaction.
• Injecting data that doesn't come from the user, like created_by=self.context['request'].user.
• Handling nested serializers for write operations.

# In a UserProfileSerializer that also creates a user
def create(self, validated_data):
    user_data = validated_data.pop('user')
    user = User.objects.create_user(**user_data)
    # Stamp the current user from the view's context
    created_by_user = self.context['request'].user
    profile = UserProfile.objects.create(user=user, created_by=created_by_user, **validated_data)
    return profile

update(self, instance, validated_data) Just like create, the default update method loops through the validated data and does a setattr(instance, key, value) for each item before calling instance.save(). You should override it when you have more complex update logic.

Maybe you need to prevent updates if an order is already "shipped." Or perhaps updating one field requires a calculated change to another.

Example: When updating a blog post, you want to replace all its tags, not just add new ones. The default update for a many-to-many relationship might not do exactly what you want.

# In a PostSerializer with a 'tags' field
def update(self, instance, validated_data):
    tags_data = validated_data.pop('tags', None)

    # This is the default behavior for all other fields
    instance = super().update(instance, validated_data)

    # Now, handle the tags with our custom logic
    if tags_data is not None:
        instance.tags.set(tags_data) # Replaces all existing tags

    return instance

to_representation(self, instance) This is the "glow-up" method. It's the last stop before your data is serialized and sent out into the world. Its job is to shape the outbound data. The model might store a user ID, but you want to show their full name. The database has a first_name and last_name, but you want to add a full_name field to the API response.

Example: Add a computed field to your User serializer.

# In your UserSerializer
def to_representation(self, instance):
    # Get the default representation
    representation = super().to_representation(instance)
    # Add our custom field
    representation['full_name'] = instance.get_full_name()
    return representation

So, When Should Serializers Just Say No?

This is just as important. A serializer that does too much becomes a god object. Here’s what doesn't belong in a serializer:

Heavy Side Effects: Sending emails, charging credit cards, updating inventory in another system, calling third-party APIs. This is a one-way ticket to a maintenance nightmare. If the database transaction fails after the email is sent, what do you do? This logic belongs elsewhere.

Complex Queries: A serializer's validate method shouldn't be making five different database calls to check a condition. That logic should live in a dedicated place (like a "selector" function or repository's function) and be called from the view.

Business Workflows: A multi-step process, like "register user, create trial subscription, and schedule a welcome email," is a business workflow. It's too high-level for a serializer. This is a job for a service layer.

In Part 2 of this series, we’ll dive into the ViewSet's role as the orchestra's conductor and explore how to use its methods—and a service layer—to keep your application logic clean and organized.