Forem: Prateek Mangalgi

I Built a Real-Time Video Calling App Using WebRTC in React Native, And It Was Harder Than I Expected

Prateek Mangalgi — Sat, 21 Feb 2026 17:01:56 +0000

Most developers have used apps like Zoom, Google Meet, or WhatsApp calls.

But building one?

That’s a completely different story.

When I started working on my React Native WebRTC app, I thought:

“It’s just video streaming, right?”

I was wrong.

Very wrong.

The Moment I Realized This Isn’t Just Another App

In a normal app:

You send a request → server responds

In WebRTC:

Two devices talk directly

No middleman.
No API response cycle.
No “simple backend”.

Just two peers trying to:

Discover each other

Negotiate connection

Exchange network details

Stream audio/video in real-time

That’s when it hit me:

This isn’t frontend or backend.
This is network-level engineering.

What WebRTC Actually Does

WebRTC (Web Real-Time Communication) allows devices to communicate peer-to-peer with ultra-low latency.

Which means:

Your phone can directly stream video to another device

Without routing media through a server

With built-in encryption

And that’s powerful.

But also complex.

The Architecture Behind My WebRTC App

My app follows a classic but important structure:

1. Client Layer (React Native)

This is where everything starts.

The app:

Captures camera & microphone
Displays local & remote video
Handles UI for calling

React Native made it easier to build cross-platform apps for iOS and Android while still using native WebRTC performance.

But UI was the easy part.

2. Signaling Server (The Unsung Hero)

Here’s the biggest misconception:

“WebRTC is peer-to-peer, so no server needed.”

Wrong.

You do need a signaling server.

Its job:

Help users find each other
Exchange connection data (SDP)
Share ICE candidates

Without signaling, peers can’t even start talking.

WebRTC does NOT define how signaling works, you have to build it yourself.

In my project, this became the coordination layer.

3. Peer Connection (The Core Engine)

Once signaling is done:

A peer connection is created

Devices exchange:

Offer
Answer
ICE candidates

This is where the magic happens.

The connection shifts from:

Server-mediated to Direct device-to-device communication

4. NAT Traversal (The Hidden Complexity)

Real-world networks are messy.

Devices sit behind:

Routers
Firewalls
NATs

So WebRTC uses:

STUN servers → Find your public IP
TURN servers → Relay data if direct connection fails

Without these, many connections simply wouldn’t work.

5. Real-Time Media Flow

Once connected:

Audio & video streams flow directly between peers

No backend involved in media transfer

Latency stays extremely low

This is why WebRTC is used in:

Video calls
Live collaboration
Telemedicine apps

The Full Flow:

Here’s how a call actually happens:

User A starts a call
Signaling server sends “offer” to User B
User B responds with “answer”
Both exchange ICE candidates
Peer connection is established
Media streams directly between devices

Not simple.

But beautiful.

What Made This Project Challenging

This wasn’t just coding.

It was understanding systems.

1. Debugging is painful

You’re not debugging functions.

You’re debugging:

Network states
ICE failures
Connection negotiation

2. It’s asynchronous chaos

Everything happens in events:

Offers
Answers
Candidates
Streams

Miss one step → connection fails silently.

3. Documentation is scattered

WebRTC isn’t beginner-friendly.

You don’t “learn it once”.

You experience it over time.

What This Project Taught Me

Before this project, I thought:

“Apps are about APIs and UI.”

Now I know:

Some systems live below that layer.

WebRTC taught me:

Real-time systems are fundamentally different
Architecture matters more than code
Networking knowledge is underrated
Peer-to-peer is powerful but complex

From App Developer to System Thinker

This project changed how I think.

I stopped asking:

“How do I build this feature?”

And started asking:

“How does communication actually happen?”

That shift is what separates:

Developers from Engineers

Final Thought

Building a WebRTC app isn’t about video calling.

It’s about understanding:

Communication protocols
Network behavior
Real-time systems

And once you understand that…

You stop seeing apps as screens.

You start seeing them as systems.

GitHub Link: https://github.com/prateek-mangalgi-dev18/WebRTC-react-native-app

