DEV Community: Pankaj Batra

Chat With Any YouTube Video — My ₹0 RAG App Is Now Live (Here's How the Frontend Works)

Pankaj Batra — Wed, 19 Aug 2026 08:53:26 +0000

Paste any YouTube link. Chat with the video. Get summaries, study notes, and quizzes — every answer grounded with clickable timestamps that jump the embedded player to the exact moment.

It's live, it's free, and there's no signup: https://youtube-rag-frontend.vercel.app

A week ago I published the backend story — a FastAPI + ChromaDB + Groq RAG pipeline running on ₹0/month, and the three walls I hit shipping it. This post is the second half: the Flutter Web frontend, the interaction pattern that makes the whole thing feel magical, and — because this project apparently refuses to let me ship anything without a fight — three more walls, including my LLM getting shut off two days before launch.

What the finished product does

The flow is deliberately boring: paste a URL, wait a few seconds while the transcript is ingested, and you're in.

From there, four things work end-to-end:

Chat. Ask anything about the video. Answers stream in token-by-token, and every factual claim carries a [ts:MM:SS] citation rendered as a tappable chip. Tap it and the embedded YouTube player seeks to that exact second. The retrieved source chunks appear before the answer even starts generating.

Summaries. One tap generates a short TL;DR plus a detailed point-by-point breakdown. Cached after first generation — instant on revisit.

Notes. Full markdown study notes, rendered in-app and downloadable as a real .md file you can drop into Obsidian or Notion.

Quizzes. Five multiple-choice questions generated from the video, with scoring and explanations — and the explanations carry the same tappable timestamp chips, so a wrong answer links you back to the moment in the video that explains it.

No login. No account. Your library and chat history never leave your browser — more on why in a minute.

The mechanic worth explaining: tappable timestamps

If there's one pattern worth stealing from this project, it's this one. It's what makes people stop and say "wait, that's cool," and it's cheap to build once you see the shape of it.

Step 1 — the LLM emits structured markers in plain text. The chat prompt instructs the model to append [ts:MM:SS] next to any factual claim, using the time ranges of the retrieved chunks. No function calling, no JSON schema for the answer — just an inline convention in the text stream. This matters because the answer is streaming; a structured-output format would force me to wait for the full response before rendering anything.

Step 2 — the frontend parses markers mid-render. In Flutter, the assistant message is built with Text.rich and a list of InlineSpans. A regex scans the accumulated text for [ts:MM:SS] matches; each match becomes a WidgetSpan wrapping a small CitationChip widget, and the surrounding text stays ordinary TextSpans. Because parsing happens on every rebuild, chips materialize live as tokens arrive — you can watch a citation pop into existence mid-sentence.

Step 3 — the chip talks to the player. The YouTube embed runs through youtube_player_iframe, and its controller lives in a Riverpod provider scoped to the current video. A chip tap reads that controller and calls seekTo(seconds) followed by playVideo(). That's the entire integration: a regex, a widget span, and a controller reference.

The same parser is reused inside quiz explanations, which is where the pattern earns its keep twice — getting a question wrong and tapping straight to the moment that explains it is the closest this app gets to a teaching assistant.

The general lesson: when your output is a stream, put structure in the text as lightweight conventions rather than around the text as schemas. Parse leniently on the client. Text and video stop being two panes on a screen and become one linked document.

Why Flutter Web (an honest answer)

The predictable question: why not React?

Because I've written Flutter for four years and I can move fast in it. That's most of the answer, and I think it's a legitimate one — familiarity is a real engineering resource. But there were structural reasons too:

One codebase, more targets later. A mobile app is a build target away, not a rewrite. For a video-study tool, a phone app is an obvious future.
Riverpod's family providers gave me per-video state isolation for free. Every provider — chat history, summary, notes, quiz, player controller — is keyed by video_id. Switching videos in the sidebar swaps the entire state tree with zero manual cleanup.
The architecture transfers. Feature-first clean architecture (data / domain / presentation per feature) is how I structure mobile apps; the six features here (library, chat, summary, notes, quiz, health) follow the same shape.

The honest trade-off: Flutter Web ships a heavier initial bundle than an equivalent React app — several MB — so first load is slower. For a productivity tool people bookmark and return to, I'll take that trade. If this were a landing page or a content site, I wouldn't.

Rest of the frontend stack, briefly: Riverpod with codegen for state, freezed for immutable models, go_router for navigation, dio for HTTP with a hand-rolled SSE parser for the chat stream, sembast_web over IndexedDB for local storage, Vercel free tier for hosting.

The privacy angle: no accounts, by design

Post 1 mentioned the backend is stateless per user. Here's what that actually buys once there's a real product on top:

Your data lives in your browser. The video library and every chat message are stored in IndexedDB (via sembast_web). The backend is a shared cache keyed by YouTube video ID — it knows which videos have been processed, but it has no concept of who you are.

The consequences stack up nicely:

Onboarding is instant. Paste a URL, start chatting. No signup wall in front of a tool whose whole pitch is "faster than scrubbing the video yourself."
No PII on servers. There is nothing to breach, nothing to subpoena, no GDPR data-subject request to handle, because there is no user data server-side.
The shared cache stretches the free tier. When two people study the same video, it's ingested once. Popular videos get cheaper per user, not more expensive.

And the honest trade-off, surfaced right in the app's About dialog: clear your browser data and your library is gone. That's deliberate. Local-first means the user owns the data — including the responsibility for it.

This decision also created the most interesting UX bug of the project, which brings us to the walls.

Wall 4: My LLM was shut off two days before launch

Post 1 readers will remember Wall 2: Google deprecated my embedding model mid-build. I wrote "read release notes, keep model names in env config." I did not expect to be rehearsing that lesson again within weeks.

Mid-frontend-build, every summary, notes, and quiz call started returning LLM_ERROR. Chat broke on new turns. Nothing in my code had changed. The cause: Groq had announced the deprecation of llama-3.3-70b-versatile back in June, and I hit the actual shutoff while testing the integration.

The fix was almost anticlimactic, and that's the point:

Picked Groq's recommended replacement — openai/gpt-oss-120b. Still free tier, same 128K context window, faster inference. Arguably an upgrade.
Updated one environment variable on Render.
Production recovered in about thirty seconds.

The proper cleanup — new defaults in config, updated .env.example, and a RUNBOOK.md so future-me knows the drill — followed as a regular commit, calmly, with production already healthy.

Here's the part worth dwelling on: this is the third provider rug-pull this project has absorbed in a matter of weeks. Gemini killed my embedding model. A hosting option I'd evaluated moved its free tier behind payment. Now Groq retired my LLM. None of these were my bugs; all of them would have been my outages.

In the LLM era, model deprecations arrive with the frequency of OS security patches. The free-tier AI stack is genuinely excellent — this whole product runs on it — but churn is its hidden cost, and the tax you pay is architectural: model names in env vars, provider calls behind your own abstractions, and a runbook for the day the 404 arrives. Not nice-to-haves. Survival gear.

Wall 5: The backend forgot; the browser remembered

This one is a direct consequence of the local-first design, and it's my favorite wall of the six because it's a product problem, not an infrastructure one.

Render's free tier has ephemeral disk: every redeploy wipes ChromaDB and SQLite. The shared cache resets. But the user's library lives in their IndexedDB, which persists just fine. Result: the sidebar cheerfully lists a video the backend has never heard of. Open it, and the summary/notes/quiz tabs spiral into confusing retry loops against a 404.

The state on the client and the state on the server had diverged, and the app had no idea.

The fix is explicit stale-state detection. Opening a video fires a silent existence check (GET /videos/{id}). On a 404, the UI drops a banner:

"This video exists in your local library but is missing from backend cache."

With two actions:

Re-sync — reconstructs the YouTube URL from the stored video ID (https://www.youtube.com/watch?v={video_id} — YouTube IDs are deterministic, so I never needed to store the URL at all) and re-ingests through the normal flow.
Remove local copy — for videos you're done with.

While stale, chat history stays readable but sending is disabled, and the content tabs show guidance instead of raw errors.

Two deliberate choices in that design. First, no silent auto-re-ingest. The app could quietly re-process every stale video in the background — and burn free-tier transcript quota on work the user never asked for. Asking is cheaper and more honest. Second, the banner names the actual situation instead of a generic "something went wrong." Users can handle the truth that a free-tier cache resets; what they can't handle is a retry spinner with no explanation.

The lesson generalizes to any local-first app with a server cache: ephemeral storage is a design constraint, not a footnote. Detect divergence explicitly. Tell the user. Let them decide.

Wall 6: Vercel couldn't build my app

Flutter Web on Vercel is a slightly odd couple — Vercel has no Flutter runtime, so the SDK gets cloned during the build via an install script. That part worked. What didn't: code generation.

This codebase leans on codegen — freezed for models, riverpod_generator for providers. Running build_runner inside Vercel's constrained build container blew the Dart analyzer's stack. The build hung past fourteen minutes and died with a stack trace long enough to need its own pagination. Twice.

The fix is the standard, mildly controversial pattern: commit the generated files. .freezed.dart and .g.dart files go into git; Vercel skips codegen entirely and just compiles. A regenerate.sh script handles local regeneration — run it after any model or provider change, commit the output.

The trade-off is honest: one extra manual step in the dev loop, in exchange for fast, deterministic CI builds. For a solo project on free-tier CI, that trade isn't close. (A smaller quirk from the same session: Vercel caps the buildCommand string at 256 characters, which my build sequence exceeded — so the whole thing moved into vercel-install.sh / vercel-build.sh scripts anyway. Cleaner, and testable locally with a plain bash vercel-build.sh.)

The lesson is the same one Wall 3 taught from a different angle: your CI environment is not your machine. Different resource limits, different failure modes. Deploy early — the first deploy is a test of the pipeline, not the product.

The bill, updated

Post 1 ended with a seven-line infrastructure bill totalling ₹0. The product now has a frontend, a domain, and real users. The updated bill:

Service	Purpose	Monthly cost
Render	Backend hosting	₹0
Vercel	Frontend hosting	₹0
Groq	LLM inference (gpt-oss-120b)	₹0 (free tier)
Google Gemini	Embeddings	₹0 (free tier)
Supadata	YouTube transcripts	₹0 (free tier)
ChromaDB	Vector storage	₹0 (local, open source)
SQLite	Metadata storage	₹0 (local, open source)
UptimeRobot	Keep-alive pings	₹0 (free tier)
Total		₹0

Six walls, two milestones, one full-stack RAG product, zero rupees. The constraint held.

What's next

A few directions I'm weighing, in no particular order: map-reduce summarization for very long videos (the current pipeline favors shorter content), voice input for chat, optional accounts for people who want cross-device sync, and — since the codebase is Flutter — a proper mobile app.

If any of those would be useful to you, say so. That's genuinely how I'll prioritize.

Try it

https://youtube-rag-frontend.vercel.app — paste a video you've been meaning to study, ask it something, tap a timestamp.

It runs on free-tier everything, so be kind: a rare cold start takes a few seconds, and it's a personal project, not a funded product. If it breaks in an interesting way, tell me — interesting breakage is how this entire series got written.

The backend story, including the first three walls, is here: I Deployed a Full RAG Backend for ₹0/Month.

About the Author

I'm Pankaj Batra, a Software Engineer focused on Flutter, automation, and enterprise integrations.

I write about practical engineering: mobile architecture, workflow automation, APIs, event-driven systems, and lessons from production systems.

Connect

Portfolio: https://pankajbatra.vercel.app
LinkedIn: https://linkedin.com/in/pankaj-batra-0a294a205
GitHub: https://github.com/Pankaj0405

If this was useful, follow for more engineering notes.

I Deployed a Full RAG Backend for ₹0/Month — Here Are the 3 Walls I Hit

Pankaj Batra — Sun, 09 Aug 2026 10:09:34 +0000

I just shipped the backend for YouTube RAG Chat: paste a YouTube link, chat with the video, and get AI-generated summaries, study notes, and quizzes — every answer grounded with clickable timestamp citations.

It runs in production. It streams responses token-by-token. It costs me exactly ₹0 per month.

Getting there was not smooth. My container OOMed on every startup, Google deprecated my embedding model mid-build, and YouTube blocked my server's IP the moment I deployed. This article is the story of the system, the three walls I hit, and what each one taught me about building AI backends under real constraints.

The problem: video is unsearchable

We've all done it: scrubbing back and forth through a 40-minute tutorial trying to find the 90 seconds where the presenter actually explains the thing. Video transcripts exist, but reading a raw transcript is worse than watching the video. What you actually want is to ask the video a question and jump straight to the answer.

That's a textbook Retrieval-Augmented Generation problem — and RAG remains the backbone of production AI in 2026, powering the majority of deployed AI applications. So instead of another chatbot-over-PDFs demo, I built RAG over the medium people actually consume: YouTube.

The requirements I set for myself:

Grounded answers. Every claim traceable to a moment in the video, via inline timestamps.
Streaming. First token in 1–2 seconds, not a 15-second spinner.
Cached everything. Same video, second user → sub-second responses.
₹0 infrastructure. Not "cheap." Zero. As a forcing function for good architecture.

That last constraint turned out to be the most educational decision of the project.

The stack

Layer	Choice
Language	Python 3.11
Web framework	FastAPI (async)
ORM + migrations	SQLAlchemy 2 (async) + Alembic
Vector DB	ChromaDB (local, persistent)
Metadata DB	SQLite
LLM	Groq — `llama-3.3-70b-versatile`, streamed via SSE
Embeddings	Google Gemini — `gemini-embedding-001` (768 dims)
Transcripts	Supadata API
Hosting	Render free tier (Docker)
Keep-alive	UptimeRobot, 10-minute pings

Note that half of these choices weren't my first choices. They're what survived contact with production. More on that shortly.

Architecture

Clean architecture, four layers, dependencies pointing strictly inward:

Routers → Services → Repositories → Infrastructure

Diagram description (for Excalidraw): Four horizontal bands stacked top to bottom. Band 1 — Routers: boxes for /videos, /chat, /summary, /notes, /quiz, /health, each receiving arrows from a "Client" box above. Band 2 — Services: boxes for IngestionService, ChatService, ContentService (summary/notes/quiz). Arrows from each router down to its service. Band 3 — Repositories: VideoRepository, ChunkRepository. Band 4 — Infrastructure: boxes for TranscriptFetcher (Supadata), EmbeddingClient (Gemini), LLMClient (Groq), ChromaDB, SQLite. Arrows from repositories/services down into infrastructure. One dashed arrow labeled "SSE stream" going from ChatService back up and out to the Client, annotated with the event sequence sources → tokens → done.

Three design decisions worth calling out:

1. No user identity on the backend

The backend is stateless per user. There are no accounts, no sessions, no per-user tables. Each user's personal video library and chat history will live in their browser's IndexedDB — a frontend concern I'll cover in the next post. The backend only knows about videos, not people.

This sounds like a limitation. It's actually the unlock for decision #2.

2. A shared, deduplicated cache

Videos are keyed by YouTube video ID. If User B ingests a video User A already processed, the backend detects the cache hit and returns metadata in under a second — no transcript fetch, no re-chunking, no re-embedding. One popular video costs the system exactly one ingestion, ever.

Look at the cached: true flag in the ingestion response below — that request returned in well under a second because someone (me, in this case) had already processed the video.

3. Timestamps as first-class citizens

The LLM is prompted to emit [ts:MM:SS] markers inline in its answers, sourced from the retrieved chunks' time ranges. The upcoming frontend will render these as tappable chips that seek the video player. The backend contract is simple: every answer carries its receipts.

The API, live

All examples use {{live}} as a placeholder for the base URL. Response bodies below are real, pasted from production.

Ingest a video

curl -X POST {{live}}/api/v1/videos \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.youtube.com/watch?v=xpDnVSmNFX0"}'

{
    "video_id": "xpDnVSmNFX0",
    "title": "System Design BASICS: Horizontal vs. Vertical Scaling",
    "channel": "Gaurav Sen",
    "thumbnail_url": "https://i.ytimg.com/vi/xpDnVSmNFX0/hqdefault.jpg",
    "duration_seconds": 476,
    "transcript_lang": "en",
    "chunk_count": 18,
    "created_at": "2026-08-09T09:20:07.152949Z",
    "cached": true
}

The pipeline behind this: validate the URL → fetch the transcript → chunk it (this 8-minute video became 18 chunks) → embed each chunk via Gemini → store vectors in ChromaDB and metadata in SQLite. On a cache hit, all of that is skipped.

Chat, streamed over SSE

curl -N -X POST {{live}}/api/v1/chat \
  -H "Content-Type: application/json" \
  -d '{"video_id": "xpDnVSmNFX0", "question": "What is this video about?", "history": []}'

The stream arrives as three event types, in order:

1. sources — the retrieved chunks, sent first so a client can render citations before the answer starts:

{
    "chunks": [
        {
            "start_time": 0.04,
            "end_time": 26.829,
            "preview": "This video is on the basics of system design. If you have never designed a system before, this is probably the place..."
        },
        {
            "start_time": 457.42,
            "end_time": 475.52,
            "preview": "We design a system which is going to meet the requirements, and the requirements are such that it's going to be Compu..."
        }
    ]
}

2. token — the answer, one token at a time:

token → {"content":"This"}
token → {"content":" video"}
token → {"content":" is"}
token → {"content":" about"}
token → {"content":" the"}
...

3. done — stream complete.

Sending sources before tokens is a small ordering decision with a big UX payoff: the user sees where the answer will come from while the answer is still being generated. First-token latency in production is 1–2 seconds, courtesy of Groq's inference speed.

Generated content: summary, notes, quiz

Three more endpoints turn any ingested video into study material, each cached after first generation:

curl -X POST {{live}}/api/v1/videos/xpDnVSmNFX0/summary

{
    "video_id": "xpDnVSmNFX0",
    "short": "This video covers the basics of system design, starting with a simple algorithm running on a computer and exposing it to others through an API...",
    "detailed": [
        "The video starts by introducing the concept of system design and how it begins with a simple algorithm running on a computer.",
        "As the algorithm becomes useful to others, it needs to be exposed through an API, allowing others to send requests and receive responses.",
        "..."
    ],
    "cached": false,
    "generated_at": "2026-08-09T09:45:48.459477Z"
}

The quiz endpoint is the most interesting of the three. The LLM must return strict, structured JSON — question, four options, correct index, explanation with a timestamp — and the backend validates the structure before accepting it (agent-style output validation, retry on malformed responses):

curl -X POST {{live}}/api/v1/videos/xpDnVSmNFX0/quiz

{
    "video_id": "xpDnVSmNFX0",
    "question_count": 5,
    "questions": [
        {
            "question": "What is the purpose of exposing code using an API?",
            "options": [
                "To store output in a file",
                "To connect to a database",
                "To allow others to use the code over the internet",
                "To configure endpoints"
            ],
            "correct_index": 2,
            "explanation": "The purpose of exposing code using an API is to allow others to use the code over the internet, as stated at [ts:02:45]."
        },
        {
            "question": "What is the difference between a desktop and a cloud?",
            "options": [
                "A desktop is a set of computers, while a cloud is a single computer",
                "A desktop is a single computer, while a cloud is a set of computers",
                "A desktop is used for personal use, while a cloud is used for business",
                "A desktop is faster than a cloud"
            ],
            "correct_index": 1,
            "explanation": "A desktop is a single computer, while a cloud is a set of computers that can be used to run a service, as stated at [ts:06:30]."
        }
    ]
}

The full endpoint list: POST /videos, GET /videos/{id}, POST /chat, POST /videos/{id}/summary, POST /videos/{id}/notes, POST /videos/{id}/quiz, GET /health.

Now for the part that actually earned this article: nothing above worked on the first deployment.

Wall 1: The 512 MB ceiling

This is the wall that reshaped the whole architecture, so it gets the deepest treatment.

My original embedding plan was the obvious one: run sentence-transformers locally with all-MiniLM-L6-v2. It's the default in every RAG tutorial, it's free forever, and it works beautifully on a dev machine.

Then I deployed to Render's free tier and the container OOMed on startup. Every time.

The math, once I actually did it, was brutal:

PyTorch runtime: several hundred MB of RAM before doing anything useful
The MiniLM model loaded into memory
ChromaDB's own footprint
FastAPI + the async stack

Total: ~800 MB. Render free tier: 512 MB. The container never even reached the health check. There was no clever flag or lazy-loading trick that closes a 300 MB gap — the architecture itself was wrong for the box.

So I stopped trying to squeeze a local model into 512 MB and asked a better question: why is my 0.1 vCPU web server doing ML inference at all? Embedding is a compute-heavy, stateless operation — exactly the kind of thing to push to a managed API. I migrated embeddings to Google Gemini's embedding API.

The results:

Backend RAM: ~800 MB → ~200 MB. Comfortable headroom on a 512 MB box.
Docker image: shrank by ~500 MB. No PyTorch, no model weights. Final compressed image is under 500 MB — small for an AI backend.
Embedding quality went up. 768 dimensions vs MiniLM's 384, with roughly a 10-point improvement on MTEB benchmarks. The constraint didn't just save the deploy — it produced better retrieval.

Lesson: free-tier constraints are an architecture review you didn't ask for. Local models are lovely on a beefy dev machine and terrible on a 0.1 vCPU box. If a component is stateless and compute-heavy, it probably doesn't belong in your web server's process.

Wall 2: My embedding model no longer existed

Fresh off the Wall 1 fix, I wired up Gemini's text-embedding-004 — the model most Gemini RAG tutorials reference — and the very first call returned a 404.

Not a rate limit. Not an auth error. The model was gone. Google had shut down text-embedding-004 on January 14, 2026, and I'd picked my model from tutorials instead of release notes.

The fix took minutes, which is the actual point of the story:

Switched to gemini-embedding-001 — stable, generally available.
It uses Matryoshka Representation Learning, meaning the model is trained so that truncated prefixes of its embedding vector are themselves valid embeddings. The default output is 3072 dimensions; I explicitly request 768, which is plenty for transcript chunks and keeps ChromaDB's storage and query costs down.
Because the model name lived in an environment variable rather than being hardcoded, the swap was a one-line config change. No code touched, no redeploy logic, no migration script.

Lesson: when you pick an API model, read the release notes and the deprecation timeline, not just the tutorial. And treat model names as configuration, not code — the day your provider kills a model (and that day will come), you'll fix it in one line instead of one afternoon.

Wall 3: "Works on my machine" — literally

With memory fixed and embeddings live, ingestion worked flawlessly on my laptop. I deployed. Transcript fetching failed instantly.

The culprit: YouTube blocks datacenter IPs. My laptop's residential IP fetched transcripts happily via youtube-transcript-api; Render's cloud IP got stonewalled. This isn't a Render problem — AWS, GCP, Azure all hit the same wall, because YouTube treats datacenter IP ranges as scraper traffic.

The realistic options were: run my own residential proxy layer (cost, complexity, ToS gray zones), or use a managed transcript API that handles that layer for me. I swapped to Supadata's API, which does exactly that, transparently, with a free tier generous enough for an MVP.

Two design decisions made this migration painless:

The abstraction held. All transcript fetching went through a single TranscriptFetcher class. Swapping youtube-transcript-api for Supadata was a single-file change — routers, services, and the chunking pipeline never knew anything happened.
Deduplication multiplies the free tier. Because videos are cached by ID, one popular video costs one transcript fetch total — not one per user. The cache isn't just a latency feature; it's what makes the ₹0 economics hold as usage grows.

Lesson: "it works on my machine" is a real infrastructure signal, not just a meme. Your laptop and your server can live in genuinely different networks with different rules. And the boring advice about wrapping external dependencies in your own abstraction pays for itself the first time an external dependency betrays you — which, per Walls 2 and 3, was twice in one project.

The ₹0 bill

Service	Purpose	Monthly cost
Render	Backend hosting	₹0
Groq	LLM inference	₹0 (free tier)
Google Gemini	Embeddings	₹0 (free tier)
Supadata	YouTube transcripts	₹0 (free tier)
ChromaDB	Vector storage	₹0 (local, open source)
SQLite	Metadata storage	₹0 (local, open source)
UptimeRobot	Keep-alive pings	₹0 (free tier)
Total		₹0

The UptimeRobot row deserves a sentence: Render's free tier spins containers down when idle, which means multi-second cold starts for the first unlucky user. A ping every 10 minutes keeps the container warm. Cold starts still exist in theory but are rare in practice (~10 seconds when they happen).

Where it landed

The numbers, in production:

Backend RAM: ~200 MB (down from ~800 MB in the original design)
Docker image: under 500 MB compressed
First-token latency (chat): ~1–2 seconds
Cache-hit responses: under 1 second
Cold starts: ~10 seconds, rare thanks to keep-alive pings

Not bad for a stack whose total infrastructure line item is a hard zero.

What's next

The backend streams grounded, timestamped answers — but right now the only client is cURL. Next milestone: a Flutter Web app that turns those [ts:MM:SS] markers into tappable chips that seek the actual video player, with each user's library and chat history living entirely in their browser. That gets its own post.

If there's one thing to take from this build: constraints are a feature. The 512 MB ceiling forced a cleaner architecture. The deprecated model enforced config discipline. The IP blocking validated the abstraction layer. A bigger budget would have let me ship all three mistakes to production and never learn from them.

About the Author

Connect

Portfolio: https://pankajbatra.vercel.app
LinkedIn: https://linkedin.com/in/pankaj-batra-0a294a205
GitHub: https://github.com/Pankaj0405

If this was useful, follow for more engineering notes.

Kafka for Engineers Who've Only Used REST: What Actually Changes

Pankaj Batra — Sat, 01 Aug 2026 13:04:53 +0000

When I first read that Kafka was a "distributed event streaming platform," I nodded, closed the tab, and went back to writing REST endpoints.

It took me a while to realize the problem wasn't Kafka. It was that every explanation started with what Kafka is and none of them started with why it exists. If you already think about systems the way REST teaches you to, most Kafka tutorials feel like they're answering a question you didn't ask.

This post is for engineers who've built REST APIs for years and want to understand Kafka the way it actually clicks — not the API, not the config, but the shift in what a system is supposed to be.

The short version:

REST is about asking. Kafka is about telling.

Once that lands, everything else about Kafka stops feeling arbitrary.

The REST mental model has a hidden assumption

Every REST system assumes one thing that's so obvious it's almost invisible: the caller knows who to ask.

Your mobile app knows to call the orders API. The orders API knows to call the payments API. The payments API knows to call the fraud service. Someone, somewhere, decided who talks to whom, and that decision is baked into the code.

Consider an order being placed. In a typical REST setup:

The order service saves the order
Then it calls the inventory service to decrement stock
Then it calls the email service to send a confirmation
Then it calls the analytics service to log the event

Four services. Three couplings the order service has to know about. And when the business decides to add loyalty points on every order, you go back and edit the order service — again.

You didn't do anything wrong. This is what REST tells you to do. But look at what's really happening: the order service is responsible for knowing every other service that cares about orders. That responsibility grows every time the business grows.

That's the hidden assumption. In REST, the sender is responsible for knowing all the receivers.

What Kafka actually changes

Kafka flips the direction.

The order service no longer calls anyone. It writes a single fact to a log:

"order 1234 was placed."

And then it's done.

Inventory, email, analytics, loyalty — none of them are called. They read the log on their own schedule, notice a new order, and each one does whatever it does. The order service doesn't know they exist. It doesn't care.

That's the whole idea.

Everything else you'll ever read about Kafka — partitions, offsets, consumer groups, brokers, retention — exists to make that one shift work at scale.

If you take nothing else from this post, take this:

In REST, services call each other. In Kafka, services publish facts and read facts, and no one is called by name.

Five things that stop feeling weird once the shift lands

Once you accept the model, a bunch of things that look strange in Kafka tutorials suddenly make sense. Here are the five that tripped me up longest.

1. Kafka doesn't delete messages after they're read

In a REST world, a response is consumed. Once your client got the JSON back, the server moves on. Message queues work similarly — pop a message off, process it, gone.

Kafka doesn't do that. Messages sit in the log for as long as you tell it to keep them — days, weeks, forever if you want. The reason is baked into the model: a fact doesn't stop being true just because one service noticed it.

If analytics needs to reprocess the last week of orders, the events are still there. If you spin up a new service tomorrow that also cares about orders, it can read every order that ever happened.

The log isn't a queue. It's a record of everything that occurred, and consumers get to decide when and how often they read from it.

2. Consumers track their own position

In REST, the server knows who called it. Requests are tracked, sessions exist, the server is the coordinator.

In Kafka, the log has no idea who's reading. Each consumer is responsible for remembering where it is in the log — its offset. If a consumer crashes and restarts, it reads its last saved offset and picks up from there. If you want a second copy of a service to also process every event, it just starts from offset zero and reads independently.

This is why replay is trivial in Kafka and impossible in REST. Rewinding a REST call doesn't mean anything. Rewinding a Kafka offset means "read those events again."

3. You scale by adding partitions, not by adding servers per endpoint

REST scales by putting a load balancer in front of your service and adding more instances behind it. Each request goes to whichever instance is free.

Kafka scales by splitting the log itself. A topic isn't a single log — it's split into partitions, and consumers coordinate to divide those partitions among themselves. If you have four partitions and four consumers in a group, each consumer handles one partition. Add a fifth consumer and one of them will sit idle, because a partition is only ever read by one consumer in a group at a time.

This is a completely different scaling model, and it means the number of partitions you choose is a design decision that affects throughput for the life of the topic. It's not something you tune later without pain.

4. Order is only guaranteed within a partition

REST doesn't really care about order. Each request is independent, and if you need ordering, you build it in the application layer.

Kafka guarantees order — but only within a single partition. Across partitions, all bets are off. This means partitioning is a design choice you make based on what needs to stay ordered.

If you partition orders by customer ID, all events for one customer stay in order. If you partition by timestamp or randomly, you'll see events for the same customer arrive out of sequence. The moment you choose a partition key, you've decided what "in order" means for that topic.

Get this wrong and you'll ship a system where events arrive in an order that makes no sense to a human, and debugging it will feel like a nightmare until you notice what's happening.

5. There's no "the server returned an error"

In REST, errors have a shape. The server returns a 500, the client sees it, retries or gives up. Error handling lives in the request path.

In Kafka, there's no server responding to your call. There's a log. If a consumer fails to process a message, the failure happens on the consumer side, and the consumer has to decide what to do about it: retry, skip, log, or move the message to a dead-letter topic for someone to look at later.

This moves error handling out of the request path entirely. You stop asking "what should I return when this fails?" and start asking "what should this consumer do when it can't process what it just read?" That's a different question, and it takes a while to get comfortable with.

When REST is still the right answer

None of this makes REST obsolete. It's not supposed to.

REST is still the right choice when:

The caller needs an answer now — an authorization check, a price lookup, a validation
You're doing CRUD on a single resource
The integration is between two systems, not many
The caller genuinely does know who to ask, and that's not going to change

Kafka is the right choice when:

Multiple systems care about the same event
You want to be able to add new consumers later without touching the producer
Events have value beyond the moment they happen — audit, replay, analytics, machine learning
The coupling between services is starting to feel like the thing you spend most of your time maintaining

The most honest tell is this: if every new feature means adding another HTTP call from an existing service, you're probably ready for events. That pattern doesn't scale — not technically, but organizationally. Every new integration means editing an old service, which means testing it, which means owning it.

Events break that cycle. New consumer, no producer changes.

The shift, restated

Kafka doesn't replace REST. What it replaces is a specific habit — the habit of every service being responsible for knowing who to notify when something happens.

Once producers only publish facts, and consumers only read what they care about, systems get easier to change. Not easier to build the first time — Kafka has real operational cost, and the mental model takes effort. But easier to change, which is what actually matters after month three of any real system.

The hardest part of learning Kafka isn't the API. It's letting go of the assumption that someone always has to be waiting for the answer.

Once you accept that services can just publish facts into the world and stop caring who reads them, the rest of Kafka is just plumbing.

About the Author

I'm Pankaj Batra, a Software Engineer focused on Flutter, automation, and enterprise integrations.

I write about practical engineering: mobile architecture, workflow automation, APIs, event-driven systems, and lessons from production systems.

Connect

Portfolio: https://pankajbatra.vercel.app
LinkedIn: https://linkedin.com/in/pankaj-batra-0a294a205
GitHub: https://github.com/Pankaj0405

If this was useful, follow for more engineering notes.

Building a Server-Driven Survey Engine in Flutter Without a WebView

Pankaj Batra — Tue, 21 Jul 2026 12:29:44 +0000

This article was originally published on my Hashnode blog and is shared here for the Dev.to community.
Enterprise apps often need forms that change without an app-store release.

New questions appear. Visibility rules change. Validation logic evolves. Dropdown options come from remote services. Nested sections grow and shrink.

If every one of those rules lives only in Flutter code, the mobile app becomes a second form engine — expensive to build and easy to drift from the web.

This post is about a different approach: server-driven surveys rendered with native Flutter widgets, while the form logic stays outside the UI layer — and without wrapping everything in a WebView.

I won’t walk through proprietary implementation details. I’ll share the design thinking, the trade-offs, and the lessons that mattered most.

The Real Challenge Isn’t UI

Drawing text fields and dropdowns is the easy part.

The hard part is keeping behavior consistent:

Conditional visibility and enablement
Validation and error messaging
Calculated values and expressions
Multi-step navigation
Nested / repeating sections
Remote option lists

On the web, mature form libraries already solve much of this.

On mobile, teams often choose one of three paths:

Rebuild the logic in Dart
Embed a WebView and reuse the web form
Hybrid model — native UI, shared logic engine

We chose the third.

Why Avoid a WebView?

WebViews are fast to ship, but they come with costs:

Heavier memory and less “native” feel
Awkward integration with camera, files, signatures, and platform UX
Harder theming consistency with the rest of the app
Debugging that feels like maintaining two apps

For production mobile UX, native widgets are usually worth the extra design work.

The constraint we accepted:

The UI can be Flutter-native.

The meaning of the form (rules, state, validity) should not be reinvented in Flutter.

The Design Principle That Unlocked Everything

The most important decision was ownership:

One layer owns form logic. Flutter owns presentation and device I/O.

That means Flutter should:

Render what the logic layer says is currently visible
Capture user input
Handle device features (files, camera, signature, etc.)
Apply theming and accessibility

Flutter should not become the place where business rules are reimplemented “just for mobile.”

This single rule prevents a class of bugs where mobile and web disagree about whether a field should appear, whether a value is valid, or what an expression means.

Server-Driven UI, Practically

In this model, the app receives a form definition (JSON) from the backend.

That definition describes:

Structure (pages, panels, questions)
Behavior (conditions, validators, expressions)
Presentation hints (titles, layout flags, locales)

The mobile client’s job is to interpret and render, not to hardcode each form.

That’s what “server-driven” means here:

Product can iterate forms without waiting for a Flutter release for every schema change
Mobile stays aligned with the same logic model used elsewhere
Engineering effort shifts from “build every form” to “build a reliable renderer”

What Made This Hard (Without the Internals)

Hybrid systems fail in the seams — the places where two runtimes meet.

A few categories of problems showed up repeatedly:

1) Nested structures break naive assumptions

Top-level questions behave differently from questions nested inside repeating or dynamic containers.

If your mental model is “look up a field by name and update it,” nested forms will eventually surprise you.

Lesson: design for ownership and context early, not after the first nested bug.

2) Presentation flags are easy to misread

