🔥 The Problem

When building a real-time chat system, push notifications are crucial. Initially, it’s common to send messages to multiple device tokens using Firebase’s legacy API.

However, Firebase has deprecated this functionality — it no longer allows sending messages to multiple device tokens in a single API call.

This introduces a problem:
What if your system has thousands of users? Looping through tokens to send messages one by one isn’t efficient — it consumes memory and slows down delivery.

💡 The Solution: Firebase Topic Messaging

A great alternative is to use Firebase Topic Messaging.

In many chat systems, users participate in channels or rooms. These channels map perfectly to topics in Firebase.

• You subscribe a device to a topic (channel).

• When a message is sent to that topic, all subscribed devices receive it.

• No need to manually manage and loop over tokens.

It's scalable and aligns with how group chat features work.

✅ Requirements

Here’s what you need:

• A Firebase project

• A service account JSON file

• Node.js and the firebase-admin package

• A socket-based system (like Socket.IO) to track user activity

🔧 Step-by-Step Setup

1. 🔐 Get Firebase Service Account

• Go to Firebase Console

• Project settings > Service accounts

• Click “Generate new private key”

• Save the file in a local .firebase/ folder

2. 🛡️ Keep Credentials Secure

Add the folder to your .gitignore:

# .gitignore
.firebase/

3. 📦 Initialize Firebase Admin SDK

Install the package:

npm install firebase-admin

Use environment variables and initialize Firebase:

# .env
FIREBASE_CREDENTIAL_PATH=.firebase/firebase-adminsdk.json

// firebase.js
const admin = require("firebase-admin");
const path = require("path");

const serviceAccount = require(path.resolve(process.env.FIREBASE_CREDENTIAL_PATH));

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount)
});

module.exports = admin;

🔄 Topic Subscription Logic

When a user connects via socket and joins channels, subscribe their device token to the corresponding topics:

const subscribeToChannels = async (deviceToken, channelIds) => {
  for (const channelId of channelIds) {
    await admin.messaging().subscribeToTopic(deviceToken, channelId);
  }
};

When the user logs out or disconnects:

const unsubscribeFromChannels = async (deviceToken, channelIds) => {
  for (const channelId of channelIds) {
    await admin.messaging().unsubscribeFromTopic(deviceToken, channelId);
  }
};

📩 Sending a Message to a Topic

Here’s how to broadcast a message to all users in a channel:

const sendToTopic = async (channelId, messageText) => {
  const message = {
    notification: {
      title: "New Message",
      body: messageText,
    },
    topic: channelId,
  };

  await admin.messaging().send(message);
};

This sends the message to all devices subscribed to the topic.

🧠 Why This Works

• It’s scalable: One message to many users.

• It’s clean: No need to track tokens manually.

• It’s flexible: You can dynamically subscribe/unsubscribe users as they join or leave channels.

📌 Final Thoughts

Using Firebase Topic Messaging helped us scale and simplify notification delivery in a chat system architecture. If you're still using the old token-based multi-send method, now’s a good time to switch.

This approach works especially well if:

• You have group-based features (like chat rooms, teams, or event channels)

• You want to reduce memory usage and API calls

🗨️ Want to Try It Yourself?

Give it a shot! If you're working on a chat app or anything with groups or channels, topic messaging is worth exploring.

The N+1 Query Problem: A Performance Killer

Imagine you have a Book model and an Author model, where each book has one author. When you try to list all books and display each book's author information, a naive approach might look something like this:

1. Query for all Book objects (1 query).

2. For each Book object, query for its related Author (N queries, where N is the number of books).

This quickly adds up, leading to N+1 queries for a seemingly simple operation. The problem becomes even more pronounced when you have nested serializers in Django Rest Framework (DRF), where a serializer might be calling other serializers, which in turn fetch more related data, creating a cascading N+1 nightmare.

How we spotted it: We personally experienced this performance hit. Our API endpoints, particularly those involving deeply nested data structures returned by DRF serializers, were making an excessive number of database calls. Tools like the Django Debug Toolbar were invaluable in visualizing these redundant queries and pinpointing the exact areas causing the slowdown.

