Cities are growing faster than governments can keep up with. Roads get built, encroachments happen, properties go unmapped, and green cover disappears — often without anyone in city administration even noticing. The result? Outdated records, revenue leakage, and infrastructure that’s impossible to manage efficiently.

At our internal hackathon, we set out to fix this with Urban Asset Intelligence — an AI-powered platform that analyzes satellite and drone imagery to automatically detect, classify, and register urban assets on a live map.

The Problem No One Talks About

Most city administrations still rely on manual field surveys to maintain their asset registries. This means records are always months or years out of date, illegal encroachments go undetected until it’s too late, and infrastructure maintenance is reactive — not proactive.

There’s no single source of truth for what a city actually contains. We wanted to build one.

What We Built

Urban Asset Intelligence is an end-to-end platform that takes a satellite or drone image as input and outputs a fully annotated, geo-referenced map of urban assets within seconds. Upload an image and get back detected buildings, roads, water bodies, parks, drains, and trees — each tagged with coordinates, estimated dimensions, and an area summary. All exportable as GeoJSON, JSON, or CSV, and ready to plug into governance systems like DIGIT Urban Governance.

How the Pipeline Works

Under the Hood: The Tech Stack

Three Asset Categories Detected so far

- 🏢 Buildings & Properties

- 🌳 Trees & Green Cover

- 💧 Water Bodies

Each detected asset is tagged with its boundary polygon, estimated area, and GPS coordinates — ready for ingestion into a city’s asset registry.

Why This Matters

The impact goes beyond just having a prettier map:

- Track Infrastructure at scale without expensive field surveys

- Improve Governance with accurate, real-time asset data

- Enable Smart Urban Planning backed by current ground truth

- Reduce Revenue Loss by surfacing unmapped and encroached properties

Built for integration with DIGIT Urban Governance, the platform is designed to slot into existing municipal workflows rather than replace them.

What We Learned

Training a segmentation model on satellite imagery is humbling. Rooftops look like roads from above. Shadows fool the model. Resolution matters enormously. We spent a significant portion of the hackathon just understanding *why* the model was wrong, not just fixing it.

The LLM integration — using Groq to generate natural language reports from detection outputs — turned out to be one of the most demo-friendly features we built. Seeing a model describe a neighborhood’s infrastructure in plain English from a satellite image is genuinely striking.

What’s Next

We’re just getting started. On the roadmap:

- Temporal monitoring with automated alerts for detected changes

- Multi-city deployment with federated data

- Integration with IoT sensor data for real-time infrastructure health

- Finer-grained asset categories (building type, road condition, encroachment probability)

If you’re working on smart city tech, urban governance, or satellite imagery ML — we’d love to connect. Drop a comment or reach out directly.

Built at an internal hackathon · YOLOv11 · DeepGlobe · FastAPI · React

*Thanks for reading! If this resonated, give it a clap 👏 — it helps others find the project.*

Singleton ensures only one instance of a class exists and provides a global access point to it.

Real World Use case: For Logger, Database Connection, Configuration Manager.

Problem

Creating multiple instances of a class like a logger and DBContext can cause:

• Resource wastage
• Inconsistent state
• Hard-to-manage global resources

1. Classic Singleton (Not Thread-Safe)Because Mutliple thread can access the instance:

#include <bits/stdc++.h>
using namespace std;

class Logger {
private:
    // Static pointer to hold the single instance of Logger
    static Logger* instance;

    // Mutex to ensure thread safety in multi-threaded environment
    static mutex mtx;

    // Private constructor
    // Prevents object creation from outside the class
    Logger() {
        cout << "Logger instance created" << endl;
    }

    // -------------------------------
    // Prevent breaking Singleton
    // -------------------------------

    // Disable copy constructor
    Logger(const Logger&) = delete;

    // Disable copy assignment operator
    Logger& operator=(const Logger&) = delete;

    // Disable move constructor (optional but recommended)
    Logger(Logger&&) = delete;

    // Disable move assignment operator
    Logger& operator=(Logger&&) = delete;

public:
    // Static method to provide global access to the instance
    // Static because it belongs to the class, not to any object
    static Logger* getInstance() {

        // Lock mutex to ensure only one thread can enter this block
        lock_guard<mutex> lock(mtx);

        // Lazy Initialization:
        // Create instance only when it is first requested
        if (instance == nullptr) {
            lock_guard<mutex> lock(mtx);
            instance = new Logger();
        }

        // Return the same instance every time
        return instance;
    }

