Choosing between GraphQL and REST isn't about which one is "better." It's about understanding where each architecture starts to break down as your product, engineering team, and traffic grow.

If you've spent enough time building APIs, you've probably seen the debate.

"GraphQL is the future."

"REST is simple and battle-tested."

Both statements are true.

And both are misleading.

After working on backend services that exposed GraphQL APIs while integrating with existing REST-based systems, I realized that the discussion isn't really about APIs.

It's about scale.

As your application grows, the challenges change—from returning JSON to managing hundreds of clients, thousands of requests, and multiple engineering teams.

Let's look at where each approach shines—and where it doesn't.

The Problem REST Was Designed to Solve

REST models your API around resources.

GET /users/42
GET /users/42/orders
GET /products/15

Each endpoint represents a piece of your system.

It's simple.

Predictable.

Easy to cache.

And because every endpoint has a well-defined responsibility, debugging is usually straightforward.

For many applications...

REST is all you'll ever need.

Then the Frontend Gets More Complex

Imagine building a dashboard.

It needs:

• User profile

• Recent orders

• Notifications

• Saved addresses

• Recommended products

With REST, the frontend might call five different endpoints.

GET /user

GET /orders

GET /notifications

GET /addresses

GET /recommendations

Five requests.

Five database queries.

Five network round trips.

Nothing is technically wrong.

But mobile users on slower networks begin to notice.

Enter GraphQL

GraphQL flips the relationship.

Instead of the server deciding what each endpoint returns...

The client asks for exactly what it needs.

query {
  user(id: 42) {
    name
    email
    orders {
      total
      status
    }
    notifications {
      title
    }
  }
}

One request.

One response.

No unnecessary data.

No missing fields.

This is why GraphQL became popular for applications with rich user interfaces.

The Hidden Cost of Flexibility

GraphQL feels magical.

Until your API reaches production.

Because clients can request almost anything...

The server has to support almost everything.

Consider this query:

user {
  posts {
    comments {
      author {
        posts {
          comments {
            ...
          }
        }
      }
    }
  }
}

Looks harmless.

It isn't.

Without safeguards, one request can generate hundreds—or even thousands—of database queries.

This is known as the N+1 Query Problem.

It's one of the biggest performance pitfalls in GraphQL.

REST Has a Different Problem

REST rarely suffers from deeply nested queries.

Instead...

It suffers from over-fetching and under-fetching.

Imagine requesting a user profile.

GET /users/42

The server returns:

{
  "id": 42,
  "name": "...",
  "email": "...",
  "createdAt": "...",
  "preferences": "...",
  "address": "...",
  "avatar": "...",
  "..."
}

The frontend only needed:

{
  "name": "...",
  "avatar": "..."
}

The extra data wastes bandwidth.

Now imagine the opposite.

The frontend also needs the user's recent orders.

Another request.

And another.

The application becomes chatty.

Caching Changes Everything

One area where REST still dominates is caching.

Endpoints naturally map to URLs.

GET /products/123

CDNs and browsers understand this automatically.

GraphQL is different.

Most requests hit the same endpoint.

POST /graphql

Every query is unique.

Traditional HTTP caching becomes much harder.

Instead, GraphQL often relies on client-side caching libraries like Apollo or Relay.

Powerful?

Absolutely.

Simple?

Not quite.

What Happened During My Internship

One of the projects I worked on involved building a GraphQL microservice using Django, Graphene, and PostgreSQL.

The goal wasn't to replace REST entirely.

It was to simplify how frontend applications accessed data.

Previously, different screens made multiple API calls to collect related information.

By exposing a GraphQL layer, the frontend could retrieve exactly the fields it needed in a single request, reducing unnecessary network traffic and simplifying client logic.

At the same time, our existing REST services continued to handle authentication, internal integrations, and other stable resource-oriented operations.

That experience reinforced an important lesson:

GraphQL and REST aren't competitors—they're tools that often work best together.

So... Which One Scales Better?

It depends on what you're scaling.

Neither architecture wins every category.

Each optimizes for different tradeoffs.

My Rule of Thumb

After building and working with both styles, this is the heuristic I follow.