A flag that hides a panel title is not the same as hiding every child title.

Some question types also have different title semantics than ordinary inputs.

Lesson: match the upstream form engine’s meaning before inventing mobile-only rules.

3) Expression language has a strict shape

Operators and functions are not interchangeable.

A valid expression can look “almost right” and still fail because the syntax is interpreted differently than expected.

Lesson: when logic “doesn’t work,” verify expression form before assuming the mobile layer is broken.

4) Performance is a product of strategy, not just widgets

Large forms stress:

startup cost
communication between UI and logic layers
remote option loading on mobile networks

Fetching everything up front can feel simple and then become slow.

Lesson: measure separately — init cost, interaction cost, and network cost are different problems.

Trade-offs We Accepted

What you gain

Native Flutter UX
Stronger parity with an existing form logic ecosystem
Faster iteration on form content from the server
Cleaner separation between UI and rules

What you pay

Bridge complexity between runtimes
More careful debugging across layers
Constraints around what the logic runtime can do directly (especially without browser APIs)
Ongoing discipline so Flutter doesn’t quietly reabsorb business logic

This architecture is not “simpler.”

It is clearer — if the ownership boundaries stay honest.

Principles I’d Reuse on the Next Project

Choose a source of truth for form logic and protect it.
Prefer native rendering when UX quality matters.
Treat nested forms as a first-class design problem.
Don’t optimize everything on day one — instrument first.
Reproduce edge cases in demos (nested sections, remote options, expression rules).
Document decisions, not just features — future you will need the “why.”

