DEV Community: SATYA SOOTAR

How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router

SATYA SOOTAR — Mon, 01 Jun 2026 16:57:52 +0000

When we think about apps like Instagram, WhatsApp, Uber, or Netflix, it's easy to get lost in the glamour of their features. The smooth feed, the instant message delivery, the live driver tracking, the seamless streaming. But what truly separates these giants from the millions of apps that never make it off the ground isn't just a clever idea, it's the architecture that holds it all up.

This isn't a blod on how to clone their UI pixel by pixel. You can find plenty of those. Instead, we're going to put on our engineering hats and explore how you would think about building the core systems of these apps from the ground up, using modern tools like Expo Router. The goal is to shift your mindset from "getting it to work" to "engineering for the long haul" and to show you how the right architecture makes all the difference.

The Myth of the Simple Folder Structure

We've all been there. You start a new project, a brilliant idea in your head, and the folder structure looks something like this:

src/
├── components/
├── screens/
├── hooks/
├── utils/
└── types/

This feels clean and organized. For a small app with five screens, it works perfectly. But then, a year later, your startup has taken off, the team has grown from 1 to 15 engineers, and the app now has 50 screens.

This simple folder structure becomes a nightmare. Opening the components/ folder is like looking into a junk drawer. You see Button.tsx, FeedPost.tsx, ChatBubble.tsx, RideCard.tsx, and no one knows which components are used where. Deleting a feature becomes a game of "hunt the import" across the entire project. It slows everyone down, and worse, it makes refactoring terrifying.

For a small app, this structure is fine. For a production-scale app that demands high performance, maintainability, and team collaboration, it's an absolute disaster. The simple way fails because it's fundamentally based on the "type" of a file, not the "function" of a feature. This is the first, and perhaps most important, lesson of scaling your React Native application.

A Better Way: The Feature-Based Architecture

The production way of thinking is to organize your code by features, not by file types. It's called "feature-based separation" or "colocation". The idea is simple: all the code that makes a single feature work lives in its own cozy folder.

Let's visualize the difference. Imagine an app with a feed and a user profile.

In the production structure, if you want to delete the "feed" feature, you delete the /feed folder. Done. No hunting around. It's a massive cognitive win for developers, especially when a team is working on different features simultaneously.

Expo Router: The Architect's Best Friend

This is where Expo Router shines. At its core, Expo Router is a file-based routing library built on top of React Navigation. This means the file structure of your app folder directly defines your app's navigation. It's incredibly powerful for large applications because it enforces a clear, predictable navigation pattern that scales without any additional mental overhead.

Let's see how we can marry feature-based architecture with Expo Router's file system.

app/
  _layout.tsx            // Root layout (check auth, setup providers)
  (auth)/               // Auth route group, no tab bar
    _layout.tsx
    login.tsx
    sign-up.tsx
  (app)/                // Protected app route group with tabs
    _layout.tsx         // Tabs layout (Feed, Search, Activity, Profile)
    (feed)/
      _layout.tsx       // Stack navigator for Feed
      index.tsx
      [postId].tsx
    (messages)/
      _layout.tsx       // Stack for Chat
      index.tsx
      [chatId].tsx
    profile/
      _layout.tsx
      index.tsx
      settings.tsx

This structure is the foundation. It tells us instantly what's public (auth), what's protected (app), and how the user moves through the app.

Building the Core Systems: A Four-Part Deep Dive

Now, let's use this architecture to think about the core systems for our four apps. We're not building a clone, but rather, understanding the architectural decisions behind their core features.

1. Instagram: The Infinite Feed

Instagram's main challenge is handling an endless stream of media-rich content. The core technical requirement is a high-performance, lazy-loading infinite scroll.

Expo Router Structure:
The (feed) folder would contain the main feed screen (index.tsx) and the dynamic route for a single post ([postId].tsx). This allows for deep linking directly to any post.