Use REST when:

• Resources are well-defined.

• HTTP caching matters.

• The API is relatively stable.

• Simplicity is a priority.

Use GraphQL when:

• Multiple clients consume the same backend.

• Frontends need different views of the same data.

• Over-fetching becomes a bottleneck.

• Developer productivity outweighs operational complexity.

And don't be afraid to combine them.

Many production systems expose REST APIs internally while providing a GraphQL gateway for frontend applications.

Final Thoughts

The GraphQL vs REST debate often treats the two as opposing philosophies.

In reality, they're solving different problems.

REST optimizes for simplicity, predictability, and scalability at the infrastructure level.

GraphQL optimizes for developer experience, flexibility, and efficient data fetching.

As systems grow, neither architecture remains perfect.

The real engineering challenge isn't choosing one over the other.

It's understanding the tradeoffs—and knowing when each tool is the right one for the job.

Deepfakes have become increasingly convincing, making it harder to distinguish manipulated videos from authentic ones. We wanted to understand whether modern computer vision techniques could reliably detect these forgeries, so we built our own end-to-end deepfake detection system—from training the model to deploying it as a web application.

Why Deepfake Detection?

With the rise of generative AI, creating realistic fake videos has become easier than ever. While the technology has exciting creative applications, it also introduces serious risks, including misinformation, identity theft, and financial fraud.

Rather than relying on existing APIs, we wanted to understand the problem from first principles. Our goal was to build a complete system capable of taking a video as input, detecting manipulated facial features, and presenting the results through an intuitive web interface.

Defining the Pipeline

Before writing any code, we broke the problem into smaller components.

Video Upload
      │
      ▼
Frame Extraction
      │
      ▼
Face Detection (MTCNN)
      │
      ▼
Image Preprocessing
      │
      ▼
CNN + Vision Transformer
      │
      ▼
Frame Predictions
      │
      ▼
Final Video Classification

Each stage solved one specific problem, making the overall system easier to develop and debug.

Choosing the Right Dataset

A model is only as good as the data it learns from.

We trained our detector using the FaceForensics++ dataset, one of the most widely used benchmarks for deepfake research. It contains thousands of real and manipulated videos generated using multiple face manipulation techniques, allowing the model to learn a wide variety of visual artifacts instead of overfitting to a single editing method.

Why We Didn't Feed Entire Videos into the Model

Processing an entire video would have required significantly more memory and computation.

Instead, we sampled a fixed number of representative frames from each video and extracted only the faces. Since facial regions contain the majority of deepfake artifacts, this approach dramatically reduced computation while preserving the most relevant information.

For face detection, we used MTCNN, which provided robust face localization even under varying lighting conditions and camera angles.

Each detected face was resized to 224×224 pixels before being passed to the classifier.

Building a Hybrid Model

Instead of relying on a single architecture, we combined the strengths of Convolutional Neural Networks and Vision Transformers.

The CNN layers acted as local feature extractors, capturing subtle artifacts such as unnatural textures, blending inconsistencies, and compression noise.

These refined features were then passed into a Vision Transformer, which analyzed relationships across the entire face to identify inconsistencies that traditional CNNs might overlook.

This hybrid architecture allowed the model to learn both local and global visual patterns.

Face Image
      │
      ▼
CNN Feature Extraction
      │
      ▼
Vision Transformer
      │
      ▼
Real / Fake Prediction

Training the Model

Training involved much more than simply calling model.fit().

We used:

• Adam optimizer with a learning rate of 5 × 10⁻⁵

• Weighted Cross Entropy Loss to address class imbalance

• Batch size of 8

• 80/20 train-test split

• PyTorch as the deep learning framework

The model was trained for multiple epochs while tracking both training and validation accuracy to ensure it generalized well instead of memorizing the dataset.

After training, the model achieved approximately 92% accuracy on the test set.

While accuracy is important, we also evaluated confidence scores and frame-level predictions to better understand how the model behaved across different videos.

Turning the Model into a Web Application

A trained model isn't useful if people can't interact with it.

We built a lightweight web application using Flask that allowed users to upload videos directly from their browser.

