Some Problems I Had in Nuxt JS (and how to solve them)
Tags: javascript, nuxt, tailwindcss
Published: 2021-08-29 11:55:55

I once had a project that required our frontend team to use **Vue JS**. Finally, we decided to use Nuxt JS as a Vue JS framework that can handle SEO as well as simplify many things, for example, *routing* where we just make various components in the **pages** folder which later components in the pages folder can be turned into pages automatically by Nuxt.

In my opinion, store or state management through **Vuex** is also made easier with the **store** folder that has been provided by Nuxt. Each folder created in the store folder will create a new *module* for the store.

However, as long as we are coding or developing the application using Nuxt JS, there are some obstacles that our team has experienced and I intend to share them. Perhaps the solution to each of our problems can help you or this article can also be a place for discussion if, for example, you have more sophisticated solutions.
***

## First problem: "heap limit allocation failed - javascript heap out of memory"

![error-heap-memory-js](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0ehoz8wryt5ru0rlngqk.jpg)

The first problem we ran into was getting an error like this. We first encountered this error when we were running the **build** command in **package.json**. We happen to be using **yarn**, so we use this command to build:

```
yarn build
```

After we found out, it turns out that this problem can not only be experienced by Nuxt JS applications. **React** and **Angular** applications can also experience the same thing. I still don't know the cause until now. We assume that RAM or memory on the server which is only 2 GB is too little, but on a local computer with 16 GB of RAM it turns out to be the same thing.

Finally we tricked by editing the script in **package.json** to be like this:

```json
"scripts": {
  "dev": "node --max-old-space-size=3000 node_modules/nuxt/bin/nuxt.js dev",
  "build": "node --max-old-space-size=3000 node_modules/nuxt/bin/nuxt.js build",
  "start": "node --max-old-space-size=3000 node_modules/nuxt/bin/nuxt.js start",
}
```

The first problem was finally solved.
***

## Second problem: "unable to verify the first certificate"

![ssl-error-nuxtjs](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ur26l90ycm3rijc49amj.jpg)

At the time of deploying to our *dev server*, all went well. But when deploying to the client server, there is a problem in the SSL sertificate. When the website page is loaded for the first time, the website throw an error.

![server-error-nuxt](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y8s8k9drd0sbtb4lrgz9.png)

Strangely, when we open a static page that doesn't fetch data from the API, we can, and when we move pages or click a link (*nuxt-link*) on the static page we can do that too.

But when loading a page that fetches data from the API (page containing *axios* running on **asyncData** and **fetch**) for the first time (via browser url), an error occurred.

We finally solved this problem by disabling SSR, in other words the website application we are working on is now completely *client-side rendering*.

The way to make a Nuxt application a client-side rendering is to add a new property in **nuxt.config.js**.

```javascript
export default {
  ssr: false,
  ...
}
```

After being made into a client-side rendering, the application turned out to be much faster and the building time was faster too. Because if in the previous SSR there were 2 built, namely Server and Client, now only 1 is built in the terminal, namely Client.

![terminal-client-side-build-nuxt](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5r9j6siamemq7hr4jkuy.jpg)

We also just found out that **ssr** that is made **false** can speed up the application, this can be used as an alternative if you want to develop Nuxt JS applications to make it faster, by changing ssr to false for a while. When you are done developing the app, and you want to make the app SSR again, **ssr** in nuxt.config.js can be change to **true** again.

Then what about our previous client application? Yes, like it or not, it's going to be client-side for a while until there is further confirmation about the problem with SSL on the client server.
***

Another new question arises, do you think a client-side application like this affects a bad SEO or not? Because I've seen on social media that Google is now able to make a better SEO for client-side web applications.