State Management: A combination of Zustand for global UI state (like the current user's feed preferences) and TanStack Query (formerly React Query) for managing server-state is a modern, powerful choice. TanStack Query is a master at caching, background refetching, and pagination, which is exactly what a feed needs.

Architecture in Action:
The Feed screen would use a FlatList with getItemLayout for memory efficiency. As the user scrolls, TanStack Query's useInfiniteQuery hook is triggered, fetching the next page of posts from an API. The API returns the data, which is then cached, and the UI updates instantly.

The Production Tradeoff: To keep the app fast and prevent it from consuming too much memory, you implement virtualized lists and heavy pagination. The tradeoff is complexity in data fetching and state synchronization, but it's the only way to handle a feed that could literally go on forever.

2. WhatsApp: Real-time Messaging with Offline-First Support

WhatsApp is a masterclass in real-time communication and offline resilience. You type a message to a friend in a different country, and they see the little typing indicator before the message pops into their chat, instantly.

Expo Router Structure:
The chat interface would live in the (messages)/[chatId].tsx screen. The deep linking with [chatId] is crucial. When a user taps a push notification for a new message, Expo Router can automatically navigate them directly to that specific chat using its built-in universal linking.

Core Technologies:

WebSockets (e.g., Socket.IO): For the real-time, persistent connection to send and receive messages instantly.
Offline-First Database (e.g., SQLite, WatermelonDB): All messages are first saved to a local database on the user's phone before they're even sent to the server.
Optimistic Updates: The UI updates instantly. Your message appears in the chat bubble before the network request is complete.

Architecture in Action:

You Send a Message: The UI calls a function. The message is saved to the local SQLite database and given a temporary id. The UI instantly renders the new message with a "sending" status icon.
Background Sync: A background job picks up the unsent message from the queue. It sends it to the server via the WebSocket connection.
Server Confirms: The server receives the message, broadcasts it to the recipient, and sends a confirmation back to your device.
Update Local State: Your app receives the confirmation, updates the local database, and changes the message status from "sending" to "sent".

The Production Tradeoff: The complexity here is high. You have to manage optimistic UI updates, conflict resolution (what if the message fails to send?), and keep your local database perfectly in sync with the server's version. The benefit, a blazing fast and reliable messaging experience that works on a shaky train connection, is worth every bit of the effort.

3. Uber: Maps and Live Location Tracking

Uber's magic is the live map. You see a car moving in real-time, and its ETA updating by the second. This is all about managing a constant stream of location data.

Expo Router Structure:
The ride-tracking screen is a huge part of the app's flow. The (app) group for a logged-in user would contain a ride folder with dynamic routes for an active ride, like ride/[rideId].tsx.

Core Technologies:

Maps SDK (e.g., MapView, Google Maps API): For rendering the map and driver's location.
WebSocket for Location Streaming: The driver's phone is constantly publishing its coordinates to a server. The server then broadcasts this to the rider's app via a WebSocket connection.
Efficient Re-rendering: Every new coordinate cannot cause a full screen re-render. You need to update only the map's marker.

Architecture in Action:

Ride Starts: The backend creates a unique room for the ride.
Driver Publishes Location: Every few seconds, the driver's app sends a "location update" message to the server's room.
Rider Listens: The rider's app is subscribed to the same room via a WebSocket.
Map Updates: When a new location arrives, the app uses a reference to the map's marker to smoothly animate it to the new position, without redrawing the whole screen.

The Production Tradeoff: The biggest challenge is handling spotty connections. What happens when the driver enters a tunnel? The app needs a robust reconnection strategy with exponential backoff and smart UI states that don't make the rider think the driver has vanished into thin air. This adds significant complexity to the WebSocket management.

4. Netflix: Heavy Content Delivery

Netflix's challenge is getting you from a giant list of movies to watching one, all with zero buffering. It's a masterclass in loading states, smart pre-fetching, and efficient video playback.

Expo Router Structure:
The sheer number of screens is a perfect use case for Expo Router's dynamic routes. You'd have a movie/[movieId].tsx route that can deep-link to any piece of content in Netflix's massive library.

Core Technologies:

FlatList with Horizontal Scrolling: For rendering rows of movie posters, optimized for performance.
Thumbnail Pre-fetching: As the user scrolls, the app starts downloading the images for the next set of movies before they're even on screen.
Lazy Loading: The video player and its heavy dependencies are only loaded when the user navigates to the movie screen.
Offline Downloads: Users can download content directly to the device's file system for later viewing.

Architecture in Action:

Browse: The home screen uses FlatList to render rows. Each row is a horizontal list of movie thumbnails.
Prefetch: As the user stops scrolling, the app examines what's about to come into view and sends a low-priority request to download those images.
Select a Movie: The user taps on "Stranger Things".
Lazy Load Details Screen: The app quickly navigates to the movie/[movieId].tsx screen. This screen's code bundle is small and loads fast.
Defer Loading: Immediately, the screen shows a skeleton UI and starts fetching movie details. The actual video player component, which is huge, is only imported and rendered after the details have loaded, keeping the initial navigation snappy.

The Production Tradeoff: You trade a super simple "load everything at once" model for a much more complex "load on demand" system. Managing the state of what is loading, what is pre-fetched, and what is cached adds layers of complexity, but it's the only way to ensure your app doesn't feel slow and bloated.

Putting It All Together: The Production-Grade Starter

So, what does all of this look like in a single, coherent architecture? Here's a diagram of a production-grade folder structure using the principles we've discussed.

This structure is your roadmap. It's how you build an app that doesn't just work for a few months, but for years.

Navigating the Waters: Authentication Flows and Shared Layouts

Two of the most common challenges in any app are managing the authentication flow and creating nested, shared layouts. Expo Router handles both beautifully.

Authentication Flow: With route groups, your (auth) and (app) folders are completely separate. Inside the root _layout.tsx, you would check an authentication state (from your Zustand store or a secure token). If the user is logged out, it renders the (auth) group (login, sign-up). If they're logged in, it renders the (app) group (the main tabs). Expo Router v5 introduced Stack.Protected which makes this pattern even more declarative and secure.

Shared Layouts and Nested Routing: You can easily create a stack navigator inside a tab. For instance, your feed screen can be a stack. The main (app)/_layout.tsx creates the tabs. Then, inside the (feed)/_layout.tsx, you create a stack navigator. This allows you to push a post details screen ([postId].tsx) on top of the feed, while the bottom tab bar remains visible.

The Unseen Hero: The API and Networking Layer

All the data for your app comes from an API. A clean networking layer is crucial. You should never directly call fetch from within a screen component. Instead, you create a service layer.

You would have a services/api.ts file that configures a single instance of an HTTP client (like Axios). It sets up base URLs, authentication headers, and response interceptors for error handling. Then, for each feature, you create a feature-specific API file (e.g., feed/api.ts) that calls your base client and exposes simple functions like fetchFeed(). Your UI components only call these simple functions, keeping them blissfully unaware of the underlying network implementation.

Wrapping Up: It's About Engineering Mindset

Building an app at the scale of Instagram, WhatsApp, Uber, or Netflix isn't about a single magic library or a clever piece of code. It's a million small, deliberate decisions about architecture, tradeoffs, and developer experience.

The tools we have today, especially Expo Router, provide an incredible foundation. With its file-based routing, deep linking, and universal design, it forces you into a structure that scales naturally. But a tool is only as good as the person wielding it.

The next time you open a new React Native project, resist the temptation of the simple folder structure. Take a moment to think about the future. Map out your features. Group your routes. Ask yourself, "How would this code look to a new developer a year from now?".

By asking these questions and following the principles of feature-based architecture, you're not just building an app. You're engineering a system built to last.

Hope you liked this blog. If there’s any mistake or something I can improve, do tell me. You can find me on LinkedIn and X, I post more stuff there.

Expo Router vs React Navigation: Which One Should You Use in 2026?

SATYA SOOTAR — Mon, 01 Jun 2026 15:44:48 +0000

If you've spent any time building React Native apps, you've already bumped into the question. You're setting up a new project, you need to move users between screens, and suddenly you're 40 minutes deep in a documentation rabbit hole wondering whether to go with the familiar React Navigation setup or take the leap to Expo Router. This article is going to break it all down, no hype, no fanboy energy, just an honest look at both options so you can make the call that actually fits your project.

First, What Does "Routing" Even Mean in a Mobile App?

On the web, routing is pretty intuitive. You type a URL, the browser goes to a page. Simple. In mobile apps, there's no URL bar, no browser history button, nothing like that. But users still need to move between screens, go back to where they came from, open modals, tab between sections, and all of that has to feel smooth and natural.

So in mobile development, routing is basically the system you use to manage how screens stack on top of each other, how state is preserved when you go back, how deep links work, and how the app knows which screen to show based on where the user is in the flow. Think of it like this: routing is "moving between screens while keeping your app's memory intact." When someone logs in, fills out a form, gets distracted and opens a modal, then comes back, the app should remember all of that. Routing is the machinery underneath that makes it happen.

In React Native, this doesn't come out of the box. The framework gives you the building blocks, but you have to wire up the navigation yourself. That's where libraries come in.

Why Navigation Is Such a Big Deal in React Native

React Native apps are essentially single-page applications. Everything runs in one JavaScript thread, rendered to native views. There's no browser doing the heavy lifting of managing history or transitions. You're responsible for it all.

Bad navigation kills good apps. A janky transition, a broken back button, a modal that doesn't dismiss properly, losing scroll position on a tab switch, these are the things that make users delete an app. Navigation isn't just a developer concern, it's directly tied to how polished your product feels.

On top of that, navigation affects how your code is organized. If your navigation logic is scattered, your codebase gets messy fast. Passing params from screen to screen starts feeling like passing notes in class, chaotic and fragile. The navigation library you choose will shape not just the user experience but the entire architecture of your app.

The Story of React Navigation

React Navigation showed up around 2017 and quickly became the community standard for React Native navigation. Before it, developers were using a library called Navigator that came built into React Native, and honestly, it was rough. It was hard to customize, the API was clunky, and it didn't support a lot of the patterns native apps needed.

React Navigation came in with a JavaScript-based approach, meaning the navigation logic runs entirely in JS rather than relying on native modules. This made it super flexible. You could customize everything. Stack navigators, tab navigators, drawer navigators, modal screens, you could compose all of these together however you needed.

Over the years it matured a lot. React Navigation v5 brought a component-based API that felt much more React-like. v6 improved performance and added better TypeScript support. By the time v7 rolled around, it had become incredibly stable and powerful, with proper native stack support through react-native-screens, smooth gesture handling, and deep link support.

Today React Navigation is still the backbone of a huge portion of React Native apps in production. It's battle-tested, well-documented, and has a massive community around it.

The Problems Developers Were Hitting

Here's the thing though. Even as React Navigation got better, there were real pain points that never fully went away.

The boilerplate was heavy. Every time you added a new screen, you had to register it with the navigator, define the route name as a string (or a typed constant if you were being careful), update your navigation types, and then navigate to it using navigation.navigate('ScreenName'). If you had a large app with lots of screens, this got tedious fast, and it was easy to make typos or let things fall out of sync.

Nested navigators were especially tricky. Imagine a tab navigator inside a stack navigator with a modal stack on top of that. Navigating from a screen deep inside one tab to a screen inside another tab required you to understand the full navigator hierarchy and use navigation.navigate with just the right combination of route names. One wrong step and things broke in subtle ways.

TypeScript support improved a lot but was never painless. You had to manually define types for every route and its params. It worked, but it was ceremony you had to maintain by hand.

Deep linking required a separate configuration object where you mapped URL patterns to route names. So your routing logic was in one place, but your deep link config was somewhere else entirely. Keeping them in sync was a real maintenance burden.

For small apps, none of this is a big deal. But as apps grow, you start to feel it. New developers joining the team had to understand both the navigator structure and the routing types before they could comfortably add a new screen. That's friction.

Enter Expo Router: Why It Was Built

Expo Router launched in 2023 and reached a stable v2 in late 2023, with v3 and v4 following through 2024 and 2025. The idea behind it was borrowed directly from the web. Specifically, from Next.js.

If you've used Next.js, you know how good file-based routing feels. You create a file at pages/about.tsx, and boom, there's a route at /about. No configuration, no registration, just a file. Expo Router brings that same mental model to React Native.

The key insight the Expo team had was this: your file system already knows about your screens. Why make developers maintain a separate navigation config that duplicates that information? Let the file system be the source of truth.

It's also important to understand that Expo Router is not a replacement for React Navigation at the infrastructure level. Under the hood, Expo Router is built on top of React Navigation. It uses the same navigators, the same gesture handling, the same native stack. What it adds is a layer of abstraction that manages the routing config automatically based on your folder structure. So when you use Expo Router, you're not leaving React Navigation behind, you're using a smarter way to configure it.

File-Based Routing Explained Simply

Here's the core concept. In Expo Router, you have an app/ directory. Every file you put in there becomes a screen. The file path becomes the route path.

app/
  index.tsx          -> /  (home screen)
  about.tsx          -> /about
  settings.tsx       -> /settings
  profile/
    index.tsx        -> /profile
    edit.tsx         -> /profile/edit

That's it. No navigator file to update. No route name strings to type. The file structure tells the router everything it needs to know.

Navigating between screens uses the Link component or the router object, and the paths you use match your file structure:

import { Link } from 'expo-router';

<Link href="/profile/edit">Edit Profile</Link>

Or programmatically:

import { router } from 'expo-router';

router.push('/profile/edit');

Because routes are paths (strings derived from your folder structure) rather than arbitrary route names, you get a lot of benefits automatically. TypeScript can infer types from your file structure using Expo Router's typed routes feature. Deep links work out of the box because your routes are already path-based. Sharing links between web and mobile becomes much simpler when both are using the same routing system.

Layouts and Nested Layouts in Expo Router

One of the most powerful things in Expo Router is the layout system. In each folder, you can have a special file called _layout.tsx. This file wraps all the screens inside that folder and lets you define shared UI or navigator configuration.

app/
  _layout.tsx        <- root layout (wraps everything)
  (tabs)/
    _layout.tsx      <- tab navigator setup
    index.tsx        <- first tab
    explore.tsx      <- second tab
  (auth)/
    _layout.tsx      <- auth flow layout
    login.tsx
    signup.tsx

The root _layout.tsx might set up things like a theme provider, a toast notification system, or your authentication context. The (tabs)/_layout.tsx defines the tab bar and which screens are tabs. The (auth)/_layout.tsx might handle redirecting already-authenticated users away from the login screen.

The parentheses in (tabs) and (auth) are a special Expo Router convention called "route groups." The folder name in parentheses is not included in the URL. It's just organizational. You're grouping screens logically without affecting the route paths.

So (tabs)/index.tsx has the route / not /(tabs)/. This is useful for organizing your code without creating weird nested URLs.

Shared layouts mean that if you're inside the tabs navigator and you navigate between tabs, the tab bar stays put and only the content area re-renders. You get this for free just by structuring your files correctly.

Protected Routes and Auth Flows

Authentication routing is something every real app has to deal with, and it's one of the areas where Expo Router shines with a clean pattern.

The idea is simple. Inside your (auth)/_layout.tsx, you check if the user is logged in. If they are, you redirect them to the main app. If not, you let them through to the login or signup screen. Inside your (tabs)/_layout.tsx or your root layout, you do the opposite. If the user isn't logged in, redirect them to /login.

Here's roughly what that looks like:

// app/(auth)/_layout.tsx
import { Redirect, Stack } from 'expo-router';
import { useAuth } from '@/hooks/useAuth';

export default function AuthLayout() {
  const { isLoggedIn } = useAuth();

  if (isLoggedIn) {
    return <Redirect href="/(tabs)" />;
  }

  return <Stack />;
}

// app/(tabs)/_layout.tsx
import { Redirect, Tabs } from 'expo-router';
import { useAuth } from '@/hooks/useAuth';

export default function TabsLayout() {
  const { isLoggedIn } = useAuth();

  if (!isLoggedIn) {
    return <Redirect href="/login" />;
  }

  return <Tabs />;
}

This is clean, explicit, and colocated with the screens it protects. In React Navigation, you'd typically handle this through conditional rendering of different navigator trees or through a more complex navigation state management setup. Both work, but the Expo Router pattern feels more intuitive to reason about.

Performance: Let's Be Honest About What Actually Matters

This is where a lot of comparisons get misleading. People throw around "Expo Router is faster" or "React Navigation has less overhead" without really qualifying what they mean. Let's break it down properly.

Bundle behavior: Expo Router supports automatic code splitting when used with Expo's Metro bundler in web mode. Each route can be lazily loaded, meaning the JavaScript for a screen only loads when the user navigates to it. In native mode (iOS/Android), this matters less because the whole bundle is bundled at build time anyway. React Navigation loads all screens eagerly by default, though you can manually implement lazy loading with the lazy prop on tab navigators.

Navigation transitions: Both approaches produce the same transition quality because Expo Router uses React Navigation's navigators under the hood. The native stack transitions you get from react-native-screens are the same regardless of which tool you use to configure them. There's no meaningful difference here.

Developer workflow speed: This is where Expo Router genuinely wins. Adding a new screen is creating a file. No config update, no type declaration, no route string to maintain. With Expo Router's typed routes, your IDE knows all valid route paths and will autocomplete them. This reduces cognitive load and bugs, which might not be a "performance" metric in the benchmarking sense, but it absolutely speeds up how fast you ship features.

Runtime overhead: Expo Router adds a thin abstraction layer on top of React Navigation. In practice, this overhead is negligible for any real-world app. You're not going to notice it.

Developer Experience: The Real Comparison

If you're a beginner just getting into React Native, Expo Router is genuinely more approachable. The mental model is simpler. Create a file, it's a screen. Navigate using a path. The concept maps directly to things you might already know from web development. You spend less time learning the framework and more time building the actual app.

For teams, file-based routing scales really nicely. When a new developer joins, they can understand the app's screen structure just by looking at the folder tree. You don't need to read a navigator config file to figure out what screens exist. This is a real benefit as teams grow.

For TypeScript users, Expo Router's typed routes (which you enable with "typedRoutes": true in your Expo config) give you end-to-end type safety on your paths. router.push('/profle/edit') will show a type error if you typo the path. That alone has saved me from embarrassing bugs.

React Navigation is not bad at developer experience, not at all. It's very explicit, which has its own value. You always know exactly how your navigators are composed because you wrote every line of it. For developers who prefer explicit configuration over convention, this feels more comfortable. There's also a huge amount of community knowledge, Stack Overflow answers, blog posts, and Discord help available for React Navigation compared to Expo Router.

Scalability for Large Applications

Let's say you're building something serious. A fintech app, a social platform, a healthcare tool. Something with dozens of screens, multiple user roles, complex flows, and a team of ten engineers working on it simultaneously.

With React Navigation at that scale, you'll likely have a main navigator file that's quite long, or you'll split navigators across multiple files and import them into each other. Neither is bad, but the manual nature of it means there's potential for it to drift and become hard to follow. Strong TypeScript discipline helps, but it's discipline you have to actively maintain.

With Expo Router at that scale, the folder structure does most of the organizational work for you. You can create nested groups, separate flows by folder, add route-specific layouts. The structure of the app is visible from the file system. New engineers can get oriented faster.

That said, Expo Router's conventions can feel constraining for non-standard navigation patterns. If you have a very custom navigation UX, like a multi-step wizard with complex back behavior, or a non-standard transition system, you might find yourself working around Expo Router's conventions rather than with them. React Navigation gives you more raw control in those cases.

Real-World App Folder Structure

Here's what a production-ready Expo Router project might look like:

app/
  _layout.tsx              <- root (providers, fonts, splash)
  +not-found.tsx           <- 404/unknown route handler

  (auth)/
    _layout.tsx            <- redirect if already logged in
    login.tsx
    signup.tsx
    forgot-password.tsx

  (app)/
    _layout.tsx            <- redirect if not logged in
    (tabs)/
      _layout.tsx          <- tab bar config
      index.tsx            <- Home tab
      explore.tsx          <- Explore tab
      inbox.tsx            <- Inbox tab
      profile.tsx          <- Profile tab

    post/
      [id].tsx             <- Dynamic route: /post/123
      [id]/comments.tsx    <- Nested: /post/123/comments

    settings/
      index.tsx
      notifications.tsx
      privacy.tsx
      account.tsx

  modal/
    image-preview.tsx      <- Modal screens
    share-sheet.tsx

The [id] syntax is for dynamic routes where the segment changes, like a user ID or post ID. router.push('/post/123') would render post/[id].tsx with id = "123" accessible via useLocalSearchParams().

Compare this to the equivalent React Navigation setup. You'd have a navigation/ folder with files like RootNavigator.tsx, AuthStack.tsx, AppTabs.tsx, SettingsStack.tsx, and a types.ts file defining all the route params. It works perfectly well, but it's more code to write and maintain.

What Companies and Teams Are Actually Choosing

In 2026, if you're starting a new project and using Expo (which is now the default recommendation from the React Native team itself), Expo Router is the default choice that comes out of the box. The npx create-expo-app template uses Expo Router. The official Expo documentation is written around Expo Router. New Expo features like server-side rendering, universal links, and the web support all integrate most cleanly with Expo Router.

Larger enterprise teams that have existing React Navigation codebases are generally not migrating. The cost-benefit doesn't make sense for stable production apps. If it works, it works.

Startups and new projects lean toward Expo Router for the DX benefits and because it positions them well for Expo's growing ecosystem.

Teams doing pure bare React Native (without Expo) still predominantly use React Navigation directly because Expo Router is designed for the Expo ecosystem. You can technically use it outside Expo, but it's not the intended use case and the experience gets rougher.

When NOT to Use Expo Router

Expo Router is genuinely not the right choice in some situations, and being honest about this matters.

If your project is bare React Native without Expo tooling, stick with React Navigation. Expo Router has dependencies on the Expo build system and Metro configuration. It can work outside of Expo, but you'll hit friction, and the community support for that setup is thin.

If you have highly custom navigation UX that doesn't map neatly to the file-based paradigm, you might find yourself fighting the conventions. Things like multi-step onboarding flows with complex skip logic, paginated full-screen flows, or deeply custom transition animations are easier to achieve with the direct control React Navigation gives you.

If your team is more comfortable with explicit configuration and dislikes "magic," React Navigation's transparency might be worth more than Expo Router's convenience. Good code is code your team understands and trusts.

If you're maintaining an existing React Navigation codebase that's working well, don't migrate for the sake of it. The grass is not always greener, and migrations introduce risk.

When React Navigation Still Makes More Sense

React Navigation is not a legacy tool. It's actively maintained, has a huge community, and is the right choice in plenty of real scenarios.

When you need very fine-grained control over the navigation state, like manually manipulating the navigation stack or implementing complex reset behaviors, React Navigation's imperative API gives you exactly what you need.

When you're building a library or a reusable component that other React Native apps will consume, you probably don't want an Expo Router dependency in your package. React Navigation is the neutral, universal choice.

When your team has deep React Navigation expertise and the project is time-sensitive, using what you know well beats learning new conventions under deadline pressure.

When you're targeting platforms or environments where Expo's toolchain isn't suitable, React Navigation is the safe choice.

Putting It All Together

Here's the honest summary. Expo Router and React Navigation are not really competitors in the way the title of this article might imply. Expo Router is built on React Navigation. Choosing Expo Router means choosing a better configuration experience layered on top of the same navigation infrastructure.

For most new apps being built in 2026 with the Expo ecosystem, Expo Router is the better default. The file-based mental model is intuitive, the TypeScript integration is excellent, and it makes your codebase easier for teams to navigate (pun intended).

For existing apps, apps outside the Expo ecosystem, or teams that value explicit configuration, React Navigation remains a completely solid choice that's not going anywhere.

The best navigation setup is the one your team understands, your users don't notice, and your codebase doesn't make you dread opening. Use that one.

Hope you liked this blog. If there’s any mistake or something I can improve, do tell me. You can find me on LinkedIn and X, I post more stuff there.

How Instagram Stores Reels, Photos, and Drafts Behind the Scenes

SATYA SOOTAR — Sun, 31 May 2026 09:11:22 +0000

You pull out your phone, record a 30-second Reel, add a trending audio, and hit "Save Draft" because you are not ready to post yet. You lock your phone, forget about it, come back three days later, and the draft is right there waiting for you. Perfectly intact. Nothing lost. But have you ever stopped to wonder how that actually works? Where did that video go? Who is holding onto it? And what happens the moment you finally hit "Share"?

This one is for you if you are building mobile apps, studying system design, or you are just genuinely curious about how apps like Instagram handle media at scale. We are going to walk through the full journey, from the moment you tap record to the moment your Reel appears on someone's feed in another country.

Why Social Media Apps Need a Special Approach to Media Storage

Regular text is tiny. A tweet, a caption, a comment, all of that is just a few hundred bytes at most. But media is a completely different animal. A single uncompressed 10-second video clip on a modern smartphone can easily be 200MB or more. A high-resolution photo can be 10MB to 15MB. Now multiply that by billions of users creating content every single day.

Instagram reportedly has over 2 billion monthly active users. If even a small fraction of them upload media daily, you are talking about petabytes of data moving through the system every 24 hours. This is why social media apps cannot afford to treat media storage the way a basic web form treats a file upload. They need a layered, thoughtful architecture that balances speed, cost, reliability, and user experience all at once.

The core challenge is this: users expect everything to feel instant, but the actual work happening under the hood is enormous.

The Journey Begins: Recording a Reel on Your Device

Let's start from the very beginning. When you open Instagram and start recording a Reel, the video is being captured by your phone's camera hardware and written to a temporary buffer in the app's local storage. This temporary storage lives inside what is called the app's sandbox, a private directory on your device that only Instagram can read and write to.

At this point nothing has gone to Instagram's servers yet. The video exists only on your phone. This is intentional. Uploading every frame as you record would be wasteful, slow, and would drain your battery. Instead, the app collects the raw footage locally first.

Your device is already doing some lightweight processing during recording, things like stabilizing the footage and encoding it into a workable format like H.264 or HEVC (H.265). These are video compression standards that dramatically reduce file size while keeping quality acceptable. Think of it as the video being "packed" efficiently before anything else happens.

What Happens When You Save a Draft

Here is where things get interesting. When you tap "Save Draft," Instagram does not just keep the video floating around in memory. It writes the file to a more permanent location within the app's local storage. On Android this is typically in the app's internal storage or cache directory. On iOS it is in a similar sandboxed directory managed by the operating system.

But the video file alone is not enough. A draft also needs to remember everything else you set up: the caption you started typing, the audio you chose, the stickers, the trim points on the video, the cover frame you selected. All of that metadata gets saved alongside the video, usually as a small structured data file, often in JSON or a similar lightweight format.

This combination, the video file plus its metadata file, is what makes a draft "complete." When you come back to it days later, the app reads both the video and the metadata and reconstructs your edit session exactly where you left it.

How drafts survive app restarts: This is a question that comes up a lot. The answer is simple but important. Because the draft is written to persistent local storage (not just held in memory), it survives the app being closed, your phone restarting, or even the app updating. Memory gets wiped when a process dies. Disk does not.

Local Storage vs Cloud Storage: Two Very Different Jobs

People often think of "storage" as one thing. But in the world of mobile apps, local storage and cloud storage serve completely different purposes and have different tradeoffs.

Local storage lives on your device. It is fast because there is no network involved. Reading a file from your phone's storage takes milliseconds. Writing to it is equally quick. The downside is obvious: it is limited to the size of your device, and if you lose your phone or clear the app's data, it is gone. Drafts live here because they are temporary and personal to you and your device.

Cloud storage lives on servers in data centers, usually spread across multiple geographic regions for redundancy. When you finally post your Reel, the video gets uploaded from your device to Instagram's cloud infrastructure. Once it is there, it can be accessed from anywhere, backed up across multiple servers, and delivered to users around the world. The tradeoff is that accessing it requires a network connection and takes more time.

A well-designed app like Instagram uses both strategically. Local storage for speed and offline capability, cloud storage for durability and shareability.

The Upload Pipeline: What Actually Happens When You Hit "Share"

Tapping "Share" kicks off one of the more complex workflows in the entire app. A lot happens in those few seconds before you see the "Your Reel has been shared" confirmation.

Chunked uploading is the first key concept here. Instead of sending the entire video file as one giant request, Instagram's client splits it into smaller pieces called chunks. Each chunk is uploaded separately. If your connection drops halfway through, you do not have to start over from the beginning. The app just resumes from the last successfully uploaded chunk. This is called resumable uploading, and it is critical for large files on mobile networks where connections are unreliable.

Upload queuing is also happening here. Your video gets placed in a queue so the upload can continue even if you navigate away from the screen or switch to another app. This is handled by a background process that the operating system allows to keep running for a period of time even when the app is not in the foreground.

Once all the chunks are received on Instagram's servers, they are reassembled and verified. A checksum, basically a mathematical fingerprint of the file, is compared to ensure nothing was corrupted during transit.

Media Processing and Compression: Making Videos Work for Everyone

Here is something important to understand: the raw video you recorded on your iPhone 15 Pro is not what plays on your friend's older Android device. Instagram processes and re-encodes every piece of media it receives.

When your video hits Instagram's servers, it enters a media processing pipeline. This pipeline does several things. It transcodes the video, meaning it converts it into multiple different formats and quality levels. There is typically a high-quality version for users on fast WiFi connections, a medium-quality version for 4G, and a low-quality version for slower connections. This technique is called adaptive bitrate streaming.

The processing pipeline also handles things like rotating the video if the metadata says it was recorded sideways, normalizing audio levels, and stripping out any metadata from the file that could expose sensitive information (like the exact GPS coordinates baked into a photo).

For photos, a similar process runs. The original image is compressed to reduce file size, resized to standard dimensions, and converted to a format optimized for the web and mobile display. Instagram famously uses JPEG compression quite aggressively, which is why images sometimes look slightly different after upload compared to the originals on your camera roll.

All of this processing happens asynchronously in the background after your upload completes. It is one reason why sometimes you see "Processing..." on a video before it becomes fully viewable.

Thumbnail Generation and Previews

Before anyone watches your Reel, they see a thumbnail. That tiny preview image is doing a lot of work. It needs to be visually compelling enough to make someone stop scrolling, and it needs to load instantly even on a slow connection.

Instagram automatically generates a thumbnail from your video, usually pulling a frame from somewhere near the beginning or letting you choose your own cover frame. That thumbnail image gets stored separately from the video itself and treated as a first-class asset. When someone's feed loads, their app downloads thumbnails first because they are much smaller than the actual videos. This is what creates the experience of seeing still images in your feed before the videos start playing.

Low-resolution preview images, sometimes called "blur-up" previews or LQIP (Low Quality Image Placeholders), are generated too. These are tiny, low-fidelity versions of the thumbnail, maybe 20 to 40 pixels wide, that can be embedded directly in the app's response data. They display instantly before the real thumbnail even finishes loading, giving the illusion of content appearing immediately.

Caching: Why Your Feed Loads So Fast on Reopen

You have probably noticed that when you close Instagram and reopen it quickly, your feed appears almost instantly. That is caching at work.

A cache is a local store of data that the app saves to your device so it does not have to re-download the same content over and over. When you scroll through your feed, Instagram is downloading posts and storing them in a cache on your device. The next time you open the app or scroll back up, it reads from that cache instead of hitting the server again.

The interesting challenge with caching is knowing when to invalidate it, meaning when to throw away the cached version and fetch a fresh one. If someone edits their post or deletes it, you do not want to keep showing the old cached version indefinitely. Apps handle this in various ways, like setting expiry times on cached content or using version identifiers that change whenever content is updated.

Caching also happens at multiple levels. The app caches images and videos on your device. But there are also caches sitting at the server infrastructure level, which brings us to CDNs.

Content Delivery Networks: How Your Reel Reaches Someone in Japan

Once your Reel is processed and live on Instagram's servers, it needs to be delivered to users potentially on the other side of the world. Sending every video request all the way back to Instagram's primary data centers (which might be in the US) for every single viewer would be unbearably slow and expensive.

This is where a CDN, or Content Delivery Network, comes in. A CDN is a globally distributed network of servers placed in data centers all around the world. When Instagram publishes your Reel, the video gets copied out to CDN servers in dozens or hundreds of geographic locations.

When someone in Tokyo opens their feed and your Reel starts playing, their app is actually fetching the video from a CDN server located in Asia, not from a server in Virginia. The physical distance between the user and the server is massively reduced, which means lower latency, faster load times, and a smoother playback experience.

CDNs also act as a buffer. If your Reel suddenly goes viral and a million people try to watch it at the same time, the CDN absorbs that traffic load across all its distributed nodes instead of hammering Instagram's central infrastructure.

Managing the Whole System: Storage, Performance, and User Experience

Pulling all of this together is not just a technical challenge. It is also a product and business challenge. Every megabyte of video stored costs money. Every CDN transfer costs money. Instagram has to make constant decisions about what to store, for how long, in how many copies, and at what quality level.

Popular content that gets viewed millions of times is worth keeping in multiple high-quality copies across many CDN nodes because the cost of delivery is offset by the engagement it drives. Old content that barely gets viewed might get moved to cheaper, slower "cold storage" over time. This is a concept called tiered storage: hot storage for frequently accessed content, cold storage for content that is rarely accessed.

On the user experience side, all of these infrastructure decisions translate into choices about how the app behaves. How long does Instagram keep your drafts locally before offering to clear them? How aggressively does it cache videos on your device before managing your storage? When does it decide to start preloading the next video in your feed before you even scroll to it? These are all product decisions backed by the storage and delivery architecture underneath.

The best mobile apps treat storage as a first-class concern, not an afterthought. Every byte has a cost, and every delay has a user impact. The fact that Instagram can make recording, editing, saving, uploading, processing, and delivering a video feel seamless across billions of devices around the world is genuinely one of the more impressive engineering achievements of the modern internet.

Putting It All Together

So the next time you save a Reel as a draft, here is what you now know is happening. The video is sitting in your device's local storage inside Instagram's sandboxed directory, paired with a metadata file that remembers every edit you made. When you finally post it, it gets chunked and uploaded to Instagram's servers over a resumable upload session. On the server side it gets processed, compressed, transcoded into multiple quality levels, and thumbnails get generated. The processed files get pushed out to CDN nodes around the world. And when your followers open the app, their clients fetch the video from the closest CDN node while also checking their local cache to avoid unnecessary downloads.

Every step in that chain is solving a real engineering problem. Speed, reliability, scale, cost, and user experience are all in tension with each other, and every design decision is a tradeoff between them. Understanding these tradeoffs is what separates engineers who just build features from engineers who build systems that actually hold up under pressure.

Hope you liked this blog. If there’s any mistake or something I can improve, do tell me. You can find me on LinkedIn and X, I post more stuff there.

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

SATYA SOOTAR — Sun, 31 May 2026 07:45:48 +0000

You're on the subway, signal drops to zero, and you still tap send on that message. A single grey tick appears. Your phone didn't throw an error, the app didn't crash, and somehow that message will reach your friend the moment you get back above ground. How does that actually work? Let's break it down.x

Why Messaging Apps Need Offline Support

Think about how you actually use your phone. You're in an elevator, on a flight, driving through a tunnel, or just in a building with terrible WiFi. Connectivity is not a constant, it's a privilege that comes and goes. If WhatsApp only worked when you had a perfect internet connection, it would be practically useless in the real world.

This is why modern messaging apps are built with what engineers call an offline-first architecture. The core idea is simple: the app should work as close to normal as possible even without internet, and quietly reconcile everything with the server the moment connection returns. The user should barely notice the difference.

What Actually Happens When You Hit Send Without Internet

Let's start with the simplest scenario: airplane mode.

You open WhatsApp, type "I'll be there in 10 minutes", and hit send. The app does not wait for a server response. It immediately displays your message in the chat with a single grey clock or tick icon. From your perspective the message is sent. But technically, it hasn't left your device yet.

What WhatsApp just did is write your message to local storage on your phone. It saved it as a pending item in a local queue, stamped it with a timestamp, assigned it a local ID, and tagged it with a status of "pending". The UI renders it immediately because it's reading from local storage, not from a server. That's why you see it instantly.

This pattern is called optimistic UI. The app assumes the best case scenario, shows you the result immediately, and handles the actual network operation in the background.

Local Storage and Message Persistence

Your phone is running a tiny database. On Android, WhatsApp uses SQLite, a lightweight relational database that lives right on your device. On iOS it works similarly. Every message you send or receive gets stored in this local database, including messages you haven't sent yet.

This local database holds a lot more than just text. It stores the message content, who sent it, who it's going to, what time it was created, what its current delivery status is, and whether it's been queued for sending. Think of it like a local source of truth that the app reads from first before even thinking about the internet.

This is also why WhatsApp can show you your entire chat history even when you're completely offline. You're not loading messages from a server, you're reading from the database on your own device.

The Message Queue: Your Phone's Outbox

When a message is saved locally and there's no internet, it gets placed in what's called a message queue. This is basically an ordered list of things that need to be sent to the server when connectivity comes back.

The queue respects order. If you send three messages while offline, they go into the queue in sequence: message 1, message 2, message 3. When the internet returns, they get sent in that exact order. This matters because message ordering is something users care about deeply and it would be confusing if your messages arrived out of sequence.

The queue also handles retries. If the app tries to send a message and the connection drops mid-attempt, it doesn't give up. It retries with a strategy called exponential backoff, which means it waits a little, tries again, waits a bit longer, tries again, and so on. This prevents the app from hammering the server repeatedly and draining your battery.

Syncing When You Come Back Online

This is where things get interesting. The moment your phone detects internet connectivity, a background process wakes up and starts the sync.

Here's roughly what happens:
First, the app works through the outgoing queue and uploads your pending messages to the WhatsApp server. Second, it asks the server if there are any incoming messages it missed while you were offline. The server has been holding those messages and delivers them now. Third, the local database gets updated with the new information and the UI refreshes to show everything.

This process of having multiple places store data (your phone and the server) and then reconciling them is called eventual consistency. You're not guaranteed that everyone sees the same state at the exact same millisecond. But you are guaranteed that eventually, once everyone is online, everything will be consistent. It's a deliberate tradeoff that prioritizes availability (the app keeps working offline) over perfect real-time accuracy.

Delivery States: What Those Ticks Actually Mean

This is probably the most visible part of the whole system and one most people are curious about.

One grey tick means the message has been saved on your device and sent to WhatsApp's server. The server has it. But it hasn't been delivered to your recipient's device yet, maybe they're offline too.

Two grey ticks means the message was successfully delivered to your recipient's device. Their phone has it. They may not have opened the chat though.

Two blue ticks means your recipient opened the chat and the message was displayed on their screen. Their app sent a read receipt back to the server, which forwarded it to you.

Each of these is a distinct state in the database. The message record gets updated as it moves through these stages. If you're offline when someone reads your message, those blue ticks will appear the next time your phone connects and pulls the updated status from the server.

Handling Media While Offline

Text messages are tiny, a few bytes at most. But photos, videos, voice notes and documents are a different story. You can't realistically queue up a 50MB video and fire it off the moment you reconnect without the user noticing.

Here's how WhatsApp handles it. When you attach a photo and hit send offline, the media file gets saved locally and tagged as "pending upload". The text metadata (who sent it, which chat, what time) goes into the queue just like a regular message. When connectivity returns, the media gets uploaded to WhatsApp's media servers first. Once the upload completes and WhatsApp gets a URL for that file, the message is then sent with a link pointing to that media.

On the receiving end, your friend's phone gets the message with the media URL but doesn't automatically download the file. That's a separate download that happens over their connection, which is why you sometimes see a "tap to download" prompt rather than media appearing instantly. This keeps the sync process fast and lets users decide whether to download large files on mobile data.

Conflict Resolution and Message Ordering

Here's a tricky scenario. What if two people in a group chat both send messages at almost the exact same time while one of them is on a spotty connection? Whose message comes first?

WhatsApp uses server-side timestamps for final ordering. When your message reaches the server, the server stamps it with an authoritative time. That server timestamp becomes the canonical order. If messages arrive at the server out of order (because one person had a delay), the server figures out the right sequence and delivers them in the correct order to everyone.

On your device, you might briefly see messages in a slightly different order before the sync catches up. This is eventually corrected, which is again that eventual consistency idea in action. The goal is that once everyone syncs, the conversation looks the same for everyone.

Reliability vs Real-Time: The Tradeoff

There's a genuine tension here that's worth understanding. If you prioritize reliability (messages always get through, the app never loses your data), you end up with some latency and complexity. If you prioritize real-time delivery (messages arrive instantly with no local queuing), you lose resilience when the network is unreliable.

WhatsApp has clearly chosen reliability. The local queue, the persistent database, the retry logic, all of this adds complexity but means your message almost never gets lost. The tradeoff is that delivery isn't always instant and the two-tick system exists precisely to tell you where in the pipeline your message currently sits.

Why Offline-First Makes the Experience Feel Smooth

Here's the thing about offline-first design that isn't immediately obvious. It actually makes the app feel faster even when you do have good internet. Because the app reads from local storage first and updates the UI immediately without waiting for server confirmation, everything feels snappy. You're not sitting there waiting for a round trip to a server in some data center. You type, you send, you see it. Done.

The network operation happens quietly in the background. When the server confirms, the status updates. But the user experience is driven by local state, not network state. This is a fundamental design philosophy and it's the reason modern apps like WhatsApp, iMessage, and Telegram feel so much more responsive than older web-based messaging tools that required a live connection for every single action.

Putting It All Together

So next time you tap send in a tunnel, here's what's silently happening on your phone. Your message is written to a local SQLite database. The queue manager picks it up and holds it. The UI reads from the local database and shows you your message immediately. When the connection returns, the queue drains in order to the server, the server delivers it to your recipient, and both devices update their local databases with the new status. The ticks change color. Everything catches up.

It's a beautifully engineered illusion of simplicity sitting on top of a surprisingly sophisticated system. And the next time someone says "I sent you a message, didn't you get it?", you can explain exactly why the answer might be more complicated than it sounds.

Hope you liked this blog. If there’s any mistake or something I can improve, do tell me. You can find me on LinkedIn and X, I post more stuff there.

I Spent a Weekend Hunting Through Linux's File System and Here's What I Found

SATYA SOOTAR — Fri, 29 May 2026 05:49:26 +0000

Most people learn Linux by memorizing commands. ls, cd, mkdir. But here's the thing, that barely scratches the surface of what's actually going on underneath. Linux is one of those systems where the more you dig, the more you realize the entire OS is basically a giant, structured collection of files that control everything. I decided to stop running commands blindly and actually go hunting. What I found was genuinely interesting.

This blog covers my top discoveries from exploring the Linux file system, things I wish someone had explained to me when I was starting out. Not a command list. Just a deep dive into what's really going on.

Before We Start: The Map You Need

Here's how the top-level Linux file system is roughly laid out

1: `/etc/passwd` Was Never Really About Passwords

When you first hear "the password file," you assume it holds passwords. The name is right there. But open it and run cat /etc/passwd on any modern Linux machine, and you'll see something like this for each user:

root:x:0:0:root:/root:/bin/bash
john:x:1001:1001:John Doe:/home/john:/bin/bash

That x in the second field? That's where the password hash used to live, literally stored in plain text in early Unix systems. Which is terrifying. At some point, system designers realized having world-readable passwords was a bad idea, so they moved the actual hashed passwords into /etc/shadow, which is only readable by root.

The fields in /etc/passwd tell you: username, password placeholder, UID (user ID), GID (group ID), full name, home directory, and default shell. This file is the backbone of user identity on Linux. Every time you log in, something reads this file to figure out who you are, where your home folder is, and which shell to launch.

What I found interesting: system services like www-data, nobody, and daemon are also listed here. These are not human users, they're service accounts created so that web servers and background processes don't have to run as root. It's a simple but clever way to limit damage if something gets compromised.

2: `/etc/shadow` Is Where the Real Secrets Live

Once you're root, run sudo cat /etc/shadow. Each line looks something like:

john:$6$randomsalt$longhashstring...:19800:0:99999:7:::

Breaking that down: the hash starts with $6$ which means SHA-512 (older systems used $1$ for MD5, which is now considered weak). After that you have the salt, then the actual hash. Then a bunch of numbers representing: days since last password change, minimum days before change allowed, maximum days before forced change, and warning days before expiry.

This file exists specifically because /etc/passwd has to be readable by everyone (programs need to look up usernames), but passwords obviously shouldn't be. So Linux splits the concern. Public info in one file, secret info in another, with strict permissions on the second one.

The insight here is that Linux uses file permissions as a security boundary — not some fancy encryption layer, just strict ownership rules. Simple, elegant, effective.

3: `/etc/hosts` Is the Original DNS

Before DNS servers existed, every machine on the internet had a manually updated file mapping hostnames to IP addresses. That file was /etc/hosts. Today we have massive distributed DNS infrastructure, but this file still exists and still takes priority over DNS lookups on most systems.

127.0.0.1   localhost
127.0.1.1   mymachine
192.168.1.50  dev-server.local

Run ping dev-server.local after adding an entry there and it works instantly, no DNS query needed. Developers use this trick all the time to redirect domains locally during development. Security researchers use it to block known malicious domains by pointing them to 127.0.0.1.

The order in which Linux resolves names is controlled by another file: /etc/nsswitch.conf. Look for the line:

hosts: files dns

"files" means check /etc/hosts first. "dns" means then go to the DNS server. Change that order and you change how your entire system resolves hostnames. That one line has enormous consequences.

4: `/etc/resolv.conf` Is Your Gateway to the Internet

When /etc/hosts doesn't have an answer, Linux goes to a DNS resolver. The configuration for which DNS server to use lives in /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 1.1.1.1
search local.lan

Simple file, massive implications. The nameserver lines tell the system where to send DNS queries. The search line appends a domain suffix to short hostnames — so typing ssh webserver might actually try webserver.local.lan first.

On modern systems using systemd-resolved or NetworkManager, this file might actually be a symlink:

ls -la /etc/resolv.conf
# → /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

That means it's dynamically managed. The actual DNS logic lives elsewhere in systemd. The file is just a compatibility shim. I found this genuinely surprising — a file I assumed was simple and static is actually a managed symlink pointing to a runtime-generated config.

5: `/proc` Is Not a Real Directory

This one blew my mind a little. The /proc directory looks like a folder full of files, but none of those files actually exist on your disk. /proc is a virtual filesystem - it's generated on-the-fly by the Linux kernel every time you read from it.

Run this:

cat /proc/cpuinfo

You'll get detailed info about your CPU: model name, cores, cache size, flags showing what features it supports. That data isn't stored anywhere. The kernel just synthesizes it when you ask.

Same with /proc/meminfo - it gives you a live breakdown of your RAM usage. MemTotal, MemFree, Cached, SwapUsed. Tools like free -h and htop are literally just reading this file and formatting the output nicely.

The design philosophy here is beautiful: instead of a special system call API for every piece of system information, Linux just exposes everything as files. Want CPU info? Read a file. Want memory stats? Read a file. This makes it incredibly easy to access kernel internals from any language that can open a file.

6: `/proc/[PID]` Lets You Inspect Any Running Process

Every running process on your system has a numbered folder inside /proc. Find your shell's PID with echo $$, then explore that folder:

ls /proc/$$/

You'll see things like:

cmdline — the exact command that launched this process
environ — all environment variables it was started with
fd/ — a folder containing symlinks to every open file descriptor
maps — the memory map: which libraries and files are loaded into memory
status — current state, memory usage, which user it runs as

The fd/ folder is particularly useful. Every file the process has open — log files, network sockets, config files — shows up here as a symlink. This is how tools like lsof work. They're just walking through /proc/[PID]/fd/ for every process and reporting what they find.

One practical insight: if a program deletes a file that another process still has open, the data isn't actually gone yet. It stays on disk until the file descriptor is closed. You can even recover the data by copying from /proc/[PID]/fd/[number]. That's a useful recovery trick.

7: `/proc/net/route` Shows Your Routing Table as a File

Most people use ip route or netstat -r to see the routing table. But those tools are just reading /proc/net/route. Open the raw file and you see:

Iface  Destination  Gateway  Flags  RefCnt  Use  Metric  Mask  MTU  Window  IRTT
eth0   00000000     0101A8C0 0003   0       0    100     00000000 0  0       0

The values are in hex and reversed byte order, which looks confusing at first. But once you decode them: 0101A8C0 reversed in pairs is C0.A8.01.01 which in decimal is 192.168.1.1. That's your default gateway.

Flag 0003 means the route is Up and is a Gateway route. This is the actual kernel routing table. Every packet your machine sends consults this structure to decide where to go next.

Understanding this means you understand why changing your default gateway works the way it does, why VPNs can reroute all traffic (they add a more specific route), and why split tunneling is possible (some traffic goes through VPN, some doesn't, based on which route is more specific).

8: `/dev/null`, `/dev/zero`, and `/dev/urandom` Are Not Real Files Either

The /dev directory is full of device files that let user space programs interact with hardware or kernel features. Most are physical device interfaces, but three stand out as being almost philosophical:

/dev/null is a black hole. Anything written to it disappears. Anything read from it returns nothing. You'll see it everywhere:

command 2>/dev/null   # silence error output

/dev/zero is an infinite source of null bytes. Read from it and you get zeros forever. It's used to create empty files of a specific size, wipe disks, or pre-allocate space.

/dev/urandom is an infinite source of random bytes, generated by the kernel's entropy pool (keyboard timings, disk interrupts, network packets, etc.). It's how secure random numbers are generated on Linux. When your system generates an SSH key, it's reading from here. When your browser generates a TLS session key, it eventually traces back to here.

The kernel trick of representing these as files means any program can use them without needing special APIs. A shell script can generate random data just as easily as a compiled C program.

9: `/etc/fstab` Decides What Gets Mounted at Boot

Every time Linux boots, it reads /etc/fstab to figure out which filesystems to mount and where:

UUID=abc123   /         ext4  defaults        0 1
UUID=def456   /home     ext4  defaults        0 2
UUID=ghi789   swap      swap  sw              0 0
tmpfs         /tmp      tmpfs mode=1777,size=2G 0 0

Using UUIDs instead of device names like /dev/sda1 is a modern improvement. Device names can change if you add a new disk, but UUIDs are stable. Each field means: device, mount point, filesystem type, mount options, dump flag, fsck order.

The last line is interesting: tmpfs on /tmp means your temp folder is actually stored in RAM, not on disk. Everything in /tmp is gone on reboot and reads/writes happen at memory speed. Many systems don't do this by default, but it's a performance and privacy improvement when you add it.

If you mess up /etc/fstab, the system can fail to boot. It's one of those files that has enormous power with very little protection against mistakes.

10: `/etc/systemd/system/` Is Where Services Live

On modern Linux systems using systemd, services are defined as unit files. The system ones live in /lib/systemd/system/, but anything in /etc/systemd/system/ takes priority and overrides them. This is where you put custom services or modifications to existing ones.

Open any .service file, like ssh.service, and you'll find it surprisingly readable:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service

[Service]
ExecStart=/usr/sbin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

The After= directive is what makes the dependency graph work. Systemd reads all unit files at boot and builds a dependency tree, then starts services in parallel where possible, serializing only where After= or Requires= demands it. This is why modern Linux boots faster than older init systems.

The Restart=on-failure is particularly useful. If your web server crashes, systemd just restarts it automatically. No daemon needed to babysit it.

11: `/var/log/auth.log` Is a Security Timeline

If you want to know what's been happening on your machine security-wise, read /var/log/auth.log (or /var/log/secure on Red Hat-based systems). Every login attempt, sudo usage, SSH connection, and authentication failure is logged here.

sudo grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head

That command pulls out every failed password attempt, groups by IP address, and shows you who's been hammering your machine. On any internet-facing server, you'll see hundreds or thousands of attempts from random IPs. This is constant and automated — bots scanning the entire internet looking for weak passwords.

Looking at the timestamps and patterns in this log teaches you more about real-world security threats than almost any textbook. You can see brute force patterns (same IP, rapid attempts), credential stuffing (many different usernames tried), and distributed attacks (same pattern from many IPs). Tools like fail2ban read exactly this file and auto-block attacking IPs.

12: `/etc/sudoers` Controls Who Can Do What as Root

Running sudo visudo (the safe way to edit this file) reveals the rules governing privilege escalation. The default you'll always see:

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

This means: user root can run all commands on all hosts as any user. Members of the sudo group (the % prefix means group) can do the same. But you can get much more specific:

john    ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

This lets john restart nginx without a password, but nothing else. This principle of least privilege is a core security concept — give people only the permissions they actually need. If john's account gets compromised, the attacker can restart nginx but can't do much else.

The file uses a strict syntax, and if you corrupt it, you can lock yourself out of sudo entirely. That's why visudo exists — it validates syntax before saving. It's one of those files where Linux forces you to use a specific editor to protect you from yourself.

The Bigger Picture

What surprised me most wasn't any single file. It was the consistent philosophy running through all of it. Linux treats everything as a file. Hardware, processes, random number generators, network state, running services. This "everything is a file" design means that the same tools (reading, writing, piping, permissions) work across completely different concerns. A web developer reading a text file and a kernel reading a network interface are using the same fundamental operation.

That's why Linux is so composable. You can pipe /dev/urandom through a text processor, read live CPU stats with a simple cat, redirect a program's output into nothing using a file called null. The whole system is built on one unifying abstraction, and once that clicks, Linux stops feeling like a collection of magic commands and starts feeling like a coherent, logical system you can actually reason about.

Go hunt around in these directories yourself. You'll find things that aren't in this post. That's kind of the whole point.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

How React's Virtual DOM Works Under the Hood

SATYA SOOTAR — Thu, 28 May 2026 06:55:27 +0000

So you've been using React for a while, calling setState, watching your UI update magically, and somewhere in the back of your head you've been wondering... how does this actually work? Like, what is React actually doing between the moment you change some state and the moment your screen updates?

That's exactly what we're going to break down today. No fluff, no theory marathons. Just a clear, step-by-step walkthrough of what's really happening under the hood.

First, Let's Talk About the Real Problem

Before Virtual DOM even makes sense, you need to understand what problem it's solving.

The browser has something called the Real DOM (Document Object Model). Think of it as a giant tree of objects that represents every element on your page. Every <div>, every <button>, every <p> tag lives in this tree. When you update something, the browser has to repaint, reflow, and recalculate layouts. And doing that frequently? It's expensive. To understand how a browser works, check out this blog.

Here's the thing about direct DOM manipulation: it's not the reading that's slow, it's the writing. Every time you touch the DOM, the browser kicks off a cascade of work. If you're updating ten different elements separately, you're triggering that cascade ten times. In older jQuery-style apps, developers would do things like this:

document.getElementById('user-name').innerText = 'John';
document.getElementById('user-age').innerText = '25';
document.getElementById('user-avatar').src = 'john.jpg';
// ...and so on for every little thing that changed

Each one of those is a direct punch to the Real DOM. And as your app grows, those punches add up fast. The UI stutters, animations drop frames, and users start noticing.

React's answer to this was: what if we stop going directly to the DOM every single time something changes?

Enter the Virtual DOM

The Virtual DOM is essentially a lightweight JavaScript object that mirrors the structure of the Real DOM. It's not a browser thing, it's just plain JavaScript living in memory.

When React renders your components, it doesn't immediately write to the Real DOM. Instead, it first builds this Virtual DOM tree, a nested JavaScript object that describes what the UI should look like. Something like this internally:

{
  type: 'div',
  props: { className: 'container' },
  children: [
    {
      type: 'h1',
      props: {},
      children: ['Hello, John']
    },
    {
      type: 'p',
      props: { className: 'bio' },
      children: ['Frontend Developer']
    }
  ]
}

This is basically what your JSX compiles down to. That <div className="container"> you write? React transforms it into something like the object above using React.createElement() calls behind the scenes.

Creating and comparing JavaScript objects is super cheap compared to touching the browser's DOM. That's the whole game here.

The Initial Render: How It All Starts

When your React app loads for the first time, here's exactly what happens:

Step 1: React takes your root component (usually <App />) and starts calling your component functions one by one, top to bottom.

Step 2: Each component returns JSX, which gets compiled into React.createElement() calls, building up that Virtual DOM tree we talked about.

Step 3: Once the full Virtual DOM tree is ready, React takes it and does a single, efficient pass to build the Real DOM and inject it into your <div id="root">.

This first render is actually doing real DOM work, React has no choice here because the page is blank. But it does it in one shot, building everything in memory first and then committing it to the browser in one go. This is already smarter than doing a bunch of individual DOM manipulations.

Now Something Changes: State or Props Update

This is where the magic really happens. Let's say a user clicks a button and you call setState. Here's the sequence of events React kicks off:

Step 1: React marks the component as "needs re-render."

Step 2: React calls your component function again and produces a brand new Virtual DOM tree. This is a fresh snapshot of what the UI should look like after the change.

Step 3: React now has two Virtual DOM trees sitting in memory: the old tree (what the UI currently looks like) and the new tree (what it should look like after the update).

Step 4: React runs a process called diffing, comparing the old tree to the new tree to figure out exactly what changed.

Step 5: React collects all the differences into a minimal set of changes, called a patch, and applies only those changes to the Real DOM.

That last part is the key insight. Instead of re-rendering everything, React surgically updates only what actually changed.

Diffing: How React Compares Two Trees

Diffing is the process of comparing the old Virtual DOM tree with the new one. The technical term React uses is reconciliation. Let's make this concrete.

Imagine your old tree looked like this:

<ul>
  <li>Apple</li>
  <li>Banana</li>
  <li>Cherry</li>
</ul>

And after a state change, the new tree looks like this:

<ul>
  <li>Apple</li>
  <li>Mango</li>    <-- changed
  <li>Cherry</li>
</ul>

React walks through both trees simultaneously, node by node. When it hits <li>Banana</li> in the old tree and <li>Mango</li> in the new tree, it flags that as a change. Everything else matches, so React only updates that one text node in the Real DOM. One update. Not three.

React's diffing uses two important heuristics to stay fast:

1. Elements of different types produce completely different trees. If you switch a <div> to a <span>, React doesn't try to figure out what to reuse. It just tears down the old subtree and builds a new one from scratch.

2. The key prop helps React track list items. This is why React warns you when you render a list without keys. Without keys, if you insert an item at the top of a list, React thinks every single item changed because positions shifted. With keys, React can figure out "oh, this item just moved, it didn't change" and skip unnecessary updates.

// Without keys: React gets confused on reorder/insert
{items.map(item => <li>{item.name}</li>)}

// With keys: React tracks each item correctly
{items.map(item => <li key={item.id}>{item.name}</li>)}

Minimal Updates: Updating Only What Changed

So React has figured out the diff. Now what?

React batches all those changes into what's called a commit phase. Instead of applying each change one at a time (which would trigger multiple browser repaints), React collects all necessary DOM operations and applies them together in a single pass.

This is huge for performance. The browser gets to do its expensive reflow/repaint work exactly once, no matter how many things changed in your component tree.

Let's think about this with an example. Say you have a dashboard with 50 components. The user updates their profile name. Without Virtual DOM, you might naively re-render every component touching the DOM 50 times. With React's approach, React re-renders the components in memory (cheap, it's just JavaScript), figures out only the name text node changed, and makes exactly one targeted update to the Real DOM.

Why This Actually Improves Performance

Let's put it all together with a clear picture:

Direct DOM manipulation forces you to write individual DOM operations manually. If you're not careful, you'll trigger multiple reflows and repaints. At scale, this becomes a performance nightmare.

React's Virtual DOM approach gives you a much smarter pipeline. You describe what your UI should look like, React figures out how to get there with the fewest possible DOM operations, and the browser has to do the least amount of expensive work.

It's like the difference between giving someone directions one turn at a time ("turn left, now turn right, now go straight...") versus handing them a full route upfront so they can optimize the path themselves.

There's also a developer experience benefit here. You write declarative code ("here's what the UI should look like") instead of imperative code ("do this, then that, then this"). React handles the imperative DOM manipulation internally so you don't have to think about it.

The Full React Update Lifecycle

Let's put the entire thing together in one clean mental model. Every update in React goes through three phases:

Render Phase - React calls your component functions and builds the new Virtual DOM tree. This is pure JavaScript computation, nothing touches the browser yet. React can pause, abort, or restart this phase if needed.

Diff Phase - React compares the new Virtual DOM tree against the previous one (reconciliation). It walks the two trees and builds a list of changes. Still no Real DOM involvement.

Commit Phase - React takes the list of changes and applies them to the Real DOM all at once. This is the only point where the browser gets involved. After this, effects like useEffect run.

Putting It All Together

Here's the simplest way to think about it. The Real DOM is like a physical whiteboard in an office. Erasing and redrawing stuff on it takes time and effort. The Virtual DOM is like a personal notebook. Writing in your notebook is fast, comparing two pages in your notebook is fast. Only once you know exactly what needs to change do you walk up to the whiteboard and make the minimum number of edits.

React is basically saying: let me do all the thinking in my notebook first, and I'll only bother the whiteboard when I know exactly what to write.

That's the entire mental model. Your components describe what the UI should look like. React keeps a copy of that description in memory as the Virtual DOM. When something changes, React builds a new description, compares it to the old one, finds the delta, and applies only that delta to the Real DOM. Fast, efficient, and you never have to think about DOM manipulation manually.

Once you internalize this flow, a lot of React's other behaviors start making more sense too. Why batching state updates matters. Why keys in lists are important. Why useMemo and React.memo exist. They're all tools that work with or optimize different parts of this same pipeline.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

SATYA SOOTAR — Sun, 10 May 2026 14:15:37 +0000

Hello readers 👋, welcome to the 15th blog in our Node.js series!

In our previous posts, we built a REST API, learned how to protect routes with JWT, and explored middleware and file uploads. Authentication has come up several times, but today we’re going to take a step back and look at the bigger picture. We’ll compare three pillars of authentication in web applications: sessions, JSON Web Tokens (JWT), and cookies.

If you’ve ever been confused about when to use a session-based login, when to reach for a JWT, or where cookies fit into all this, this post will clear things up. We’ll keep it practical, avoid deep security rabbit holes, and end with a decision framework you can apply to your next project.

Let’s get started.

What are cookies?

Cookies are small pieces of data stored on the client (browser) by the server via the Set-Cookie header. They are automatically sent back to the server with every subsequent request to the same domain. That’s their superpower: they travel with every request without the client having to do anything extra.

A cookie looks something like this:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict

The browser then dutifully sends Cookie: sessionId=abc123 with each request.

Cookies alone are not an authentication method; they are a transport mechanism. They can carry a session ID, a JWT, or just a simple preference. But because sessions almost always rely on cookies, the two are often mentioned together.

Key properties you can set on cookies:

HttpOnly – the cookie cannot be accessed via JavaScript (document.cookie), which helps prevent XSS attacks.
Secure – the cookie is only sent over HTTPS.
SameSite – controls whether the cookie is sent on cross‑site requests, mitigating CSRF.

In a traditional session‑based authentication, the server sets a cookie containing a unique session ID, and all further requests carry that cookie to identify the user.

What are sessions?

Session‑based authentication is the classic approach. After the user logs in with valid credentials, the server creates a session – a record in a database, in‑memory store, or cache (like Redis) that contains the user’s identity and any other relevant data. The server then sends back a cookie holding only the session ID.

Every subsequent request comes with that cookie. The server reads the session ID, looks up the session data (often from a store), and knows who the user is without them sending the password again.

Let’s see a simplified Express example using express-session:

const session = require('express-session');

app.use(session({
  secret: 'your-secret-key',
  resave: false,
  saveUninitialized: true,
  cookie: { secure: true, httpOnly: true, maxAge: 3600000 } // 1 hour
}));

app.post('/login', (req, res) => {
  // authenticate user
  req.session.userId = user.id; // stored on server
  res.send('Logged in');
});

app.get('/dashboard', (req, res) => {
  if (!req.session.userId) return res.status(401).send('Unauthorized');
  // fetch user data using session.userId
  res.send(`Hello user ${req.session.userId}`);
});

Sessions are stateful: the server must maintain a session store (memory, database, Redis). When you scale to multiple server instances, the session store must be shared, which adds complexity.

What are JWT tokens?

JSON Web Tokens (JWT) are a stateless authentication method. After a successful login, the server generates a token containing a payload (like the user’s ID and role) and signs it with a secret key. The token is sent to the client, which stores it. For each subsequent request, the client sends the token, usually in the Authorization header as a Bearer token, or sometimes in an HttpOnly cookie. The server verifies the signature, extracts the payload, and trusts that the user is who the token claims.

We’ve already implemented JWT authentication in an earlier blog. Here’s a quick recap:

const jwt = require('jsonwebtoken');

app.post('/login', (req, res) => {
  // authenticate user
  const token = jwt.sign({ userId: user.id }, 'secret', { expiresIn: '1h' });
  res.json({ token });
});

app.get('/profile', (req, res) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).send('No token');
  try {
    const decoded = jwt.verify(token, 'secret');
    req.user = decoded;
    res.send(`Profile of user ${req.user.userId}`);
  } catch (err) {
    res.status(403).send('Invalid token');
  }
});

Because JWT contains all the info needed (in the payload), the server doesn’t need to look up a session. That’s the stateless magic.

Stateful vs stateless authentication

This is the key distinction.

Stateful (sessions): The server keeps track of authenticated users. Each request requires a session lookup. This works great for traditional multi‑page apps because scaling requires a shared session store. Logout is easy: just destroy the session on the server.
Stateless (JWT): The server doesn’t store anything. It trusts the token after verifying the signature. This makes horizontal scaling a breeze. Logout is trickier: since the server doesn’t remember the token, you can’t invalidate it without a blacklist (bringing back some state). Usually, you set short expiration and rely on the client removing the token.

Think of sessions as a coat-check ticket: you give the clerk your coat, get a ticket, and later hand the ticket back to retrieve your coat. The clerk (server) remembers you. JWT is like a digital passport: the passport says who you are, and the border official (server) verifies its authenticity without calling home. Both have their place.

Sessions vs JWT: detailed comparison

Feature	Session‑based	JWT
State	Stateful (server stores session data)	Stateless (server only verifies token)
Storage	Session ID stored in a cookie; session data stored server‑side (memory, DB, Redis)	Token stored client‑side: browser (localStorage, sessionStorage) or HttpOnly cookie; no server‑side storage
Scalability	Requires shared session store across instances (e.g., Redis)	Easy to scale horizontally; no server‑side data sharing needed
Logout	Server deletes session – immediate effect	No server‑side record; token can’t be invalidated instantly unless a blacklist is used. Short expiry & client removal are typical
Security typical risks	Session hijacking (if cookie stolen), CSRF (mitigated with SameSite, tokens)	Token theft (if stored in non‑HttpOnly cookie or localStorage), XSS (if accessible via JS), token size
Payload visibility	Server‑side, opaque to client	Payload is Base64‑encoded (not encrypted); everyone can read it, but signature ensures integrity. Never put secrets in payload
Typical use case	Traditional server‑rendered web apps, multi‑page apps, apps with centralized user management	APIs, single‑page applications (SPAs), mobile apps, microservices, third‑party integrations

Note that you can store a JWT inside an HttpOnly cookie, blending some benefits: you get automatic cookie sending (no need to attach header manually) and protection from XSS, while still being stateless. The choice of where to store the token is separate from the choice of session vs JWT.

When to use each method

Use sessions when:

You have a traditional server‑rendered application (EJS, Pug, etc.).
You need fine‑grained control over active session invalidation (e.g., force logout, revoke access instantly).
You’re comfortable managing a session store (or don’t mind the overhead for a simple app).
You want to keep sensitive data on the server.

Use JWT when:

You are building a REST API that serves multiple frontends (web, mobile, desktop).
You want to scale horizontally without worrying about a shared data store.
You need to pass authorization across multiple independent services (microservices).
Your client is a SPA where the frontend handles presentation and stores the token (e.g., in memory or localStorage, though HttpOnly cookie is safer).

A hybrid approach: store a short‑lived JWT inside an HttpOnly, Secure, SameSite cookie. That way you get automatic cookie handling, XSS protection, and still remain stateless on the server. This is increasingly popular in modern frameworks.

Conclusion

Sessions, cookies, and JWT aren’t mutually exclusive; they’re pieces of the authentication puzzle. Cookies transport data (session IDs or JWTs) seamlessly. Sessions give you server‑side control at the cost of state. JWT gives you stateless scalability at the cost of instant invalidation. Choosing between them depends on your application architecture, scalability needs, and security priorities.

To recap:

Cookies are a transport mechanism, automatically sent with every request, and can be secured with HttpOnly, Secure, and SameSite flags.
Sessions store user state on the server and use a cookie holding a session ID. They are stateful and great for traditional web apps.
JWT embeds user information in a signed token; the server doesn’t need a lookup. They are stateless and ideal for APIs, SPAs, and microservices.
The decision often hinges on stateful vs stateless needs and where you want to store sensitive data.

In the next post, we’ll start connecting Express to databases; building a full‑stack authentication flow with registration and login that persists real data. See you then!

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

URL Parameters vs Query Strings in Express.js

SATYA SOOTAR — Sun, 10 May 2026 14:09:37 +0000

Hello readers 👋, welcome to the 14th blog in our Node.js series!

In the last few posts, we built a complete file upload and serving system using Multer and Express. We learned how to accept files, store them safely, and serve them back via static URLs. Today, we're going to shift focus to something more subtle but equally important: how to extract information from the URL itself. Specifically, we'll talk about URL parameters and query strings in Express.js.

You see these every day: URLs like /users/42 or /search?q=express&sort=asc. Knowing when to use a parameter (the 42) versus a query string (the ?q=express) makes your API design cleaner and more intuitive. Let's break it all down with clear examples.

Let's get started.

What URL parameters are

URL parameters (also called route parameters) are segments of the URL path that act as placeholders. They are part of the path itself and are typically used to identify a specific resource. In Express, you define them with a colon (:) prefix in the route path, and Express captures their values into req.params.

Think of <name> as a placeholder for something like an ID, a username, or a category. The actual value appears in the URL after the previous segment.

Here's a basic route that uses a parameter:

const express = require('express');
const app = express();

app.get('/users/:userId', (req, res) => {
  const userId = req.params.userId;
  res.send(`User profile for ID: ${userId}`);
});

If you visit http://localhost:3000/users/123, req.params.userId will be "123". Notice that the parameter is part of the path. It's not optional; the route wouldn't match /users/ alone (without an ID).

You can have multiple parameters in a single route:

app.get('/posts/:postId/comments/:commentId', (req, res) => {
  const { postId, commentId } = req.params;
  res.json({ postId, commentId });
});

The values are always strings, so you may need to parse them into numbers if needed (parseInt). Express doesn't do any type conversion automatically.

What query strings (query parameters) are

Query strings are key-value pairs that come after a question mark (?) in a URL. They are used to send additional data that is often optional, like filters, sorting options, pagination, or search terms. They are not part of the route path itself. In Express, you access them via req.query.

For example, a search URL might look like this:

/search?q=express&page=2&limit=10

Here, q, page, and limit are query parameters. Express parses them and makes them available in req.query as an object.

Example route:

app.get('/search', (req, res) => {
  const query = req.query.q;
  const page = req.query.page || 1;
  const limit = req.query.limit || 10;
  res.json({ query, page, limit });
});

A request to /search?q=node&page=3 gives:

{ "query": "node", "page": "3", "limit": 10 }

Query strings are extremely flexible because they don't affect route matching directly; any number of them can be added to a URL without breaking the route pattern.

Differences between URL parameters and query strings

The core difference lies in their purpose and placement.

Aspect	URL Parameters (Route params)	Query Strings
Appearance in URL	Part of the path: `/users/42`	After `?` in the URL: `/users?role=admin`
Purpose	Identify a specific resource (required)	Provide additional instructions or filters (optional)
Route matching	Must be defined in route path with `:param`	Does not affect which route is matched
Express access	`req.params` (object)	`req.query` (object)
Typical use cases	Entity ID, username, category, blog post slug	Search, pagination, sorting, filtering, API keys
Order in URL	Fixed position in the path	Unordered, can be combined arbitrarily
Optionality	Usually required for the resource to make sense	Often optional with defaults

A good mental model: parameters point to a specific "noun" (the resource); query strings describe "how" or "what to do" with that resource, like filtering or sorting.

Accessing params in Express

As shown earlier, you define placeholders in the route string using :paramName. Then inside the handler, you read req.params. All values are strings.

If you need to make a parameter optional and still match the base route, you can use a ? after the parameter name (like :userId?), but then you'd need to handle the case where it's undefined. Alternatively, define two routes: one with and one without the parameter.

Here's an example of an optional parameter:

app.get('/articles/:year?/:month?', (req, res) => {
  const { year, month } = req.params;
  res.send(`Articles ${year ? 'for ' + year : ''} ${month ? '/' + month : ''}`);
});

But be careful, req.params will contain strings for whatever segments exist.

Accessing query strings in Express

Query strings don't need to be declared. Any key=value pair after the ? will appear in req.query. If a key appears multiple times (e.g., ?tag=js&tag=node), Express by default gives you an array (only if you use a certain parsing library; the built-in qs library parses arrays with repeated keys). So req.query.tag might be ['js', 'node'].

Example with arrays:

app.get('/items', (req, res) => {
  const tags = req.query.tags;
  // tags could be a string or an array if multiple
  const tagsArray = Array.isArray(tags) ? tags : [tags].filter(Boolean);
  res.json({ tags: tagsArray });
});

When to use params vs query: practical examples

User profile ID (use params)

You want to get a specific user by ID. The ID is the identifier of the resource, so it belongs in the path.

app.get('/users/:id', (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  if (!user) return res.status(404).json({ error: 'User not found' });
  res.json(user);
});

This makes the URL clean: /users/5. Without the ID, the route doesn't make sense. So a parameter is the right choice.

Search filters (use query strings)

You want to filter a list of products by category, price range, and sort order. None of these are "the resource identifier". They are optional, descriptive modifiers. So they go in the query string.

app.get('/products', (req, res) => {
  const { category, minPrice, sort } = req.query;
  let results = [...products];
  if (category) results = results.filter(p => p.category === category);
  if (minPrice) results = results.filter(p => p.price >= Number(minPrice));
  if (sort === 'asc') results.sort((a, b) => a.price - b.price);
  else if (sort === 'desc') results.sort((a, b) => b.price - a.price);
  res.json(results);
});

A request URL like /products?category=electronics&minPrice=100&sort=asc clearly communicates that we're viewing the products collection but with specific filters.

Mixed usage

Often, you'll combine both. For example, fetching comments for a specific post, with pagination:

GET /posts/:postId/comments?page=2&limit=10

Here, :postId identifies the post (required), while page and limit control how many comments are returned (optional with defaults).

Visualizing the URL structure

Every URL can be broken down into parts. Let's disassemble an example:

https://api.example.com/users/42?include=posts&limit=5

Protocol & domain: https://api.example.com
Path: /users/42
- Segment users (static)
- Segment 42 (dynamic, captured by :userId)
Query string: ?include=posts&limit=5
- include=posts
- limit=5

Express routes match against the path (ignoring the query string). So you'd define:

app.get('/users/:userId', (req, res) => { ... });

And then inside, req.params.userId gives "42", req.query.include gives "posts", and req.query.limit gives "5".

This separation allows the same route to respond differently based on what the client asks for, without defining countless different URL patterns.

Conclusion

Understanding URL parameters versus query strings is essential for designing clean, predictable REST APIs. URL parameters are used to identify a specific resource (like a user or a post) and appear as dynamic segments in the path. Query strings are used to modify the request, provide filters, pagination, or any optional data, and appear after the ? in the URL. Express makes both accessible with req.params and req.query.

Let's quickly recap:

URL parameters (:param) are parts of the path used for required resource identifiers. Accessed via req.params.
Query strings (?key=value) are optional key‑value pairs used for filtering, sorting, searching, and other modifiers. Accessed via req.query.
Route matching ignores query strings, so they are flexible and don't affect which handler runs.
Use parameters when the URL would be incomplete without that piece of data; use query strings for everything else that's optional or descriptive.
In Express, both are available as simple JavaScript objects, making it easy to extract and use them.

Armed with this understanding, your routes will become more intuitive and your APIs more predictable. See you in the next post!

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Storing Uploaded Files and Serving Them in Express

SATYA SOOTAR — Sun, 10 May 2026 14:05:18 +0000

Hello readers 👋, welcome to the 13th blog in our Node.js series!

In the last post, we learned how Multer helps us accept file uploads in Express, whether single files or multiple files. We configured a disk storage engine and saw how req.file and req.files give us all the details about what arrived. But one question remained unanswered: where do the uploaded files actually live, and how do clients get them back?

Today we're going to close that loop. We'll talk about storage choices, how to serve uploaded files so they're accessible via a URL, and crucial security practices that keep your application safe. By the end, you'll have a complete picture of the upload‑serve lifecycle.

Let's jump in.

Where uploaded files are stored

When Multer saves a file on the server, it places it into a folder that you specify via the destination callback. In our previous example, we used an uploads folder at the root of our project. After a few uploads, the folder might look something like this:

project/
├── uploads/
│   ├── avatar-1680000000-123456789.png
│   ├── avatar-1680000010-987654321.jpg
│   └── cover-1680000020-456789123.jpeg
├── server.js
└── package.json

The actual filenames are generated by the filename callback (often using a timestamp and a random number to avoid collisions). The original name is still available inside req.file.originalname, but on disk we keep a sanitized, unique name.

Local storage vs external storage concept

In development and small applications, storing files on the local filesystem is perfectly fine. It's simple and needs no extra setup. But as your application grows, you'll often hear about external storage services like Amazon S3, Google Cloud Storage, or Cloudinary. These services store files separately from your Node.js server, which brings several benefits:

Your server's disk space isn't used by user files.
The files can be served to clients directly from a CDN, reducing load on your application server.
Scaling becomes easier because the storage layer is independent.

For this post, we'll focus entirely on local storage because that's where most people start. We'll mention how to serve those local files directly to clients. Later, when you move to cloud storage, the ideas of URLs and security transfer easily.

Serving static files in Express

After a file is uploaded and stored on disk, you typically want to make it accessible through a URL so that a client (browser, mobile app) can download or display it. Express provides a built‑in middleware called express.static exactly for this purpose.

express.static takes a folder path and serves all files inside it as static assets. For example:

const express = require('express');
const app = express();

// Serve files from the 'uploads' folder at the '/files' URL path
app.use('/files', express.static('uploads'));

Now, if there is a file uploads/avatar-123456.png, it becomes available at http://localhost:3000/files/avatar-123456.png. The URL path you choose (/files) can be anything; it doesn't have to match the folder name.

A common practice is to serve the uploads folder under a dedicated path like /uploads or /files to keep the URL structure clear.

Setting up the complete flow

Let's combine Multer and static serving into a single Express app to see the full picture:

const express = require('express');
const multer = require('multer');
const path = require('path');
const fs = require('fs');

const app = express();
const port = 3000;

// Ensure uploads folder exists
const uploadsDir = path.join(__dirname, 'uploads');
if (!fs.existsSync(uploadsDir)) {
  fs.mkdirSync(uploadsDir);
}

// Multer configuration
const storage = multer.diskStorage({
  destination: (req, file, cb) => cb(null, 'uploads/'),
  filename: (req, file, cb) => {
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
    const ext = path.extname(file.originalname);
    cb(null, file.fieldname + '-' + uniqueSuffix + ext);
  }
});
const upload = multer({ storage });

// Serve uploaded files statically
app.use('/files', express.static('uploads'));

// Upload route
app.post('/upload', upload.single('photo'), (req, res) => {
  if (!req.file) {
    return res.status(400).json({ error: 'No file uploaded' });
  }
  // Build the public URL
  const fileUrl = `http://localhost:${port}/files/${req.file.filename}`;
  res.json({
    message: 'File uploaded successfully',
    url: fileUrl
  });
});

app.listen(port, () => console.log(`Server running on port ${port}`));

After uploading, the client receives a JSON response containing the direct URL. It can then use that URL to display an image, download a document, or simply check the file.

Accessing uploaded files via URL

The key insight is that the public URL is built from three parts:

Base URL of your server (e.g., http://localhost:3000)
Static serving path (e.g., /files)
Filename on disk (the unique name generated by Multer)

In the route handler, req.file.filename gives us the exact name stored on disk. Concatenating these pieces gives a valid URL that Express will serve from the uploads folder.

For a more production‑ready approach, you'd likely construct the URL from a configuration setting, not hardcode localhost. For example:

const baseUrl = process.env.BASE_URL || `http://localhost:${port}`;
const fileUrl = `${baseUrl}/files/${req.file.filename}`;

Now clients always get the correct URL regardless of the environment.

Security considerations for uploads

File uploads are powerful but also a potential attack vector if not handled carefully. Here are some essential safe‑handling practices that every developer should follow.

1. Limit allowed file types

Never accept arbitrary file types. Use Multer's fileFilter to check the MIME type or file extension before writing to disk. For example, if you expect images:

const upload = multer({
  storage,
  fileFilter: (req, file, cb) => {
    const allowedTypes = /jpeg|jpg|png|gif/;
    const mimeType = allowedTypes.test(file.mimetype);
    const extName = allowedTypes.test(path.extname(file.originalname).toLowerCase());
    if (mimeType && extName) {
      return cb(null, true);
    }
    cb(new Error('Only image files are allowed'));
  }
});

2. Restrict file size

You can set a limits object on the Multer instance to reject files that are too large:

const upload = multer({
  storage,
  limits: { fileSize: 5 * 1024 * 1024 } // 5 MB
});

This prevents someone from filling up your server's disk with a single request.

3. Rename files to avoid path traversal

Never trust the original filename directly in the storage path. Always generate a new name, as we did with the filename callback. Using Date.now() and a random number makes it nearly impossible for an attacker to guess the filename. Also avoid including user‑supplied strings in the path to prevent directory traversal attacks (e.g., ../../../etc/passwd).

4. Store uploaded files outside the public web root

If possible, keep the uploads folder outside the main Express static folder that is openly served. In our setup, we used /files explicitly, but the uploads folder itself is not automatically exposed except through that route. Still, it's a good idea to store uploads in a directory that is not directly under the static root, and then use express.static with an absolute path to serve it under a specific URL prefix. This prevents direct access via path guessing.

5. Do not execute uploaded files

Make sure your static file serving middleware only serves files with safe content types. For example, if someone uploads a .php or .js file and you serve it via express.static, a browser might try to interpret it as code, especially if served with the wrong Content-Type. Express/Node.js static middleware sends files with an appropriate MIME type based on the extension, which usually prevents execution. Still, it's wise to limit accepted extensions and avoid storing executable scripts in the uploads folder.

6. Scan for malware (advanced)

For high‑security applications, you can integrate virus scanning tools that inspect uploaded files before they're stored. This is beyond the scope of this post, but keep it in mind for production systems.

Conclusion

Storing and serving uploaded files completes the file upload puzzle. By using Multer's disk storage and Express's static middleware, you can quickly give your users the ability to upload content and retrieve it via clean URLs. Add a few security precautions, and you have a robust foundation that works for development and small production apps.

Let's quickly recap:

Uploaded files can be stored locally in a project folder (e.g., uploads/) or externally on cloud services for scalability.
express.static lets you serve the files under a URL prefix, making them accessible to clients.
Building a file URL combines the base URL, the static serving path, and the unique filename stored on disk.
Security is essential: limit file types and sizes, rename files, avoid executable files, and store uploads outside the main public root if possible.
A clear folder structure and the static middleware together create an intuitive upload‑serve flow.

Now you have the full cycle: receiving files and giving them back. In the next post, we'll explore something new, maybe working with databases or error handling. See you then!

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Handling File Uploads in Express with Multer

SATYA SOOTAR — Sun, 10 May 2026 14:00:30 +0000

Hello readers 👋, welcome to the 12th blog in our Node.js series!

In the last post, we learned how Express simplifies route handling and request processing. Today, we're going to tackle a common real‑world requirement that every backend developer faces: handling file uploads. Whether it's a profile picture, a PDF invoice, or a batch of images, users need to send files to your server, and you need a clean way to receive and store them.

Express itself doesn't handle file uploads out of the box. That's where a specialized middleware called Multer comes in. We'll understand why file uploads need special handling, how Multer works, and then build practical examples for single and multiple file uploads. By the end, you'll be able to accept files, store them on disk, and serve them back to clients.

Let's jump right in.

Why file uploads need middleware

When a browser sends a file, it uses a special encoding called multipart/form-data. This encoding splits the request body into multiple parts, each representing a form field or a file. A regular JSON body parser like express.json() cannot parse multipart data. If you try, req.body will be empty, and the file data will be lost.

To handle multipart/form-data, we need a parser that knows how to extract files from the request stream and make them available to our code. Multer is precisely that parser.

What Multer is

Multer is a Node.js middleware for handling multipart/form-data, which is primarily used for uploading files. It is designed to work with Express and sits as a middleware in the request pipeline. When a request with a file arrives, Multer processes the incoming stream, saves the file(s) to a location you specify (disk or memory), and attaches a file (or files) object to the req object. The rest of your route handler can then access the file details.

Multer adds a file or files property to the request object. A single file upload sets req.file, while multiple files set req.files (an array or an object, depending on configuration). Each file object contains fields like originalname, mimetype, size, and path (if stored on disk).

The multipart/form-data concept simply

Imagine you want to mail a letter along with a small gift. You can't just stuff the gift into a regular envelope; you need a special package with compartments. Similarly, when a browser sends form data that includes a file, it can't just put everything into a single JSON object. It uses multipart/form-data, which creates boundaries (think of them as separators) that tell the server where each field or file begins and ends.

When you set enctype="multipart/form-data" on a form, the browser encodes the data using this format. Multer is the tool on the server side that understands these compartments and extracts the file from the correct part.

Setting up Multer

First, install Multer in your project:

npm install multer

Then, require it and configure a storage engine. We'll start with disk storage, which saves files directly to a folder on your server.

Minimal storage configuration

const multer = require('multer');

// Define where to store files and how to name them
const storage = multer.diskStorage({
  destination: function (req, file, cb) {
    // Specify the upload folder
    cb(null, 'uploads/');
  },
  filename: function (req, file, cb) {
    // Give the file a unique name, preserving the extension
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
    const extension = file.originalname.split('.').pop();
    cb(null, file.fieldname + '-' + uniqueSuffix + '.' + extension);
  }
});

const upload = multer({ storage: storage });

Here, multer.diskStorage lets you control the destination folder and filename. The callback cb is used to pass the final path or error. We generate a semi‑unique filename to avoid collisions.

Handling a single file upload

Let's create an Express route that accepts a single file, for example, a profile picture. The client sends the file under a field name, say avatar.

const express = require('express');
const app = express();
const port = 3000;

// Ensure the "uploads" folder exists, or Multer will error
const fs = require('fs');
const path = require('path');
const uploadsDir = path.join(__dirname, 'uploads');
if (!fs.existsSync(uploadsDir)){
    fs.mkdirSync(uploadsDir);
}

// Single file upload middleware
app.post('/profile', upload.single('avatar'), (req, res) => {
  // req.file contains information about the uploaded file
  if (!req.file) {
    return res.status(400).json({ message: 'No file uploaded' });
  }
  console.log(req.file);
  res.json({
    message: 'File uploaded successfully',
    file: {
      originalName: req.file.originalname,
      size: req.file.size,
      path: req.file.path
    }
  });
});

app.listen(port, () => console.log(`Server running on port ${port}`));

upload.single('avatar') is the Multer middleware. It expects the file to be sent in the form field named avatar. After successful upload, req.file contains:

fieldname – the name of the form field
originalname – the original name on the user's computer
mimetype – e.g., image/png
size – file size in bytes
destination – the folder where the file was saved
filename – the generated filename on disk
path – the full path to the uploaded file

Handling multiple file uploads

Multer provides several ways to accept multiple files.

1. Multiple files with the same field name (array of files)

Use upload.array('photos', 5) to accept up to 5 files in the field photos.

app.post('/gallery', upload.array('photos', 5), (req, res) => {
  if (!req.files || req.files.length === 0) {
    return res.status(400).json({ message: 'No files uploaded' });
  }
  const fileDetails = req.files.map(f => ({
    name: f.originalname,
    size: f.size
  }));
  res.json({ message: 'Files uploaded', files: fileDetails });
});

req.files is an array of file objects, each similar to req.file.

2. Multiple fields with different names

Use upload.fields([...]) when you have several distinct file fields, like avatar and cover.

const cpUpload = upload.fields([
  { name: 'avatar', maxCount: 1 },
  { name: 'cover', maxCount: 1 }
]);

app.post('/complete-profile', cpUpload, (req, res) => {
  // req.files is an object with keys 'avatar' and 'cover', each an array of files
  const avatar = req.files['avatar'] ? req.files['avatar'][0] : null;
  const cover = req.files['cover'] ? req.files['cover'][0] : null;
  res.json({ avatar: avatar?.originalname, cover: cover?.originalname });
});

Serving uploaded files

After uploading, you often need to serve the files back to the client (e.g., to display an image). Express has a built‑in middleware express.static for serving static files from a directory.

// Serve files from the 'uploads' folder at the '/files' URL path
app.use('/files', express.static(path.join(__dirname, 'uploads')));

Now, if a file was saved as uploads/avatar-123456789.png, the client can access it at http://localhost:3000/files/avatar-123456789.png. You can use the relative path to build the URL.

Visualizing the upload flow

Client → Server → Storage flow:

Client (browser)
  │
  ├── Sends POST /profile with multipart/form-data (file in field "avatar")
  │
  ▼
Express Server
  │
  ├── Multer middleware (upload.single('avatar'))
  │     ├── Parses multipart data
  │     ├── Streams file to disk (or memory)
  │     └── Attaches req.file
  │
  ▼
Route Handler
  │
  ├── Accesses req.file details
  ├── Saves metadata to database (if needed)
  └── Sends response (e.g., file URL)

Multer middleware execution:

Request
  │
  ▼
Multer middleware (configured with storage engine)
  │
  ├── Read stream → Identify boundaries
  │
  ├── For each file field:
  │     ├── Extract filename, MIME type
  │     ├── Call storage._handleFile (disk or memory)
  │     │     └── Write to disk / buffer
  │     └── Emit 'file' event or push to array
  │
  ├── Calls next() when all fields and files processed
  │
  ▼
Next middleware / route handler (receives req.file or req.files)

That summarizes the lifecycle.

Conclusion

Multer makes handling file uploads in Express straightforward. By plugging it as a middleware, you can accept single or multiple files, control where they are saved, and then serve them back easily. Understanding multipart/form-data and Multer's role is key to building applications that accept user‑generated content.

Let's quickly recap:

File uploads use multipart/form-data; regular body parsers can't handle them.
Multer is an Express middleware that parses multipart data and gives you req.file or req.files.
Configure storage using multer.diskStorage to define destination and filename.
upload.single(), upload.array(), and upload.fields() cover most use cases.
Serve uploaded files with express.static for easy access.
The upload lifecycle flows from client to Multer to disk, then to your route handler.

Now you can confidently add file upload capabilities to your Node.js APIs. In the next post, we might explore error handling in Multer or move on to database integration. See you then!

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

Creating Routes and Handling Requests with Express

SATYA SOOTAR — Sun, 10 May 2026 13:52:33 +0000

Hello readers 👋, welcome to the 11th blog in our Node.js series!

We've come a long way. We started by setting up Node.js, understood its event loop, explored blocking vs non‑blocking code, handled async operations with promises, secured routes with JWT, designed a REST API, and even dove into middleware. But to build those APIs and middleware, we used Express.js. Now it's time to shine a focused light on exactly how Express helps us create routes and handle requests so effortlessly.

In this post, we'll take a step back and talk about what Express.js is, why it makes Node.js development so much smoother, and how to create clean, readable routes for GET and POST requests. By the end, you'll see why Express has become the go‑to framework for building web servers with Node.js.

Let's jump in.

What is Express.js?

Express.js is a minimal and flexible web application framework for Node.js. It provides a thin layer of fundamental web application features, without obscuring Node.js features that you know and love. In simpler words, it's a set of tools that makes it ridiculously easy to handle HTTP requests, define routes, work with middleware, and send responses.

At its core, Express is just a function that returns an application object. You attach route handlers to it, and it efficiently maps incoming requests to the right handlers.

Why Express simplifies Node.js development

To appreciate Express, let's quickly compare it with building an HTTP server using Node.js's built‑in http module.

Raw Node.js HTTP server example:

const http = require('http');

const server = http.createServer((req, res) => {
  if (req.method === 'GET' && req.url === '/users') {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify([{ id: 1, name: 'Satya' }]));
  } else if (req.method === 'GET' && req.url.startsWith('/users/')) {
    const id = req.url.split('/')[2];
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ id, name: 'Satya' }));
  } else if (req.method === 'POST' && req.url === '/users') {
    let body = '';
    req.on('data', chunk => body += chunk);
    req.on('end', () => {
      const user = JSON.parse(body);
      res.writeHead(201, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(user));
    });
  } else {
    res.writeHead(404);
    res.end('Not found');
  }
});

