Frontend Development


# Debugging Next.js Application in Production

<a href="https://nextjs.org">Next.js</a> is an open-source development framework built on top of node.js enabling React-based web applications functionalities such as server-side rendering and generating static websites.
Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling, route prefetching, and more. No config is needed. – From nextjs.org
Debugging a bug in production can be a nightmare especially if the bug is reproducible only in the production environment. This could happen for several reasons like not having all the data on a local/stage environment or setting up a backend server can seem complex & time-consuming if you are a frontend developer.
So In this article, we will see how we can debug a Next.js application in production without even setting up a local server or trying to reproduce the bug on local or any other environment.

## Bug(s) in production NextJS app

We’ll take a simple Todo NextJS App available here - https://github.com/requestly/sample-nextjs-app

which is also live at: https://sample-nextjs-app-flax.vercel.app/

![To Do App](/assets/blog-images/to-do-app.png)

So for our case, there is a Next.JS basic to-do app that adds and fetches a list of tasks from the backend and when the user clicks on complete, the task gets deleted from the server.
In our application setup, we have a server and a frontend application built using Next.Js

Also in Next.Js, when we build our application:
If we see our production build so our index page component is compiled as static/chunks/pages/index-b1a6b3cf2be8bc12f539.js
Let’s take a look at our \_buildManifest.js

```
"/": ["static/chunks/pages/index-b1a6b3cf2be8bc12f539.js"],
```

Our about.html has the following scripts imported:

```
<script src="_next/static/chunks/pages/index-b1a6b3cf2be8bc12f539.js" defer=""></script>
```

#### So there is a hash generated along with the filename, the hash will change whenever we rebuild your application.

Now, we have a hypothetical situation where clicking on submit while adding a task I am getting an error in production, only the total tasks count gets updated but the task is not created.

## Debugging Backend APIs

If I have to debug this on a local setup, I need to set up the frontend and backend server locally too because my UI code by default hits the server on `/create` and `/delete` and it is too cumbersome to set server along with frontend and debug for a quick find.
So let’s talk about an approach using the Requestly browser extension using which you can debug your app without setting up your server on local machine.

### About Requestly

Requestly is a Chrome extension that lets you modify network requests like Modify Request & Response Headers, Redirect URLs, Switch Hosts, Mock API Response, Delay Network requests, Insert Custom Scripts, and much more. This is widely used by developers on daily basis because of the features it provides and it makes things simpler.

### Solution

Using the Requestly Redirect feature, we can redirect our script(s) from Production to localhost. In layman terms, when the browser loads the app then instead of loading the JS from production, requestly picks the JS from localhost. Now, we can add some more logic that can help us debug the issue. And once, we find the issue we can fix in our local script, test it on the production site and then deploy it with confidence.

![Redirect Prod to local using Requestly](/assets/blog-images/redirectRule.png)

## Setting up Requestly Redirect Rule (Step by Step Guide)

### Step1 — Install Requestly Extension

Go to <a href="https://requestly.io">https://requestly.io</a> and set up the extension for the browser of your choice.

### Step2 — Setup Redirect Rule

We will create a redirect rule through which we will use our production server capability on our local machine for debugging.

- Redirect Rule Set Up for Create Route

![Redirect Rule Setup](/assets/blog-images/redirect-rule-for-create.png)

Through this, we have successfully redirected our local server routes to the production server.
And when I debugged I found an issue with my UI code itself, that in the request all the required fields were not getting passed as the params. So it was a quick solution and setting up rules saved a lot of time.

## Debugging JS Code on Production

Just like in the previous example, we have set up redirects for routing an API endpoint from the production server to the local server, we will use a similar technique to redirect the JS hosted on production to my local JS. However, there is a slight complexity when it comes to JS mentioned earlier, every resource in the next.js project gets a unique file hash when the application is built. For example, In the following script resource

```
https://sample-nextjs-app-flax.vercel.app/_next/static/chunks/pages/index-b1a6b3cf2be8bc12f539.js

```

`index-b1a6b3cf2be8bc12f539.js` is the unique file hash. This is variable and Requestly provides very good support to handle variables in the URL.
Handling file hashes in the URL

We can use Requestly WildCard or Regex Match Operator to handle the file hash So our Rule will simply become

Request URL “WildCard Matches” `https://sample-nextjs-app-flax.vercel.app/_next/static/chunks/pages/index-*.js`

Destination - `https://localhost:3000/_next/static/chunks/pages/index.js`

### Requestly Redirect Rule (Redirect Production JS to localhost JS)

![Redirect Production JS to localhost JS](/assets/blog-images/js-redirect-rule.png)

So, We just saw how you can configure Requestly to gain complete control over your network traffic. This is a very powerful technique and saves a lot of time. Whether you are a backend developer or frontend developer, Requestly is now in every developer’s toolkit.

Happy Debugging! By <a href="https://linkedin.com/in/govindgoel">@govindgoel</a>

#### For Reference:

More about Next.js: <a href="https://nextjs.org/">https://nextjs.org/</a>