Final Thoughts

Building a server-driven survey experience in Flutter is less about clever widgets and more about boundary design.

If Flutter owns too much logic, you rebuild a form engine.

If you lean only on WebView, you sacrifice native quality.

If you split responsibilities cleanly, you get something harder to build — and much easier to evolve.

The goal isn’t to expose every internal mechanism publicly.

The goal is to ship forms that stay correct as the business changes — without turning every schema update into a mobile release.

About the Author

I'm Pankaj Batra, a Software Engineer focused on Flutter, automation, and enterprise integrations.

I write about practical engineering: mobile architecture, workflow automation, APIs, and lessons from production systems.

Connect

Portfolio: https://pankajbatra.vercel.app
LinkedIn: https://linkedin.com/in/pankaj-batra-0a294a205
GitHub: https://github.com/Pankaj0405

If this was useful, follow for more engineering notes.

5 Power Automate Design Mistakes That Slow Down Your Flows (And How to Fix Them)

Pankaj Batra — Mon, 13 Jul 2026 08:53:27 +0000

This article was originally published on my Hashnode blog and is shared here for the Dev.to community.

Power Automate makes it incredibly easy to automate business processes.

With just a few actions, you can connect Microsoft Forms, SharePoint, Outlook, Teams, SQL Server, and hundreds of other services—often without writing a single line of code.