    // Example logging method
    void log(const string& message) {
        cout << "[LOG]: " << message << endl;
    }
};

// Static member initialization
Logger* Logger::instance = nullptr;
mutex Logger::mtx;

int main() {
    // Get Logger instance multiple times
    Logger* logger1 = Logger::getInstance();
    Logger* logger2 = Logger::getInstance();

    // Both pointers should point to the same instance
    if (logger1 == logger2) {
        cout << "Both logger instances are the same." << endl;
    } else {
        cout << "Different logger instances created!" << endl;
    }

    // Using logger
    logger1->log("Application started");
    logger2->log("Logging from same instance");

    return 0;
}

Highlights:

• Only one instance is created.
• Client doesn’t use new directly.

2: Eager Initialization (Early Load) Singleton

What is Eager Initialization?

The Singleton instance is created at program start, not when it is first requested.

#include <bits/stdc++.h>
using namespace std;

class Logger {
private:
    // Instance is created at load time (before main())
    static Logger* instance;

    // Private constructor
    Logger() {
        cout << "Logger instance created at load time" << endl;
    }

    // Prevent copy and assignment
    Logger(const Logger&) = delete;
    Logger& operator=(const Logger&) = delete;

public:
    // Global access point
    static Logger* getInstance() {
        return instance;
    }

    void log(const string& message) {
        cout << "[LOG]: " << message << endl;
    }
};

// Instance created eagerly at program start
Logger* Logger::instance = new Logger();

int main() {
    // Instance already exists even before this line
    Logger* logger = Logger::getInstance();
    logger->log("Application started");

    return 0;
}

Disadvantages of Eager Initialization
1. Resource Wastage

• Instance is created even if it is never used
• Bad for heavy objects (DB connection, file logger, network setup)

2. Slower Application Startup

• Object creation happens before main()
• Can increase application startup time

3. No Lazy Control

• You lose control over when the object is created
• Not ideal when initialization depends on runtime configuration

4. Harder to Handle Failures

• If constructor throws an error → application may fail during startup
• Debugging becomes difficult

When Eager Singleton Is Acceptable

• Constructor is very lightweight
• Instance is always required
• Application startup cost is not critical

Eager Singleton creates the instance at startup, while Lazy Singleton creates it only when needed — making Lazy initialization more memory and performance efficient.

Factory Design Pattern is a creational design pattern that provides an interface for creating objects, but allows subclasses or factory classes to decide which class to instantiate.

In Simple Words:

Factory Design Pattern helps us decouple object creation from the client code by moving the creation logic to a separate factory class.
The client only asks for an object , it doesn’t care how or which object is created.

Let’s take Example of Real World Problem:

Problem Statement:
Imagine we are building a Notification System that supports:

• Email
• SMS
• Push Notifications

Without a factory, the code looks like this:

if(type == "EMAIL") {
   new EmailNotification().send();
} else if(type == "SMS") {
   new SmsNotification().send();
}

Problems

• Too many if-else conditions
• Violates Open/Closed Principle
• Hard to maintain and extend
• Tight coupling between client and concrete classes

Use Cases (Why Factory?)

• Payment gateways (UPI, Card, Wallet)
• Notification systems (Email, SMS, Push)
• Logging frameworks
• Database drivers
• Cloud SDKs (AWS, Azure, GCP)

Simple Factory Pattern
A Simple Factory uses a single factory class to create objects based on input.

#include <iostream>
#include <string>
using namespace std;

// Product Interface
class Notification {
public:
    virtual void send() = 0;
    virtual ~Notification() {}
};

// Concrete Products
class EmailNotification : public Notification {
public:
    void send() override {
        cout << "Sending Email Notification" << endl;
    }
};

class SmsNotification : public Notification {
public:
    void send() override {
        cout << "Sending SMS Notification" << endl;
    }
};

// Simple Factory
class NotificationFactory {
public:
    static Notification* createNotification(const string& type) {
        if (type == "EMAIL") return new EmailNotification();
        if (type == "SMS") return new SmsNotification();
        return nullptr;
    }
};