server.listen(3000);

That works, but as your application grows, the code becomes a mess of if‑else statements, manual body parsing, and repetitive header writing.

Now look at the same logic with Express:

const express = require('express');
const app = express();
app.use(express.json());

app.get('/users', (req, res) => {
  res.json([{ id: 1, name: 'Satya' }]);
});

app.get('/users/:id', (req, res) => {
  const id = req.params.id;
  res.json({ id, name: 'Satya' });
});

app.post('/users', (req, res) => {
  const user = req.body;
  res.status(201).json(user);
});

app.listen(3000);

Here's what Express gives you:

Clean routing: You directly map HTTP methods and URL patterns to handler functions. No need to manually parse req.url or check req.method.
Automatic body parsing: With express.json() middleware, the body is parsed and available at req.body.
Easy response helpers: res.json() automatically sets the content type and stringifies the object.
Route parameters: Express extracts :id from the URL and places it in req.params.
Middleware support: You can chain functions (like we explored in the previous blog) to handle logging, auth, validation.

Express takes away the boilerplate so you can focus on your application logic.

Creating your first Express server

Let's start from zero. First, initialize a project and install Express:

npm init -y
npm install express

Then create a file, say server.js:

const express = require('express');
const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
  res.send('Hello from Express!');
});

app.listen(PORT, () => {
  console.log(`Server is running on http://localhost:${PORT}`);
});