Portfolio Link: https://prateek-mangalgi.vercel.app/

From Chatbot to Medical AI: How I Used RAG, FAISS & Mistral to Ground AI in Reality

Prateek Mangalgi — Mon, 16 Feb 2026 17:17:39 +0000

Most AI demos look impressive.

They answer anything.
They speak confidently.
They sound intelligent.

But confidence is not accuracy.

And when you’re dealing with medical reports, accuracy isn’t optional, it’s responsibility.

When I built Medibotix, I didn’t want another chatbot that guesses.

I wanted an AI that reads your medical report first, and only then speaks.

That decision led me deep into Retrieval-Augmented Generation (RAG), vector search with FAISS, and the power of the Mistral AI API.

And it completely changed how I think about building AI systems.

The Problem With Vanilla AI Chat

Large language models are powerful.

But they have a fundamental limitation:

They generate answers based on training data, not your uploaded document.

Which means:

They might hallucinate.

They might generalize.

They might sound right but be wrong.

They don’t truly see your specific report unless designed to.

In healthcare, that’s dangerous.

So I asked myself:

How do I make an AI answer strictly from the patient’s medical report, and nothing else?

The answer wasn’t prompt engineering.

It was architecture.

The Architecture Behind Medibotix

Medibotix is built around a simple but powerful principle:

The AI must retrieve relevant context before generating an answer.

Here’s the system design.

Document Upload (FastAPI Layer)

A user uploads a medical report (PDF or text).

The backend (built with FastAPI) does not immediately send it to the language model.

Instead, it:

1. Extracts text from the file

Cleans and prepares it

Breaks it into overlapping chunks

Why chunking?

Because medical reports are long.
And language models work best with structured context, not raw documents.

2. Intelligent Chunking

The document is split into overlapping segments.

Overlap matters because medical explanations often span multiple lines.
Without overlap, meaning breaks.

Each chunk becomes a knowledge unit.

Think of it as turning a document into searchable memory fragments.

3. Embeddings via Mistral API

This is where Mistral AI enters the architecture.

Each chunk is converted into a vector embedding using the Mistral embedding model.

Embeddings don’t store words.

They store meaning.

Now every chunk of the medical report becomes a coordinate in semantic space.

Not keyword searchable.

Meaning searchable.

That distinction is everything

4. FAISS - The Memory Engine

Those embeddings are stored inside FAISS.

FAISS is optimized for ultra-fast similarity search.

When a user asks:

“Is my hemoglobin level low?”

The system:

Converts the question into an embedding (via Mistral API)

Compares it against stored document embeddings

Retrieves the top semantically similar chunks

Not based on keyword matching.

Based on contextual similarity.

That’s the heart of RAG.

5. Retrieval-Augmented Generation (RAG)

Now comes the critical orchestration.

Instead of asking the language model to answer blindly, we:

Inject only the retrieved chunks

Provide strict system instructions

Ask it to answer using that context alone

The final answer is generated using a Mistral chat model, but grounded in retrieved evidence.

That’s Retrieval-Augmented Generation.

The model doesn’t guess.

It reasons from evidence.

Guardrails: Designing Responsible Medical AI

In healthcare, hallucination isn’t funny.

It’s harmful.

So Medibotix enforces strict constraints:

Only health-related questions

No political or unrelated topics

No billing or administrative details

Simple language explanations

No unnecessary medical jargon

Clear refusal for off-topic queries

The AI doesn’t replace doctors.

It translates reports into human language.

That difference matters.

The Complete Flow (End-to-End Architecture)

Here’s how everything connects:

User uploads medical report
FastAPI extracts and chunks text
Mistral API generates embeddings
Embeddings stored in FAISS index
User asks a question
Question embedded via Mistral
FAISS retrieves top relevant chunks
Retrieved context passed to Mistral chat model
AI responds strictly from document evidence

It’s not just AI.

It’s a controlled intelligence pipeline.

What This Project Changed for Me

Before Medibotix, I thought AI products were about models.

Now I know they’re about orchestration.

A powerful model without retrieval is like:

A brilliant doctor who hasn’t read your test results.

RAG ensures the AI reads first.

Then answers.

And that small architectural shift makes the difference between:

Impressive.

And dependable.

From Chatbot to Cognitive System

Medibotix isn’t just a chat interface.

It’s a layered system:

Embeddings for understanding

FAISS for memory

Retrieval for grounding

Mistral for reasoning

Guardrails for safety

That’s modern AI engineering.

And that’s where real differentiation lies.

Not in making models talk louder.

But in making them accountable to context.

Final Thought

I didn’t want to build a chatbot that sounds intelligent.

I wanted to build an AI that reads before it speaks.

RAG gave it structure.
FAISS gave it speed.
Mistral API gave it reasoning power.

And architecture gave it discipline.

That’s how Medibotix went from a simple AI idea…

To a document-grounded medical assistant built for responsibility.

Demo link: https://medibotix.vercel.app/
GitHub link: https://github.com/prateek-mangalgi-dev18/Medibotix
Portfolio link: https://prateek-mangalgi.vercel.app/

Most MERN Tutorials Ignore This, Until Production Breaks

Prateek Mangalgi — Fri, 13 Feb 2026 07:38:42 +0000

Media storage isn’t a feature, it’s infrastructure.
Here’s how one decision transformed my MERN music app from fragile to scalable.
When you build your first full-stack product, you think the hard part is logic.

Authentication.
Playlists.
Search algorithms.
UI polish.

But no one tells you about the invisible monster waiting in production:

Media storage.

When I built my MERN music streaming platform, MusicHub, I was proud. It had an admin panel to upload songs, a clean UI, playlist creation, search by artist and movie, everything felt solid.

Until I deployed it.

And the illusion cracked.

The Day It Slowed Down

I uploaded a handful of songs.

Just ten.

That’s all it took.

The server felt heavier.
Streaming wasn’t as smooth.
Deployment limits started whispering warnings.
Storage felt fragile.

That’s when I realized something most beginner tutorials never mention:

Building features makes you feel like a developer.
Handling infrastructure makes you become one.

The Moment I Stopped Thinking Like a Student

Up until that point, I was storing audio files the “easy way.”
Local storage. File paths in the database. Simple.

But production is not impressed by simplicity.

Production asks:

What happens when 1,000 users stream simultaneously?

What happens after 10 redeploys?

What happens when storage resets?

What happens when your backend becomes a file delivery service?

And suddenly, I saw the flaw.

My backend wasn’t meant to carry audio weight.
It was meant to carry logic.

That’s when I discovered Cloudinary, and more importantly, I understood why media delivery is its own engineering discipline.

The Architectural Awakening

Most people think Cloudinary is just for images.

But it’s much more than that.

It’s infrastructure for creators.

When I integrated Cloudinary into MusicHub, something subtle but powerful changed:

My server stopped being responsible for heavy media.

It started focusing on what it should do:

Authentication

Business logic

Database coordination

User experience

And audio?
It traveled through a global CDN, optimized, distributed, resilient.

Streaming became smoother.

Deployment became peaceful.

And the anxiety around “what if this breaks in production?” started fading.

The Psychological Shift

There’s something no one talks about in software engineering:

Confidence.

When your architecture is fragile, you feel it.
When your infrastructure is messy, you know it.

After moving my media handling to Cloudinary, MusicHub stopped feeling like:

“A project I built.”

It started feeling like:

“A product I could ship.”

That’s a powerful shift.

Because good architecture doesn’t just improve performance,
it improves how you think about yourself as a builder.

Final Thought

Every developer reaches a moment where they must choose:

Keep building features…

Or start building systems.

For me, that moment came when storage nearly broke my music app.

And choosing the right media infrastructure turned out to be the difference between a demo project and a scalable product.

Sometimes growth as a developer doesn’t come from writing more code.

It comes from understanding what not to handle yourself.

And that realization changed how I build, permanently.

GitHub link: https://github.com/prateek-mangalgi-dev18/MusicHub
Portfolio link: https://prateek-mangalgi.vercel.app/