// Usage
int main() {
    Notification* n1 = NotificationFactory::createNotification("EMAIL");
    n1->send();

    Notification* n2 = NotificationFactory::createNotification("SMS");
    n2->send();

    delete n1;
    delete n2;
    return 0;
}

Limitation

• Simple Factory still contains conditional logic
• Not fully extensible

Factory Method Pattern (Most Important)

The Factory Method Pattern defines an interface for creating objects, but lets subclasses decide which class to instantiate.

#include <iostream>
using namespace std;

// Product Interface
class Notification {
public:
    virtual void send() = 0;
    virtual ~Notification() {}
};

// Concrete Products
class EmailNotification : public Notification {
public:
    void send() override {
        cout << "Sending Email Notification" << endl;
    }
};

class SmsNotification : public Notification {
public:
    void send() override {
        cout << "Sending SMS Notification" << endl;
    }
};

// Factory Interface
class NotificationFactory {
public:
    virtual Notification* createNotification() = 0;
    virtual ~NotificationFactory() {}
};

// Concrete Factories
class EmailFactory : public NotificationFactory {
public:
    Notification* createNotification() override {
        return new EmailNotification();
    }
};

class SmsFactory : public NotificationFactory {
public:
    Notification* createNotification() override {
        return new SmsNotification();
    }
};

// Usage
int main() {
    NotificationFactory* factory1 = new EmailFactory();
    Notification* n1 = factory1->createNotification();
    n1->send();

    NotificationFactory* factory2 = new SmsFactory();
    Notification* n2 = factory2->createNotification();
    n2->send();

    delete n1;
    delete n2;
    delete factory1;
    delete factory2;

    return 0;
}

Benefits

• No if-else
• Follows Open/Closed Principle
• Easy to extend
• Highly used in frameworks

Abstract Factory Pattern (Advanced)

The Abstract Factory Pattern provides an interface to create families of related objects without specifying their concrete classes.

Real-World Example

• AWS Notification Factory
• Firebase Notification Factory

#include <iostream>
using namespace std;

// Abstract Products
class Email {
public:
    virtual void send() = 0;
    virtual ~Email() {}
};

class Sms {
public:
    virtual void send() = 0;
    virtual ~Sms() {}
};

// Concrete Products (AWS)
class AwsEmail : public Email {
public:
    void send() override { cout << "AWS Email Sent" << endl; }
};

class AwsSms : public Sms {
public:
    void send() override { cout << "AWS SMS Sent" << endl; }
};

// Abstract Factory
class NotificationFactory {
public:
    virtual Email* createEmail() = 0;
    virtual Sms* createSms() = 0;
    virtual ~NotificationFactory() {}
};

// Concrete Factory
class AwsNotificationFactory : public NotificationFactory {
public:
    Email* createEmail() override { return new AwsEmail(); }
    Sms* createSms() override { return new AwsSms(); }
};

// Usage
int main() {
    NotificationFactory* factory = new AwsNotificationFactory();
    Email* email = factory->createEmail();
    Sms* sms = factory->createSms();

    email->send();
    sms->send();

    delete email;
    delete sms;
    delete factory;
    return 0;
}

When to Use

• Large-scale systems
• Multiple product families
• Enterprise applications

Strategy focuses on choosing an algorithm at runtime, while Factory focuses on creating objects without exposing the instantiation logic to the client.

Introduction to Design Patterns

In real-world software systems, change is inevitable. New features are added, requirements evolve, and behaviors vary over time. If our design is rigid, even a small change can ripple through the entire codebase.

This is where Design Patterns help.

Design Patterns are proven, reusable solutions to recurring software design problems.

A core idea behind many design patterns is:

Encapsulate what varies and separate it from what stays the same.

The Strategy Design Pattern is one of the best examples of this idea in action.

The Common Mistake: Solving Everything with Inheritance

Most developers naturally start with inheritance.
It feels intuitive, clean, and object-oriented.

But inheritance has a hidden limitation.

Inheritance works well when variation exists in only one dimension.
When behavior varies in multiple dimensions, inheritance quickly breaks down.
Let’s understand this with examples.

Example 1: Robot System
Problem Statement:
We are building a Robot Simulation System.
Different robots may have different abilities:

• Walk / Cannot Walk
• Talk / Cannot Talk
• Fly / Cannot Fly

Inheritance-Based Design (The Wrong Turn)
A typical inheritance-based solution looks like this:

What’s Wrong Here?

1. Class explosion: Each new combination of abilities creates a new subclass.

2. Poor scalability: Adding a new ability (e.g., Swim) multiplies the hierarchy.

3. Violates SOLID principles

• SRP: Robots handle too many responsibilities
• OCP: Existing classes must be modified for new behavior

Inheritance is growing in multiple dimensions ->this is the real problem.

Key Insight :

Inheritance models “is-a” relationships.
Strategy models “can-do” behaviors.

Robots don’t become walkable or talkable — they perform walking or talking.

This leads us to the Strategy Pattern.

Introducing the Strategy Design Pattern

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime.

Strategy-Based Design (Robot Example)
Step 1: Identify the Changing Parts

• Walking behavior
• Talking behavior
• Flying behavior

Each behavior varies independently.

Class Diagram — Strategy Pattern (Robot)

Why This Works

No inheritance explosion
Behaviors are reusable
New behavior added without touching existing code
Composition over inheritance

Code Example :

#include <bits/stdc++.h>
using namespace std;

// ---------- Walk Strategy ----------
class Walkable {
public:
    virtual void walk() = 0;
    virtual ~Walkable() {}
};

class NormalWalk : public Walkable {
public:
    void walk() override {
        cout << "Walking normally" << endl;
    }
};

class NoWalk : public Walkable {
public:
    void walk() override {
        cout << "Cannot walk" << endl;
    }
};

// ---------- Talk Strategy ----------
class Talkable {
public:
    virtual void talk() = 0;
    virtual ~Talkable() {}
};

class NormalTalk : public Talkable {
public:
    void talk() override {
        cout << "Talking normally" << endl;
    }
};

class NoTalk : public Talkable {
public:
    void talk() override {
        cout << "Cannot talk" << endl;
    }
};

// ---------- Fly Strategy ----------
class Flyable {
public:
    virtual void fly() = 0;
    virtual ~Flyable() {}
};

class NormalFly : public Flyable {
public:
    void fly() override {
        cout << "Flying normally" << endl;
    }
};

class NoFly : public Flyable {
public:
    void fly() override {
        cout << "Cannot fly" << endl;
    }
};

// ---------- Context ----------
class Robot {
protected:
    Walkable* walkable;
    Talkable* talkable;
    Flyable* flyable;

public:
    Robot(Walkable* w, Talkable* t, Flyable* f)
        : walkable(w), talkable(t), flyable(f) {}

    virtual void projection() = 0;

    void performWalk() { walkable->walk(); }
    void performTalk() { talkable->talk(); }
    void performFly()  { flyable->fly(); }

    virtual ~Robot() {
        delete walkable;
        delete talkable;
        delete flyable;
    }
};

// ---------- Concrete Robots ----------
class CompanionRobot : public Robot {
public:
    CompanionRobot()
        : Robot(new NormalWalk(), new NormalTalk(), new NoFly()) {}

    void projection() override {
        cout << "I am a Companion Robot" << endl;
    }
};

class WorkerRobot : public Robot {
public:
    WorkerRobot()
        : Robot(new NormalWalk(), new NoTalk(), new NoFly()) {}

    void projection() override {
        cout << "I am a Worker Robot" << endl;
    }
};

// ---------- Main ----------
int main() {
    Robot* companion = new CompanionRobot();
    companion->projection();
    companion->performWalk();
    companion->performTalk();
    companion->performFly();

    cout << "-------------------" << endl;

    Robot* worker = new WorkerRobot();
    worker->projection();
    worker->performWalk();
    worker->performTalk();
    worker->performFly();

    delete companion;
    delete worker;

    return 0;
}

This problem is very common in real systems like payment methods, notification systems, and pricing engines, where behavior changes independently.”

🏫 The College Analogy

🏫 VNet = Private College

• A secure space where only authorized people and services can enter.

👤 Private Link = Admission Approval System

• Think of Private Link as the permission system that grants students (apps) access to specific departments (Azure services) securely inside the college (VNet).

📄 Private Endpoint = Student ID + Gate Pass

• A Private Endpoint is like a physical ID card and gate pass that gives a specific student the right to enter a certain department.
• It creates a network interface (NIC) with a private IP address inside your VNet that connects to a specific Azure resource.

