DEV Community: Ankita Budhia

How I Built a Netflix-Inspired Movie Explorer with TanStack Query and Framer Motion

Ankita Budhia — Thu, 25 Jun 2026 11:31:43 +0000

After spending a lot of time building full-stack and backend-heavy projects, I wanted to work on something that was unapologetically frontend-focused, something that pushed me to think more about user experience, loading states, performance, and how to make an application feel polished rather than just functional.

That’s how Movix came about.

Movix is a Netflix-inspired movie discovery app built with React, TypeScript, React Query, Tailwind CSS, and Framer Motion. The goal wasn’t just to fetch movie data from the TMDB API and render cards. I wanted to build an experience that felt smooth to use, with fast search, responsive interactions, useful details, and small touches like prefetching and animated hover states that make the app feel more intentional.

Live Demo: https://movix-tmdb.netlify.app
GitHub: https://github.com/ankita007-coder/TMDB-Movie-Explorer

What Movix does

Movix lets users:

browse trending, popular, and top-rated movies
search for movies and actors
open detailed movie pages with cast information
view actor details in a modal
save movies to a personal watchlist
navigate a UI inspired by modern streaming platforms

Under the hood, it also became a good playground for exploring React Query caching, prefetching strategies, Context-based state management, and performance-focused frontend architecture.

The idea behind the project

A lot of movie apps are basically the same pattern:

fetch a list
render some cards
show a details page

There’s nothing wrong with that, but I wanted this project to focus on how the app feels as much as what it does.

That meant thinking about questions like:

How do I reduce loading friction when a user clicks into a movie?
How should search behave so it doesn’t feel clunky?
What’s the best way to handle watchlist state without overengineering it?
How can animations add polish without becoming distracting?

So instead of treating Movix like “just another React project,” I used it to explore the frontend decisions that make an application feel more complete.

Tech stack

Frontend

React
TypeScript
Vite

Styling and UI

Tailwind CSS
Framer Motion

Data fetching and server state

TanStack Query

State management

React Context API

Authentication

Auth0

API

TMDB (The Movie Database)

Building the home page around discovery

The home page is designed around movie discovery rather than just raw data display.

It includes:

a hero carousel featuring trending movies
multiple horizontal sections for:
- Trending
- Popular
- Top Rated

This structure let me build a reusable section-based layout, where each category uses the same UI pattern but fetches different data.

That might sound small, but I wanted the project structure to feel scalable from the start. Instead of writing one-off code for every section, I built reusable pieces like:

HorizontalMovieSection
MovieCard
shared loading skeletons
reusable API hooks for different categories

That kept the UI layer much cleaner as the project grew.

Designing movie cards that reveal more context

A movie card usually starts as “poster + title,” but that felt too static.

So I added hover interactions where cards reveal additional information like:

runtime
genres
movie title overlay

These interactions were built using Framer Motion, which made it easy to add animations without turning the code into a mess of CSS transitions and state toggles.

The goal here wasn’t to make the UI flashy for the sake of it, it was to make browsing feel more interactive and less like scanning a spreadsheet of posters.

Using React Query to make navigation feel faster

One of the parts I enjoyed most in this project was using React Query prefetching to improve perceived performance.

When a user hovers over a movie card, the app prefetches the movie details query in the background. So if they click into that movie a second later, there’s a good chance the details are already cached and ready.

That small decision makes the app feel much faster than if every detail page waited for a fresh fetch after navigation.

Why React Query worked well here

Movix has a lot of server-driven data:

trending movies
popular movies
top-rated movies
search results
movie details
cast information
actor details
known-for credits

Managing all of that with manual loading flags and useEffect chains would get messy pretty quickly.

React Query gave me a much cleaner model:

built-in caching
stale time control
query deduplication
background refetching
easier loading/error handling

For this project, I configured queries with a 5-minute stale time and disabled unnecessary refetches on window focus to keep the UX smoother.

Search: simple feature, lots of UX details

Search ended up being one of those features that seems straightforward until you start thinking about edge cases.

Movix supports searching for both:

movies
actors

To make it feel usable, I added:

debounced input
loading skeletons
empty states
error handling

Without debouncing, every keystroke would trigger a new request and the whole experience would feel noisy. Debouncing gave the search a much calmer, more deliberate feel while also reducing unnecessary API calls.

Building the movie details page

The movie details page pulls together a lot of information in one place:

backdrop and poster
title and tagline
runtime
genres
release date
overview
rating
cast details
streaming providers (India)

This page became a good exercise in component composition because there’s a lot of data, but I still wanted the UI to feel structured rather than overwhelming.

So instead of building one huge component, I split the page into smaller pieces like:

movie hero/details section
cast section
reusable person cards
modal-based actor details

That made the page much easier to reason about and update.

The cast modal and “Known For” section

One of my favorite features in Movix is the actor modal.

Clicking on a cast member opens a modal that shows:

actor photo
name
department
short biography
movies they’re known for

The “Known For” section is built using TMDB’s combined credits endpoint and then filtered/sorted to show the most relevant movie work.

I liked this feature because it made the movie details page feel less static. Instead of cast members being dead-end data, they became entry points into another layer of discovery.

Watchlist without overengineering state

For the watchlist, I deliberately kept the state management lightweight.

I used:

React Context for shared watchlist state
localStorage for persistence

Each authenticated user gets a unique storage key, which means their watchlist remains separate.

This was one of those places where I didn’t want to overcomplicate the solution. A global state library would have been unnecessary here. Context + localStorage was enough, and it kept the feature simple.

Performance optimizations I cared about

Movix wasn’t just about UI, I also wanted it to be reasonably efficient.

A few things I focused on:

1. Prefetching movie details

Hovering over a movie card triggers a prefetch, which reduces perceived load time on the details page.

2. Query caching

React Query handles caching and deduplication, which avoids unnecessary repeated requests.

3. Lazy loading images

Movie posters and other media are loaded lazily where appropriate.

4. Route-based code splitting

Pages are lazy-loaded using React.lazy() to reduce the initial bundle size.

None of these optimizations are groundbreaking individually, but together they make the app feel noticeably smoother.

Project structure

As the project grew, I wanted to avoid dumping everything into a flat components folder.

So I split the code into a more structured layout:

src
├── api/
│   └── movieService.ts
├── components/
│   ├── movie/
│   │   ├── MovieCard
│   │   ├── HorizontalMovieSection
│   │   ├── CastSection
│   │   └── PersonCard
│   └── reusable/
│       ├── Container
│       ├── Skeleton
│       └── Modal
├── context/
│   └── WatchlistContext
├── hooks/
│   ├── useTrending
│   ├── useTopRated
│   ├── usePopular
│   ├── useMovieDetails
│   ├── usePersonCredits
│   └── usePersonDetails
├── pages/
│   ├── Home
│   ├── MovieDetailsPage
│   ├── SearchPage
│   └── WatchlistPage
├── routes/
│   └── AppRoutes
├── types/
│   └── movie.ts
└── utils/

This separation helped keep concerns clearer:

API logic stays in one place
data-fetching hooks stay reusable
components stay focused on UI
pages assemble the bigger experience

What this project taught me

Movix taught me a lot about the difference between building a feature and building an experience.

Technically, the project helped me get more comfortable with:

React Query for server-state management
prefetching strategies
organizing frontend code for scale
balancing animation with usability
choosing simpler state management when it’s enough

But more importantly, it reminded me that frontend work isn’t just about rendering data. It’s about making the product feel intuitive, responsive, and enjoyable to use.

A movie app is a pretty familiar project idea, so the interesting part wasn’t the domain itself, it was the opportunity to think carefully about performance, interaction design, and how small decisions add up to a better experience.

What I’d improve next

If I continue working on Movix, I’d like to add:

infinite scrolling for search results
more advanced filters by genre/year/language
a dark/light theme toggle
better recommendations based on watchlist history
stronger accessibility improvements across interactive components

Final thoughts