Run it with node server.js, and open http://localhost:3000. You'll see the greeting. This is the absolute minimal Express server.

Handling GET requests

GET requests are used to fetch data. Express makes it very intuitive.

1. Simple GET route

app.get('/hello', (req, res) => {
  res.send('Hello World');
});

2. Using route parameters

app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  res.send(`User ID: ${userId}`);
});

A request to /users/42 returns User ID: 42. Express automatically parses the :id segment.

3. Query string parameters

app.get('/search', (req, res) => {
  const query = req.query.q;
  const page = req.query.page || 1;
  res.json({ query, page });
});

A request to /search?q=express&page=2 gives { "query": "express", "page": "2" }.

4. Returning JSON data

app.get('/api/users', (req, res) => {
  const users = [
    { id: 1, name: 'Satya' },
    { id: 2, name: 'Priya' }
  ];
  res.json(users); // sets Content-Type to application/json automatically
});

res.json() is the go‑to for API responses.

Handling POST requests

POST requests typically create new resources. To process them, you need to read the request body. Express's built-in middleware express.json() does exactly that.

app.use(express.json()); // parse JSON bodies

app.post('/api/users', (req, res) => {
  const { name, email } = req.body;
  // In a real app, you'd save to a database
  const newUser = { id: Date.now(), name, email };
  res.status(201).json(newUser);
});