But as workflows grow, something interesting happens.

The automation still works...

...yet it becomes slower, harder to debug, and increasingly difficult to maintain.

In many cases, the issue isn't Power Automate itself.

It's the workflow design.

Over the past few months, while working on enterprise automation solutions, I've noticed the same design patterns appearing repeatedly. Individually they may seem harmless, but together they can significantly impact performance, readability, and long-term maintainability.

In this article, I'll share five common Power Automate design mistakes and practical ways to avoid them.

Why Flow Design Matters

Unlike traditional code, Power Automate workflows are visual.

That makes them incredibly easy to build.

Unfortunately, it also makes it easy to introduce unnecessary actions, nested loops, duplicated logic, and expensive operations without realizing their long-term impact.

As workflows become more complex, these small design decisions compound.

A well-designed workflow provides:

🚀 Faster execution
🐞 Easier debugging
📈 Better scalability
🧹 Simpler maintenance
👥 Easier collaboration with other developers

Let's look at five common mistakes.

1. Using "Apply to each" When You Don't Need It

One of the most common performance issues is unnecessary Apply to each loops.

Power Automate automatically creates these loops whenever an action returns an array, even when you're expecting only a single item.

Many developers simply leave the loop in place.

Example:

Get Items

↓

Apply to each

↓

Condition