Movix started as a movie discovery app, but it turned into a really useful frontend playground for experimenting with React Query, performance optimization, reusable architecture, and UI polish.

It was also a good reminder that “frontend project” doesn’t have to mean “just styling things.” There’s a lot of engineering depth in figuring out how to fetch, cache, structure, and present data in a way that feels seamless to the user.

If you’ve built something similar, or if you’d approach React Query caching/prefetching differently, I’d love to hear how you think about it.

Live Demo: https://movix-tmdb.netlify.app
GitHub: https://github.com/ankita007-coder/TMDB-Movie-Explorer

How I Built a Distributed Rate Limiter with Redis, Lua, and Docker

Ankita Budhia — Mon, 22 Jun 2026 19:14:35 +0000

Rate limiting sounds simple at first, until you try to make it work across multiple server instances without breaking consistency.

I wanted to build something beyond the usual “store a counter in memory and block after 5 requests” demo. So I built APIShield, a distributed rate limiting system that works across multiple backend instances while enforcing limits consistently using Redis, Lua scripting, and MongoDB-backed dynamic rules.

This project ended up being a lot more interesting than I expected. It pushed me into questions around atomic operations, shared state, rule prioritization, and how to make a system feel closer to a production service than a middleware experiment.

In this post, I’ll walk through the architecture, the rate limiting strategies I implemented, and why I ended up moving the sliding window logic into Redis using Lua.

GitHub Repository: APIShield

What is APIShield?

APIShield is a distributed rate limiting system that supports:

Fixed Window
Sliding Window
Token Bucket
Dynamic rule management
Violation tracking
Admin dashboard for rule configuration

The main goal was to build a rate limiter that could run across multiple backend instances while still applying limits consistently, even when requests hit different servers.

Architecture

The system looks like this:

Client
   │
   ▼
Backend Instance 1  ─┐
Backend Instance 2  ─┼──> Redis (Centralized Enforcement)
                     │
                     └──> MongoDB (Rule Storage)

Why this setup?

If each backend instance keeps its own counters in memory, the rate limit breaks the moment traffic is distributed across servers.

For example:

Backend 1 sees 3 requests
Backend 2 sees 3 requests
Limit is 5 requests

If both servers count independently, the client effectively gets 6 requests instead of 5.

That’s why Redis acts as the centralized enforcement layer. Every backend instance checks and updates the same counters, so the limit stays consistent regardless of which instance receives the request.

MongoDB stores dynamic rate limit rules, which means limits can be configured without redeploying the backend.

The algorithms I implemented

1. Fixed Window

This is the simplest strategy.

A counter is maintained for a fixed time window, such as:

100 requests per minute
1000 requests per hour

Once the window resets, the counter resets too.

Pros

Easy to implement
Low memory overhead
Fast

Cons

It has the classic boundary burst problem.

A client could send:

100 requests at 12:00:59
another 100 at 12:01:01

and effectively bypass the intended smoothness of the limit.

2. Sliding Window

To make enforcement more accurate, I implemented Sliding Window using Redis Sorted Sets.

Instead of counting requests in fixed buckets, the system stores request timestamps and continuously checks how many requests happened within the last N seconds.

At a high level, the logic is:

Remove timestamps older than the active window
Add the current request timestamp
Count the remaining timestamps
Block the request if the count exceeds the limit

This gives much more accurate rate limiting than fixed windows.

The problem with a naive implementation

My first approach was the straightforward one: perform the sliding window logic using multiple Redis commands from Node.js.

That meant every request required a sequence like:

remove expired entries
add current request
count requests
set expiry

It works, but it also means multiple Redis round trips per request. At small scale that’s acceptable. At higher traffic volumes, it starts to feel wasteful — especially because the whole operation really needs to be treated as one unit.

That’s what led me to Lua.

Why I used Lua for Sliding Window

To reduce latency and make the sliding window logic atomic, I moved it into a Lua script executed directly inside Redis.

Instead of making multiple Redis calls from Node.js, the backend sends a single script to Redis, and Redis performs the entire rate-limiting workflow in one go.