Test it with a client that sends JSON:

{
  "name": "Rahul",
  "email": "rahul@example.com"
}

The response will be 201 Created with the new user object.

You can also handle form submissions using express.urlencoded({ extended: true }) if you're dealing with traditional HTML forms.

Sending responses

Express provides multiple methods to send responses, each suitable for different scenarios:

res.send(string) – sends a plain text or HTML string; sets Content-Type accordingly.
res.json(object) – sends a JSON object with proper header.
res.status(code).json(object) – sets the status code and sends JSON.
res.sendFile(path) – streams a file from disk.
res.redirect(url) – redirects to another URL.
res.download(path) – prompts the browser to download a file.

You can also chain status codes: res.status(404).send('Not Found').

Example:

app.get('/file', (req, res) => {
  res.sendFile(__dirname + '/sample.pdf');
});

Express is flexible and doesn't force one way of responding.

Conclusion

Express.js strips away the repetitive plumbing of raw Node.js HTTP servers and lets you define routes declaratively, making your code cleaner and faster to write. With just a few lines, you can set up a server, handle GET and POST requests, parse inputs, and send proper responses. This is the foundation of every Node.js backend I've built.

Let's recap:

Express is a minimal framework that simplifies creating HTTP servers in Node.js.
It offers clean routing with methods like app.get, app.post, app.put, etc.
Route parameters (req.params), query strings (req.query), and body parsing (req.body) are built in.
Response helpers (res.json, res.send, res.status) make sending data back straightforward.
Compared to raw Node, Express eliminates boilerplate and reduces developer friction.