🛏️ NSG / Firewall = College Watchman

• Network Security Groups and firewalls are like security guards who validate whether the student with an ID is allowed to go to a certain department or not.

📁 What is DNS?

• DNS (Domain Name System) is like the college receptionist or student directory.
• When you ask for a service like mydb.database.windows.net, it tells you the room number (IP address).

🌐 Public DNS = Info Booth for Outsiders

• Anyone can ask for a public domain and be routed to an external (public) IP.

🏢 Private DNS Zone = Internal Directory

• Only accessible from inside the college (your VNet).
• Points domain names to private IP addresses.

🧬 DNS Resolution = Asking Receptionist for a Room

• You ask where the DB is. If the receptionist finds a private DNS entry, they give you the internal room number.
• Otherwise, you might be sent outside the college.

Putting It All Together

Let’s say you have a database at mydb.database.windows.net, and you want to access it privately:

1. You enable Private Link on the DB.
2. You create a Private Endpoint in your VNet.
3. Azure assigns it a private IP and sets up a DNS entry like:
   mydb.privatelink.database.windows.net -> 10.1.0.5
4. You link a Private DNS Zone to your VNet.
5. Now when you access mydb.database.windows.net, Azure rewrites it to the private version, and you stay inside the college.

Summaries table contents

Azure Concept College Analogy Role VNet Private College Secure boundary Private Link Admission system Grants access to services Private Endpoint Student ID + Gate Pass Entry point with private IP NSG / Firewall Watchman Controls traffic Public DNS Info booth for outsiders Public directory Private DNS Zone Internal map/directory Private resolution DNS Resolution Asking receptionist Name to IP translation

Why This Matters

Understanding these concepts is critical when you’re:

• Accessing Azure PaaS services (like SQL, Storage, PostgreSQL) from AKS or VMs securely.
• Avoiding data exposure to the internet.
• Building enterprise-grade, secure, and compliant architectures.

System Design: The Importance for Software Engineers

When we talk about small or large applications, system design helps us build a high-level understanding of the components of an application and their relationships with each other.

Why do we focus on components? Because to ensure the success of a project, we can divide it into components so that it becomes well-structured, maintainable, scalable, and meets user requirements.

Now, let’s talk about what system design is.

In simple terms, system design is an approach by which we structure a system to ensure it meets required functionality, performance, scalability, and other quality attributes.

It is the process of defining the architecture of components, data, etc., for a system to satisfy both functional (what the system is doing, related to a specific task) and non-functional requirements (how the system should perform, system attributes, or quality attributes).

What are the key factors we need to ensure when designing a good system?

• Scalability (both horizontal and vertical)
• Caching
• Load balancing
• Data partitioning
• Various types of databases
• Network protocols
• Database sharding, etc.

Similarly, we must consider various trade-offs, such as:

• Latency vs throughput
• Performance vs scalability
• Consistency vs availability

When it comes to deploying applications, there’s always been a big challenge in traditional methods. Let’s break down why this is an issue, and how containers, like Docker, came to solve it.

The Problems with Traditional Deployment

In the traditional way, developers write code and test it on their local machines. Everything seems to work fine, so they push the code to version control, and from there, it gets promoted through different environments. It’s then sent to the testing environment, where it works with the same setup as the development environment. Everything seems good, and the application passes all the tests.

But here’s where things start to go wrong. Once the code gets handed off to the operations team and moves into the production environment, it fails. Suddenly, it’s not working as expected. The developer might scratch their head and say, “But it worked fine on my machine!” Meanwhile, the operations team is left confused and frustrated.

The problem often lies in the misconfiguration of environments. The dependencies, libraries, and settings in production might be slightly different from what was in the developer’s environment. These little differences cause big issues, and sometimes the only way to fix them is by going through a lengthy change request process, which can slow everything down.

This disconnect between development and production is a huge problem that causes unnecessary delays and confusion. And it’s precisely this issue that containers, like Docker, aim to fix.

How Containers Help Fix This Problem

The issue we face with traditional deployment is that there’s no simple way to pack all the libraries, dependencies, and configurations needed for an application into a single, portable unit. When the application is moved to a different environment, things can break.

This is where containers come into play. A container is an isolated environment that includes everything the application needs to run — the code, the libraries, the dependencies, and the runtime (including the operating system). This means that, regardless of where you run the container — whether it’s on a developer’s machine, a testing server, or in production — it will behave exactly the same. No more “works on my machine” excuses.