↓

Update Item

While this works, every additional loop adds unnecessary processing and makes the flow harder to understand.

Better Approach

If your logic expects a single record, retrieve the first result instead of iterating through the collection.

Get Items

↓

First()

↓

Condition

↓

Update Item

Benefits

Less processing
Cleaner workflows
Faster execution
Easier debugging

2. Retrieving More Data Than Necessary

Another common mistake is retrieving an entire SharePoint list and filtering the results afterward.

Example:

Get Items

↓

5000 Records

↓

Filter Array

↓

Find One Record

Although functional, this forces Power Automate to process far more data than necessary.

Instead, use OData Filter Queries whenever possible.

Example:

Status eq 'Pending'

Title eq 'Vendor A'

This allows SharePoint to perform the filtering before returning the data.

Benefits

Less data transferred
Faster execution
Better scalability

3. Performing Duplicate Checks After Creating Records

Another design pattern I occasionally see looks like this:

Create Item

↓

Search for Duplicate

↓

Delete Duplicate

Although functional, it performs unnecessary work.

A cleaner approach is:

Search Existing Record

↓

Exists?

↓

Yes → Skip

↓

No → Create Item

Benefits

Prevents duplicate records
Reduces unnecessary writes
Improves performance
Keeps data clean

4. Writing Extremely Complex Expressions