Now that you're comfortable with routes and request handling, the next step is to build more complex applications, connect to databases, and structure larger codebases. We'll continue that journey in the next post.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

What is Middleware in Express and How It Works

SATYA SOOTAR — Sun, 10 May 2026 13:50:59 +0000

Hello readers 👋, welcome to the 10th blog in our Node.js series!

In the last post, we built a clean REST API using Express.js for a users resource. We defined routes and handled different HTTP methods. Today, we are going to explore a concept that sits quietly at the heart of every Express application: middleware.

If you have ever wanted to log every request, check authentication tokens, or validate incoming data before it hits your route handler, you have needed middleware. Let's understand what middleware is, how it fits into the request lifecycle, the different types, and how to chain multiple middleware to build powerful, reusable pipelines.

Let's get started.

What middleware is in Express

Middleware, in Express, are functions that have access to the request object (req), the response object (res), and the next middleware function in the application's request-response cycle. The next middleware function is conventionally denoted by a variable named next.

Think of middleware as a series of checkpoints or processing stations that every incoming request passes through before reaching the final route handler. At each checkpoint, you can:

Inspect or modify the request (e.g., add properties, parse the body).
Perform some logic (e.g., log the request time, check authentication).
Send an early response (e.g., return an error if the user is not authenticated) and stop the chain.
Call next() to pass control to the next middleware in line.