That solved three problems at once:

1. Atomicity

There’s no gap between removing old requests, inserting the new one, and checking the count. That avoids race conditions when multiple requests arrive close together.

2. Fewer network round trips

The logic runs directly inside Redis, so the backend doesn’t need to orchestrate multiple calls for every request.

3. A more production-friendly implementation

It made the sliding window approach feel much less like a demo and much more like something I’d be comfortable using in a real distributed service.

This was probably my favorite part of the project because it changed the sliding window implementation from “technically correct” to “something that actually scales more gracefully.”

3. Token Bucket

I also implemented Token Bucket to support smoother rate limiting behavior.

In this model:

a bucket has a maximum token capacity
tokens refill over time
every request consumes one token
if no tokens remain, the request is blocked

This is useful when you want to allow short bursts of traffic without removing limits entirely.

Compared to fixed windows, it feels much more natural for APIs where occasional bursts are acceptable but sustained abuse is not.

Dynamic Rule Engine

One of the things I didn’t want was a hardcoded rate limiter with a single global limit.

So I built a dynamic rule engine where rules are stored in MongoDB and managed through an admin dashboard.

Each rule can define things like:

target → ip or user
scope → global or endpoint
algorithm → fixed window / sliding window / token bucket
limit and window configuration
active / inactive state

That makes the system much more flexible because different limits can be applied to different scenarios instead of forcing one blanket rule across everything.

Rule Resolution Priority

When multiple rules could match the same request, I added a priority order:

Endpoint + User
Endpoint + IP
Global + User
Global + IP
Fallback Rule

This allows the system to support more realistic cases.

For example:

a premium user can have a higher limit on a specific endpoint
anonymous traffic can be limited by IP
everything else can still fall back to a global default rule

Fallback Protection

I also didn’t want a missing rule to mean unlimited access.

So if no specific rule matches a request, APIShield applies a safe fallback limit. That acts as a default protection layer and prevents accidental gaps in enforcement.

Violation Tracking

Blocking requests is useful, but I also wanted visibility into who was repeatedly crossing limits.

So I added violation tracking in Redis for:

per-user violations
per-IP violations

This made it possible to surface analytics in the dashboard and inspect how the system was actually being used.

Admin Dashboard

The project also includes an admin dashboard where rules can be:

created
updated
deleted
toggled on/off

and where rate limit violations can be monitored.

I liked this part because it turned the project from “a rate limiting middleware” into something that felt more like an internal platform.

Dockerized setup

The whole system runs with Docker Compose using separate services for:

redis
mongo
backend1
backend2
dashboard

This made it much easier to validate distributed behavior locally.

One of the most satisfying tests was applying a global limit, sending alternating requests to both backend instances, and watching the 6th request get blocked even though the requests were split across servers.

That was the point where the system actually felt distributed instead of just pretending to be.

What this project taught me

APIShield taught me a lot more than just how to implement rate limiting.

It forced me to think about:

how state should be shared across multiple backend instances
when in-memory logic stops being enough
how to reduce race conditions in distributed systems
when to move logic closer to the data store
how to design backend systems that are configurable instead of hardcoded

It also reminded me that some of the most interesting engineering problems aren’t always flashy user-facing features. Sometimes they’re the quiet infrastructure pieces that keep everything else stable.

Final thoughts

Rate limiting is one of those things users rarely notice when it works well, but systems definitely notice when it doesn’t.

Building APIShield gave me hands-on experience with distributed backend design, Redis scripting, and the tradeoffs behind different rate limiting strategies. It also made me appreciate how much engineering depth can hide behind a feature that, on the surface, sounds as simple as “block requests after a certain limit.”

If I continue iterating on this project, I’d love to explore:

richer analytics dashboards
per-plan throttling for SaaS-style use cases
Redis Cluster support
stronger observability and failure-mode handling
benchmarking different strategies under load

If you’ve built something similar, or would approach rate limiting differently, I’d love to hear your thoughts.

If you want to explore the implementation in more detail, the project is here:

GitHub: APIShield