What Exactly Are Containers?

Containers are Isolated Environment.

All the required Libraries, Application, Binaries, Dependency and Runtime(OS) are encapsulated inside it.

Containers are like lightweight sandboxes. They don’t require an entire operating system like a virtual machine, but they do have everything you need to run an application.

This means they are fast, portable, and easy to use.

Containers are isolated from each other, which means you can run multiple containers on the same machine without them interfering with each other.

This solves the problem of inconsistent environments because everything the application needs is bundled inside the container itself.

It doesn’t matter where you run it — it will always behave the same way.

What Is Docker?

Now, let’s talk about Docker. Docker is not a container itself — it’s a platform that allows you to build, ship, and run containers.

Think of Docker as the tool that makes it easy for developers to package up their applications into containers. Docker simplifies the process of managing containers, and it helps ensure that everything runs smoothly, whether you’re working locally, testing in a QA environment, or deploying to production.

A serializer acts like a translator between complex data (like database records) and simple formats (like JSON). They help with:

• Data Transformation: Converting data for API responses.
• Input Validation: Ensuring incoming data is correct.
• Code Simplification: Reducing boilerplate code for data handling.

Types of Serializers in Django

1. Serializer

This is the basic serializer where you define fields manually and here the all three types validators also used.

Example:
from rest_framework import serializers

#validators

def alphanumeric(value):

if not str(value).isalnum():

raise serializers.ValidationError("Value must be alphanumeric")

class CarSerializer(serializers.Serializer):

id = serializers.IntegerField(read_only=True)

name = serializers.CharField()

description = serializers.CharField()

active = serializers.BooleanField(read_only=True)

chassisnumber = serializers.CharField(validators= [alphanumeric])

price = serializers.DecimalField(max_digits=9, decimal_places=2)

def create(self, validated_data):

return CarList.objects.create(**validated_data)

def update(self, instance, validated_data):

instance.name = validated_data.get('name', instance.name)

instance.description = validated_data.get('description', instance.description)

instance.active = validated_data.get('active', instance.active)

instance.chassisnumber = validated_data.get('chassisnumber',instance.chassisnumber)

instance.price = validated_data.get('price', instance.price)

instance.save()

return instance

#field level validator

def validate_price(self, value):

if value <= 20000.00:

raise serializers.ValidationError("Price must be greater then 20 k")

return value

#Object level Validation

def validate(self,data):

if data['name'] == data['description']:

raise serializers.ValidationError("Name and description must not be same")

return data

2. ModelSerializer

This serializer automatically generates fields based on a Django model, making it easier to work with.

Example:
class ReviewSerializer(serializers.ModelSerializer):

class Meta:

model=Review

fields = ‘__all__’

3. HyperlinkedModelSerializer

Similar to ModelSerializer , but it uses hyperlinks for relationships instead of primary keys.

Example:
class UserHyperlinkedSerializer(serializers.HyperlinkedModelSerializer):
class Meta:
model = User
fields = ‘__all__’

4. ListSerializer

Used to handle lists of objects, allowing for multiple instances to be serialized at once.

Example:
class UserListSerializer(serializers.ListSerializer):
child = UserSerializer() # Use the basic serializer for each user

5. Nested Serializers

Allows you to include one serializer within another, useful for representing related models.

Example:
class ProfileSerializer(serializers.ModelSerializer):
class Meta:
model = Profile
fields = [‘bio’, ‘location’]

class UserWithProfileSerializer(serializers.ModelSerializer):
profile = ProfileSerializer() # Nested serializer

class Meta:
model = User
fields = [‘username’, ‘email’, ‘profile’]

Custom Serializers

You can also create custom serializers by extending existing ones, adding specific validation or custom logic as needed.

Example:
class CustomUserSerializer(serializers.ModelSerializer):
class Meta:
model = User
fields = [‘username’, ‘email’]

def validate_email(self, value):

if ‘@example.com’ in value:
raise serializers.ValidationError(“Email cannot be from example.com”)
return value

Understanding serializers in Django is crucial for building efficient APIs. They help transform complex data, validate input, and simplify your code.

I hope this overview helps clarify serializers for you! If you have questions or experiences to share, feel free to comment!