Middleware functions are executed in the order they are defined. That order is crucial and we'll explore it soon.

Where middleware sits in the request lifecycle

In a typical Express app, an incoming HTTP request flows through a pipeline:

The request arrives at the server.
It passes through each middleware function registered (both application-level and router-level) in the order they were added.
Finally, it reaches the route handler that matches the path and method.
The route handler sends a response.
If no middleware or route sends a response, the request hangs; Express doesn't automatically respond.

The middleware chain can be visualized as:

Request → [Middleware 1] → [Middleware 2] → [Route Handler] → Response

Each arrow is a next() call. If a middleware function does not call next(), the request stalls and never reaches the next middleware or route handler (unless you send a response and end the request). This pipeline concept is the backbone of Express.

The role of `next()`

The next function is a callback that tells Express "I'm done, move on to the next middleware or route handler." If the currently executing middleware function does not end the request-response cycle, it must call next().

There are two important variations:

next() – proceed to the next middleware in the stack.
next('route') – skip to the next route handler (only works in router-level middleware).

If you pass an error to next(err), Express skips all remaining non-error middleware and goes directly to an error-handling middleware, which has four parameters: (err, req, res, next). We'll keep error handling middleware for another post.

Application-level middleware

Application-level middleware are bound to an instance of the app object using app.use() or app.METHOD(). They run for every request (if no path is specified) or for requests that match a specific path prefix.