Once a video was uploaded, the backend performed the following steps:

1. Extract video frames.

2. Detect faces using MTCNN.

3. Preprocess each face.

4. Run inference using the trained model.

5. Aggregate predictions across all processed frames.

6. Display the final prediction along with confidence scores.

The frontend was intentionally simple, allowing users to drag and drop videos without requiring any technical knowledge.

Looking Beyond a Single Prediction

Instead of classifying a video using just one frame, our system analyzed multiple frames and combined their predictions.

This made the detector significantly more robust.

For every uploaded video, the application displayed:

• Overall prediction (Real or Fake)

• Confidence score

• Number of analyzed frames

• Frame-by-frame predictions

• Detection history through an analytics dashboard

This additional transparency helped users understand why a video received a particular classification instead of treating the model as a black box.

Challenges We Faced

Building the system presented several practical challenges.

Selecting Representative Frames

Analyzing every frame was computationally expensive, while analyzing too few risked missing manipulated regions.

We settled on sampling a limited number of frames that provided a good balance between speed and accuracy.

Face Detection Failures

Videos with poor lighting, side profiles, or motion blur occasionally caused MTCNN to miss faces.

Handling these edge cases required additional validation and graceful error handling.

Class Imbalance

Real and fake samples were not perfectly balanced.

Using a weighted loss function prevented the model from becoming biased toward the majority class.

Deployment Constraints

Deep learning models can consume significant memory during inference.

To keep the application responsive, we limited the number of processed frames and optimized preprocessing wherever possible.

What We Learned

This project taught us that building an AI application involves much more than training a neural network.

Data preparation, preprocessing, deployment, and user experience all have a direct impact on the quality of the final system.

Perhaps the biggest takeaway was that no single architecture is sufficient for every problem. Combining CNNs for local feature extraction with Vision Transformers for global context produced a stronger detector than relying on either approach alone.

More importantly, deploying the model as a complete web application transformed it from a research experiment into something users could actually interact with.

What's Next?

Although the system performed well on FaceForensics++, there is still plenty of room for improvement.

Future iterations could include:

• Temporal modeling using video transformers instead of independent frame analysis.

• Multi-modal detection by combining visual and audio signals.

• Support for newer generative models and diffusion-based deepfakes.

• GPU-accelerated inference for real-time processing.

• Explainable AI techniques such as Grad-CAM to highlight manipulated facial regions.

Deepfake generation techniques continue to evolve rapidly, and detectors must evolve alongside them. Building this project gave us a deeper appreciation for the challenges involved—not just in training accurate models, but in creating practical AI systems that people can use.

Kafka is one of those technologies everyone uses but very few truly understand. I wanted to change that—not by reading another whitepaper, but by building a simplified version from scratch.

Most tutorials teach Kafka from the outside.

You create a producer.

You create a consumer.

You publish a message.

Everything magically works.

But...

• Where does the message actually go?

• How does the consumer know what to read?

• Why doesn't Kafka delete messages after they're consumed?

• How can multiple consumers read the same data independently?

Those questions led me to build my own miniature event streaming platform inspired by Kafka.

The goal wasn't to compete with Apache Kafka. It was to understand why Kafka is designed the way it is.

The First Attempt: Just Send Messages

Every messaging system begins with one idea:

A producer sends data.

A consumer receives data.

Producer
    │
    ▼
 Queue
    │
    ▼
Consumer

A simple queue works surprisingly well.

Until you ask two questions.

What happens if the consumer crashes?

The message disappears.

What if another consumer wants to read the same message?

Too late. It has already been removed.

Queues are great for task distribution.

Kafka solves a different problem.

Instead of a Queue, Think Like a Journal

Rather than deleting messages, Kafka keeps appending them to a log.

Imagine writing in a notebook.

0  User Registered
1  Payment Successful
2  Email Sent
3  Order Delivered

Nothing gets erased.

New events are simply written at the end.

This tiny design decision changes everything.

Appending is incredibly fast because disks are optimized for sequential writes.

More importantly, history is preserved.

That became the foundation of my implementation.

Instead of removing messages after consumption, I stored every event in append-only log files.