Application: <a href="https://github.com/requestly/sample-nextjs-app">https://github.com/requestly/sample-nextjs-app</a>

Deployed Application: <a href="https://sample-nextjs-app-flax.vercel.app/">https://sample-nextjs-app-flax.vercel.app/</a>

Rules: <a href="https://app.requestly.io/rules/#sharedList/1639923388678-Next.Js-Debugging">https://app.requestly.io/rules/#sharedList/1639923388678-Next.Js-Debugging</a>



This article will take you through how to use [Requestly](https://requestly.io) to simulate fake 404, 500 response status codes and test your frontend app `without changing anything in your codebase`. There are two possible ways to solve this using Requestly:

- [Requestly Desktop App](/desktop) (1 step)
- [Requestly Chrome Extension](https://chrome.google.com/webstore/detail/requestly-modify-headers/mdnleldcmiljblolnjhpnblkcekpdkpa) (2 step)
  <br />
  <br />

# Using Desktop App

You can use any MITM proxy to intercept the request and simulate the status code. However, using [Requestly Desktop App](/desktop), it is possible in a single step.

### Steps

- Go to Rules Tab and Click on New Rule
- Select Modify Response
- Define the exact URL (or Pattern) and define the status code. That's it.

![Modify Response Status Code Rule](/assets/img/screenshots/desktop-app/modify-status-code.png)

Here's a step by step video [demo](https://youtu.be/nLcIZGmMAtQ) explaning same.

Download Requestly Desktop App from [here](/desktop)

# Using Browser Extension

[Requestly Browser Extension](https://chrome.google.com/webstore/detail/requestly-modify-headers/mdnleldcmiljblolnjhpnblkcekpdkpa) can simulate different status codes on an API by redirecting the actual API to a mock API using Requestly's `Redirect Rule`.

![Mock Server](/assets/blog-images/mock-server.png)

## Steps

### 1. Create a mock API using Requestly

Requestly has a Mock Server capability to create a Mock API response. Here are the steps to create one.

- Create a new mock API here- [https://app.requestly.io/mock-server/viewer/create](https://app.requestly.io/mock-server/viewer/create)
- Set the status code you want to simulate (404, 500 ...).
  ![Mock API sending 500 status code](/assets/blog-images/mock-500-status.png)

Example mock Simulating 500 status code- [https://app.requestly.io/mock/aIfQd7toGFUMCL0PZDrc](https://app.requestly.io/mock/aIfQd7toGFUMCL0PZDrc)

_Requestly mock server handles the [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) headers automatically so that the browser does not block the cross-origin requests._

### 2. Redirecting actual API endpoint to the Mock Server endpoint.

- Setup a [redirect rule](https://requestly.io/feature/redirect-url) to redirect the actual API to the requestly mock API.

![Redirect Blinkit Search API to a mock API simulating 404 status code](/assets/blog-images/blinkit-404.png)

Redirecting Blinkit Search API to a mock API simulating 404 status code

### 3. Removing Content-Security-Policy Headers

Sometimes redirection to mock API won’t work due to [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)- [connect-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src) directive, which restricts the URLs loaded using script interfaces.

You can use the [Requestly marketplace](https://app.requestly.io/marketplace) rule to bypass this, which has a prebuilt rule to remove the `content-security-policy` header. Thats it.

![Requestly Marketplace](/assets/blog-images/marketplace-cors.png)

Download Requestly browser extension from [here](https://chrome.google.com/webstore/detail/requestly-modify-headers/mdnleldcmiljblolnjhpnblkcekpdkpa)

I hope this empowers you to do robust testing of your frontend app/website by simulating different API behaviours.

Further Resources:

- [Simulating 500 when Tweeting](https://requestly.io/blog/simulating-500-status-code-in-create-tweet-api-on-twitter)
- [Simulating 404 on Blinkit Search](https://requestly.io/blog/simulating-404-status-code-in-blinkit-search-api)

Happy Debugging!

By [@nafees87n](https://www.linkedin.com/in/nafees87n/)



Nobody wants to see errors in their API. But they appear at times when least expected. The possible scenarios when an error pops up could be something is wrong with the request or some problem with the API. Whatever may be the cause, one thing is sure traffic would stop.

API crashes shouldn’t disrupt the user experience. Errors should be handled at the client-side so that the user knows that something is wrong and can move on from there.

In the development phase, the consumers of API won’t wait till the API is entirely built to start their development. In this scenario, they can mock server responses and begin their development. Testing the application for error responses is vital so that user traffic is not blocked.

A QA tester or Product manager would want to mock various error responses to check how the application handles the errors.

## How to Simulate API error responses using Requestly

[Requestly](https://requestly.io) is a tool that intercepts all the network requests and allows users to modify them. It enables users to Modify Headers, Redirect URLs, Switch hosts, Mock API responses, Delay network requests, Insert custom scripts. It is available as a desktop app and browser extension on all major browsers.

[Requestly](https://app.requestly.io) app can simulate status code responses by using the redirect rule to redirect to a mock API that overrides the status code. In simple words, you are hitting the mock API instead of the actual API.

![Mock Server](/assets/blog-images/mock-server.png)

I used it to simulate status code responses on certain prominent websites.

I tried this with the following sites to see how the site handles the simulation of 500- Internal Server Error status code.

## Simulating 404 status code on blinkit search.

I created a mock using requestly setting 404 status code.

![Mock for simulating 404 response code on blinkit search](/assets/blog-images/mock-404-status.png)
_Mock for simulating 404 response code on blinkit search_

After some observation, I found that blinkit search API follows the pattern `[https://blinkit.in/v5/search/*](https://blinkit.in/v5/search/*)`

![Rule redirecting blinkit search to mock API response](/assets/blog-images/blinkit-404.png)
_Rule redirecting blinkit search to mock API response_

The blinkit website went into infinite loading on searching as a 404 response status code was simulated in the search API. The error is not handled here instead. If some message were to the user, the experience would have been better.

![Searching on Blinkit](/assets/blog-images/blinkit-search.png)
_Searching on Blinkit_

Get the rule here: [https://app.requestly.io/rules/#sharedList/1640614559005-blinkit-search-404](https://app.requestly.io/rules/#sharedList/1640614559005-blinkit-search-404)

This is how I used Requestly to simulate 404 in the blinkit search. I hope this article has helped you and empowers you to simulate different status codes.

Happy Debugging!

Further Resources:

- [Simulate different API status code using Requestly](https://requestly.io/blog/simulate-different-api-status-code-using-requestly/)
- [Simulating 500 when Tweeting](https://requestly.io/blog/simulating-500-status-code-in-create-tweet-api-on-twitter)

By [@nafees87n](https://www.linkedin.com/in/nafees87n/)



Nobody wants to see errors in their API. But they appear at times when least expected. The possible scenarios when an error pops up could be something is wrong with the request or some problem with the API. Whatever may be the cause, one thing is sure traffic would stop.

API crashes shouldn’t disrupt the user experience. Errors should be handled at the client-side so that the user knows that something is wrong and can move on from there.

In the development phase, API consumers won’t wait until the API is entirely built to start their development. In this scenario, they can mock server responses and begin their development. Testing the application for error responses is crucial so that user traffic is not blocked.

A QA tester or Product manager would want to mock various error responses to check how the application handles the errors.

## How to Simulate API error responses using Requestly

[Requestly](https://requestly.io) is a tool that intercepts all the network requests and allows users to modify them. It enables users to Modify Headers, Redirect URLs, Switch hosts, Mock API responses, Delay network requests, Insert custom scripts. It is available as a desktop app and browser extension on all major browsers.

[Requestly](https://app.requestly.io) app can simulate status code responses by using the redirect rule to redirect to a mock API that overrides the status code. In simple words, you are hitting the mock API instead of the actual API.

![Mock Server](/assets/blog-images/mock-server.png)

I used it to simulate status code responses on Twitter

I tried this with the following sites to see how the site handles the simulation of 500- Internal Server Error status code.

## Simulating 500 status code when Tweeting

I created a mock API using requestly setting Status Code as 500.

![Mock for simulating 500 error response on Twitter](/assets/blog-images/mock-500-status.png)
_Mock for simulating 500 error response on Twitter_

After some reverse engineering, I noticed that when the tweet button is clicked, a POST request is sent to a Twitter API ending with `CreateTweet`.

So I created the Requestly rule to be applied only when the URL matches `*/CreateTweet`using wildcard match.

![Redirect Rule redirecting to mock API](/assets/blog-images/createTweet-API.png)
_Redirect Rule redirecting to mock API_

The redirection to mock API won’t work due to [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)- [connect-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src) directive, which restricts the URLs loaded using script interfaces.

You can use the [Requestly marketplace](https://app.requestly.io/marketplace) rule to bypass this, which is a prebuilt rule to remove the `content-security-policy` header.

![Requestly Marketplace](/assets/blog-images/marketplace.png)

When I tried tweeting something, 500 status code was simulated and handled as following.

![500 error response simulated when tweeting](/assets/blog-images/twitter-screenshot.png)
_500 error response simulated when tweeting_

Get the rule here- [https://app.requestly.io/rules/#sharedList/1640613384657-twitter-500-simulate](https://app.requestly.io/rules/#sharedList/1640613384657-twitter-500-simulate)

This is how I used Requestly to simulate 500 when tweeting. I hope this article has helped you and empowers you to simulate different status codes.

Happy Debugging!

Further Resources:

- [Simulate different API status code using Requestly](https://requestly.io/blog/simulate-different-api-status-code-using-requestly)
- [Simulating 404 on Blinkit Search](https://requestly.io/blog/2021/12/28/simulate-404-API-status-code-in-blinkit-search-API)

By [@nafees87n](https://www.linkedin.com/in/nafees87n/)


Frontend Development

Debugging Next.js App in Production

Simulate Fake response status codes using Requestly

Simulating 404 HTTP status code in Blinkit Search API

Simulating 500 HTTP status code in Create Tweet API on Twitter

Get to know Requestly