Example: logging middleware for every request

const express = require('express');
const app = express();

// Application-level middleware (no path, runs on every request)
app.use((req, res, next) => {
  console.log(`${req.method} ${req.url} - ${new Date().toISOString()}`);
  next();
});

Here, we log the HTTP method, URL, and timestamp for every request. We then call next() so the request continues down the pipeline.

Example: middleware for a specific path

You can limit middleware to a path prefix:

app.use('/admin', (req, res, next) => {
  console.log('Admin route accessed');
  next();
});

Middleware added this way will run for any route starting with /admin.

Router-level middleware

Router-level middleware works exactly like application-level middleware, except it is bound to an instance of express.Router(). It's used to organize route-specific middleware, especially when you have modular route files.

const router = express.Router();

// Router-level middleware: runs for every request handled by this router
router.use((req, res, next) => {
  console.log('Inside user router');
  next();
});

router.get('/profile', (req, res) => {
  res.send('User profile');
});

app.use('/users', router);

Now, any request starting with /users will first go through the router-level middleware before hitting the specific route handler.

Built-in middleware

Express has some built-in middleware functions that solve common tasks. You've already seen one: express.json(). These are middleware functions that come with Express and are used via app.use().

express.json() – parses incoming JSON payloads and populates req.body.
express.urlencoded({ extended: true }) – parses URL-encoded payloads (from HTML forms).
express.static('public') – serves static files (images, CSS, JS) from a directory.

Example:

app.use(express.json());
app.use(express.static('public'));

These are middleware too! They process the request and call next() for the next piece in the pipeline.

Execution order of middleware

The order in which you declare middleware matters immensely. Express executes them sequentially, top to bottom. If you place a middleware that sends a response before your route handler, the route handler will never run.

Consider this incorrect example:

app.use((req, res, next) => {
  res.send('This ends the request');
  next(); // This will still be called but no further middleware can modify the response after send
});
app.get('/', (req, res) => {
  res.send('Hello world');
});

Here, the first middleware sends a response, and unless you call next() before send(), the get handler never sees the request. More importantly, even if you call next() after send(), Express will not allow you to send another response; you'd get an error because headers are already sent. So, typically you either call next() without sending a response, or you end the request inside the middleware.

The correct pattern:

app.use((req, res, next) => {
  console.log('Logging');
  next(); // pass control
});

app.use((req, res, next) => {
  // maybe add timestamp to req
  req.requestTime = Date.now();
  next();
});

app.get('/', (req, res) => {
  res.send(`Hello world, request at ${req.requestTime}`);
});

Each middleware adds something and passes control. The route handler runs at the end.

Real-world examples

Let's see three practical middleware: logging, authentication, and request validation.

Logging middleware

You've already seen a basic logger. Let's write a slightly cleaner one:

function logger(req, res, next) {
  const start = Date.now();
  res.on('finish', () => {
    const duration = Date.now() - start;
    console.log(`${req.method} ${req.originalUrl} ${res.statusCode} - ${duration}ms`);
  });
  next();
}
app.use(logger);

This logs the method, URL, status code, and response time. It uses the finish event on the response to know when the response is sent.

Authentication middleware

This one checks for a valid JWT token (similar to our earlier JWT blog). If invalid, it stops the request with a 401 error. Otherwise, it attaches the user and continues.

function authenticate(req, res, next) {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];
  if (!token) {
    return res.status(401).json({ message: 'Access token missing' });
  }
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    next();
  } catch (err) {
    return res.status(403).json({ message: 'Invalid token' });
  }
}
// Protect a route
app.get('/profile', authenticate, (req, res) => {
  res.send(`User profile for ${req.user.userId}`);
});

Notice how the middleware stops the request (by returning a response) when authentication fails, so the route handler never executes.

Request validation middleware

You can validate input before it reaches business logic. This keeps your route handlers clean. Here's a simple one for creating a user:

function validateUserInput(req, res, next) {
  const { name, email } = req.body;
  if (!name || !email) {
    return res.status(400).json({ message: 'Name and email are required' });
  }
  if (typeof email !== 'string' || !email.includes('@')) {
    return res.status(400).json({ message: 'Invalid email' });
  }
  next();
}

app.post('/users', validateUserInput, (req, res) => {
  // create user logic...
});

When validation fails, we respond immediately with 400 Bad Request. Otherwise, next() passes control to the actual handler. This separation improves readability and reusability.

Middleware pipeline

Imagine a physical pipeline with several inspection stations. A request arrives, gets stamped at the logging station, then passes through a security gate (authentication), then a quality check (validation), and finally reaches the desired destination (route handler). At any point, if it fails inspection, it gets turned away with a response.

Conclusion

Middleware is one of those concepts that, once you understand it, Express becomes transparent. It's just a sequence of functions that have access to req and res and can either pass the request along with next() or end the cycle by sending a response. By chaining middleware, you can separate concerns like logging, authentication, and validation, making your code cleaner and more maintainable.

Let's quickly recap:

Middleware functions sit between the incoming request and the final route handler.
They can modify the request/response, run code, or end the request early.
The next() function passes control to the next middleware in the stack; without it, the request stalls.
Application-level middleware (app.use()) runs for all requests or a specific path.
Router-level middleware (router.use()) works for a specific router.
Built-in middleware like express.json() are just prepackaged middleware.
Execution order is top-to-bottom, so declare middleware before routes they should affect.
Real-world uses include logging, authentication, and input validation, which keep route handlers focused.

Now that you understand middleware, you can structure Express apps that are modular, secure, and easy to scale. In the next post, we'll continue building more practical features. See you there!

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

DEV Community: SATYA SOOTAR

How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router

The Myth of the Simple Folder Structure

A Better Way: The Feature-Based Architecture

Expo Router: The Architect's Best Friend

Building the Core Systems: A Four-Part Deep Dive

1. Instagram: The Infinite Feed

2. WhatsApp: Real-time Messaging with Offline-First Support

3. Uber: Maps and Live Location Tracking

4. Netflix: Heavy Content Delivery

Putting It All Together: The Production-Grade Starter

Navigating the Waters: Authentication Flows and Shared Layouts

The Unseen Hero: The API and Networking Layer

Wrapping Up: It's About Engineering Mindset

Expo Router vs React Navigation: Which One Should You Use in 2026?

First, What Does "Routing" Even Mean in a Mobile App?

Why Navigation Is Such a Big Deal in React Native

The Story of React Navigation

The Problems Developers Were Hitting

Enter Expo Router: Why It Was Built

File-Based Routing Explained Simply

Layouts and Nested Layouts in Expo Router

Protected Routes and Auth Flows

Performance: Let's Be Honest About What Actually Matters

Developer Experience: The Real Comparison

Scalability for Large Applications

Real-World App Folder Structure

What Companies and Teams Are Actually Choosing

When NOT to Use Expo Router

When React Navigation Still Makes More Sense

Putting It All Together

How Instagram Stores Reels, Photos, and Drafts Behind the Scenes

Why Social Media Apps Need a Special Approach to Media Storage

The Journey Begins: Recording a Reel on Your Device

What Happens When You Save a Draft

Local Storage vs Cloud Storage: Two Very Different Jobs

The Upload Pipeline: What Actually Happens When You Hit "Share"

Media Processing and Compression: Making Videos Work for Everyone

Thumbnail Generation and Previews

Caching: Why Your Feed Loads So Fast on Reopen

Content Delivery Networks: How Your Reel Reaches Someone in Japan

Managing the Whole System: Storage, Performance, and User Experience

Putting It All Together

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

Why Messaging Apps Need Offline Support

What Actually Happens When You Hit Send Without Internet

Local Storage and Message Persistence

The Message Queue: Your Phone's Outbox

Syncing When You Come Back Online

Delivery States: What Those Ticks Actually Mean

Handling Media While Offline

Conflict Resolution and Message Ordering

Reliability vs Real-Time: The Tradeoff

Why Offline-First Makes the Experience Feel Smooth

Putting It All Together

I Spent a Weekend Hunting Through Linux's File System and Here's What I Found

Before We Start: The Map You Need

1: /etc/passwd Was Never Really About Passwords

2: /etc/shadow Is Where the Real Secrets Live

3: /etc/hosts Is the Original DNS

4: /etc/resolv.conf Is Your Gateway to the Internet

5: /proc Is Not a Real Directory

6: /proc/[PID] Lets You Inspect Any Running Process

7: /proc/net/route Shows Your Routing Table as a File

8: /dev/null, /dev/zero, and /dev/urandom Are Not Real Files Either

9: /etc/fstab Decides What Gets Mounted at Boot

10: /etc/systemd/system/ Is Where Services Live

11: /var/log/auth.log Is a Security Timeline

12: /etc/sudoers Controls Who Can Do What as Root

The Bigger Picture

How React's Virtual DOM Works Under the Hood

First, Let's Talk About the Real Problem

Enter the Virtual DOM

The Initial Render: How It All Starts

Now Something Changes: State or Props Update

Diffing: How React Compares Two Trees

Minimal Updates: Updating Only What Changed

Why This Actually Improves Performance

The Full React Update Lifecycle

Putting It All Together

1: `/etc/passwd` Was Never Really About Passwords

2: `/etc/shadow` Is Where the Real Secrets Live

3: `/etc/hosts` Is the Original DNS

4: `/etc/resolv.conf` Is Your Gateway to the Internet

5: `/proc` Is Not a Real Directory

6: `/proc/[PID]` Lets You Inspect Any Running Process

7: `/proc/net/route` Shows Your Routing Table as a File

8: `/dev/null`, `/dev/zero`, and `/dev/urandom` Are Not Real Files Either

9: `/etc/fstab` Decides What Gets Mounted at Boot

10: `/etc/systemd/system/` Is Where Services Live

11: `/var/log/auth.log` Is a Security Timeline

12: `/etc/sudoers` Controls Who Can Do What as Root

The role of `next()`