Reading Without Deleting

Now another question appears.

If messages aren't deleted...

How does a consumer know what it has already processed?

The answer is surprisingly elegant.

Every message gets an offset.

Offset    Event

0         Login
1         Upload
2         Payment
3         Logout

The consumer simply remembers the last offset it processed.

Consumer A

Current Offset = 2

The next read starts from offset 3.

Nothing is deleted.

Nothing is copied.

Just a number.

Implementing offset tracking was one of my favorite parts of the project because it immediately enabled message replay and recovery after failures.

One Log Isn't Enough

A single log works...

...until thousands of producers start writing simultaneously.

Now everyone is waiting for the same file.

The obvious solution?

Split the log.

Orders

├── Partition 0
├── Partition 1
└── Partition 2

Messages are distributed across partitions using a hashing strategy.

partition = hash(key) % number_of_partitions

Suddenly, multiple producers can write in parallel.

This dramatically improves throughput while keeping ordering guarantees inside each partition.

I implemented topic partitioning using this exact idea.

Building the Broker

Once producers and consumers existed, I needed something in the middle.

The broker became the brain of the system.

Its responsibilities were simple:

• Accept incoming messages

• Choose the correct partition

• Persist data to disk

• Serve consumer requests

• Track offsets

Instead of producers writing directly to files, everything flowed through the broker.

Producer

      │

      ▼

   Broker

 ┌──────────┐
 │ Partition│
 │ Selection│
 └──────────┘

      │

      ▼

 Append Log

This separation made the architecture much cleaner and much closer to how real event streaming systems operate.

Consumers Needed Memory Too

At first, consumers simply kept asking:

"Do you have anything new?"

The broker responded with every message after the consumer's last offset.

This worked.

But what if several consumers belonged to the same application?

If everyone read every partition...

...work would be duplicated.

So I added consumer groups.

Each consumer receives ownership of specific partitions.

Consumer Group

Consumer A  → Partition 0

Consumer B  → Partition 1

Consumer C  → Partition 2

Now processing scales horizontally without duplicate work.

Keeping Consumers Alive

A new challenge appeared.

How does the broker know whether a consumer is still alive?

I solved this with heartbeats.

Each consumer periodically sends a small heartbeat message.

If the broker stops receiving heartbeats, it assumes the consumer has failed.

The abandoned partitions are automatically reassigned to another consumer in the same group.

This was one of the most interesting parts of the project because it introduced fault tolerance without making the system overly complex.

Persistence Changed Everything

Keeping everything in memory makes development easy.

It also means losing everything after a restart.

To avoid that, every message was written to disk using append-only logs.

When the broker restarted, it simply rebuilt its state from the stored log files.

No database.

No recovery scripts.

Just replaying the history.

This reinforced one of Kafka's most elegant ideas:

The log is the source of truth.

Measuring Performance

Once the system worked, I wanted to understand how it behaved under load.

I benchmarked the broker using different partition counts.

• 4 partitions

• 8 partitions

• 16 partitions

The throughput remained fairly consistent at around 330–338 messages per second.

The biggest bottlenecks weren't the algorithms themselves.

They were:

• Synchronous disk writes

• JSON serialization overhead

• Python thread scheduling

• Network I/O between clients and the broker

Even though the implementation was intentionally simple, the benchmarks showed how partitioning improves concurrency while other parts of the system become the limiting factors.

What I Didn't Build

Apache Kafka is the result of years of engineering.

My implementation intentionally focused on understanding the core concepts rather than reproducing every production feature.

It doesn't include:

• Multi-broker replication

• Leader election

• Log compaction

• Zero-copy networking

• Compression

• Distributed consensus

And that's okay.

The objective wasn't feature parity.

It was understanding the architecture.

Final Thoughts

Building a Kafka-inspired system completely changed the way I think about event streaming.

The biggest lesson wasn't about producers or consumers.

It was about logs.

Once you realize that Kafka is fundamentally a distributed, append-only log with smart indexing and offset management, many of its design decisions suddenly make perfect sense.

Sometimes the best way to understand a complex system isn't to read another tutorial.

It's to build one yourself.