Power Automate expressions are incredibly powerful.

Functions such as:

split()
concat()
if()
length()
coalesce()

allow sophisticated transformations.

The mistake is combining everything into one huge expression.

Instead of writing something like:

concat(
 split(...),
 if(...),
 body(...)
)

Break the logic into multiple Compose actions.

Compose – Format Date

↓

Compose – Customer Name

↓

Compose – Final Output

This approach makes workflows significantly easier to understand, debug, and maintain.

5. Never Looking at Flow History

Many developers only check whether the flow succeeded.

Flow History provides much more valuable information.

It can help identify:

Slow-running actions
Retry attempts
Connector latency
Failed expressions
Workflow bottlenecks

Reviewing Flow History regularly often reveals optimization opportunities that aren't obvious while building the workflow.

Best Practices I Follow

Whenever I build a Power Automate workflow, I try to follow a few simple principles.

✅ Keep workflows as linear as possible.

✅ Filter data before retrieving it.

✅ Avoid unnecessary loops.

✅ Break complex logic into smaller Compose actions.

✅ Prevent duplicate records before writing data.

✅ Review Flow History regularly.

Small improvements made early can dramatically improve maintainability as workflows evolve.

Final Thoughts

Power Automate makes automation accessible to everyone.

Designing workflows that remain clean, scalable, and performant as they grow is a different skill.

Most performance improvements don't come from changing connectors.

They come from making better design decisions.

A well-structured workflow is easier to understand, easier to debug, and much more reliable as business requirements evolve.

About the Author

Hi, I'm Pankaj Batra, a Software Engineer focused on building scalable software, automation solutions, and enterprise integrations.

I regularly write about:

⚡ Power Automate & Workflow Automation
📱 Flutter & Mobile Development
🐍 Python & Backend Development
🔗 REST APIs & System Integrations
🏗️ Software Architecture

Connect with me

🌐 Portfolio: https://pankajbatra.vercel.app
💼 LinkedIn: https://linkedin.com/in/pankaj-batra-0a294a205
💻 GitHub: https://github.com/Pankaj0405

If you found this article helpful, consider following me for more practical software engineering content.