The Solution: select_related and prefetch_related to the Rescue!

Django provides two incredibly powerful tools to combat the N+1 problem:

1. select_related(): For One-to-One and Many-to-One Relationships

select_related performs an SQL JOIN and includes the fields of the related object in the initial query. This means that when you access the related object later, it's already available without needing an extra database hit. It's ideal for "forward" relationships (like Book to Author).

Before (N+1 query):

# views.py
from rest_framework import generics
from .models import Book
from .serializers import BookSerializer

class BookListView(generics.ListAPIView):
    queryset = Book.objects.all()
    serializer_class = BookSerializer

# serializers.py
from rest_framework import serializers
from .models import Book, Author

class AuthorSerializer(serializers.ModelSerializer):
    class Meta:
        model = Author
        fields = ['name', 'email']

class BookSerializer(serializers.ModelSerializer):
    author = AuthorSerializer() # This is where the N+1 typically happens

    class Meta:
        model = Book
        fields = ['title', 'publication_date', 'author']

After (Optimized with select_related):

# views.py
from rest_framework import generics
from .models import Book
from .serializers import BookSerializer

class BookListView(generics.ListAPIView):
    # Eagerly load the 'author' related object
    queryset = Book.objects.select_related('author').all()
    serializer_class = BookSerializer

# serializers.py (no change needed here, as the problem was in the query)
# ... same as above ...

By adding select_related('author'), Django fetches the author data in the same query as the book data, drastically reducing the number of database calls.

2. prefetch_related(): For Many-to-Many and Reverse One-to-Many Relationships

prefetch_related works differently. It performs a separate lookup for each relationship, and then performs a Python join to link them up. This is useful for "reverse" relationships (e.g., getting all Book objects for a given Author) or Many-to-Many relationships.

Let's say a Book can have multiple Genres (Many-to-Many relationship).

Before (N+1 query):

# views.py
from rest_framework import generics
from .models import Book
from .serializers import BookSerializer

class BookListView(generics.ListAPIView):
    queryset = Book.objects.all()
    serializer_class = BookSerializer

# serializers.py
from rest_framework import serializers
from .models import Book, Author, Genre

class GenreSerializer(serializers.ModelSerializer):
    class Meta:
        model = Genre
        fields = ['name']

class BookSerializer(serializers.ModelSerializer):
    author = AuthorSerializer()
    genres = GenreSerializer(many=True) # Another N+1 potential

    class Meta:
        model = Book
        fields = ['title', 'publication_date', 'author', 'genres']

After (Optimized with prefetch_related):

# views.py
from rest_framework import generics
from .models import Book
from .serializers import BookSerializer

class BookListView(generics.ListAPIView):
    # Eagerly load 'author' and 'genres'
    queryset = Book.objects.select_related('author').prefetch_related('genres').all()
    serializer_class = BookSerializer

# serializers.py (no change needed here)
# ... same as above ...

Here, prefetch_related('genres') fetches all associated genres in a separate, efficient query and then attaches them to the correct books in Python, avoiding N individual queries for each book's genres.

Seeing the Difference with Django Debug Toolbar

To truly appreciate the impact of these optimizations, tools like the Django Debug Toolbar are indispensable. Before applying select_related and prefetch_related, you'll likely see a large number of database queries for a single API call. After implementing these changes, you'll observe a dramatic reduction in the query count, leading to faster response times and a happier database.

Key Takeaways for Optimizing Your DRF APIs:

• Be aware of nested serializers: They are a common culprit for N+1 issues.

• Use select_related for One-to-One and Many-to-One relationships. It performs a SQL JOIN.

• Use prefetch_related for Many-to-Many and reverse One-to-Many relationships. It performs separate queries and a Python join.

• Always debug and profile: Tools like Django Debug Toolbar are your best friends for identifying and confirming performance bottlenecks.

• Start simple: Don't over-optimize prematurely. Address N+1 issues when you actually observe performance problems.

By strategically applying select_related and prefetch_related, you can significantly boost the performance of your Django Rest Framework APIs, providing a smoother experience for your users and a lighter load on your database. Happy optimizing!