All Posts In Nextjs

In this article, we introduce different ways to do the Data Fetching in a React App, especially with NextJS. You will learn something like, Static generation, Server-side rendering, and Client-side rendering.

Before nextJS 9.4, we could use next.config.js to set up environment variables, i.e., process.env.* which we can use in our application. In nextJS version 9.4 and up, we could use .env* files. At first glance, they make this complicated, but they have been given a purpose. In the article, we will go over this, and see how we benefit from this new feature.

NextFeathers uses JSON web token (JWT) for authentication when calling the Restful API implemented by FeathersJS. The JWT token was simply saved in the browser's localStorage and removed when the user is logged out. Many people said this is very bad because the hacker could run Javascript via what so-called XSS on your website, and read the data from localStorage. Personally, I kinda against this because it's unlikely happened, and as I know that is how AWS-amplify works by default. But there is indeed a risk, so I would like to fix it.

Everyone hates the server is down, but it happens sometimes. It's better you have a backup plan, that you can quickly switch to, but if not, at least you need to put the site in the maintenance mode, so your visitors won't be surprised by seeing the 404 or 500 error. In this article, I would like to show you how to put on a maintenance page quickly in the NextJs application.

Error handling is an essential aspect of web development to ensure smooth user experiences and provide meaningful feedback when things go wrong. In this blog post, we'll explore how Next.js, a popular React framework for building server-rendered applications, facilitates error handling. Specifically, we'll cover handling 404 errors, server-side errors (500), and client-side errors caused by JavaScript runtime errors using the react-error-boundary package.

As a Next.js developer, it's essential to optimize the SEO of your web pages to ensure they rank well in search engine results. However, you may come across an issue where Next.js renders duplicate meta tags, causing potential SEO problems. In this blog post, we will explore the problem and discuss a solution to fix it when using NextFeathers, a popular Next.js setup.

If you're a web developer using Next.js and have integrated Google Ads into your site, you may encounter a puzzling runtime error that says: "Error: Hydration failed because the initial UI does not match what was rendered on the server. Warning: Did not expect server HTML to contain a <iframe> in <ins>."

In the ever-evolving digital landscape, optimizing website performance is crucial for providing users with a seamless and responsive experience. One common strategy is caching responses to reduce server load and improve page load times. However, when it comes to bot requests, a different approach might be necessary to ensure optimal resource utilization.

In web development, providing a seamless and user-friendly experience is crucial. One common scenario involves loading a list of blog posts and allowing users to fetch more posts with a "Load More" button. However, when users click on a blog post and then navigate back, the page often resets, and users lose their loaded content. In this blog post, we'll explore how to overcome this challenge by leveraging the power of sessionStorage in a Next.js application.

To reduce high SYN_RECV and TIME_WAIT states on our Next.js + Feathers.js server, we enabled HTTP keep-alive in Axios, monitored socket usage, and adjusted system settings (tcp_syncookies=1, somaxconn=1024). While keep-alive helped reduce overhead, increasing somaxconn didn’t clearly improve results and may need to be reverted. Final tuning may also depend on upstream traffic and reverse proxy behavior.

When deploying Node.js applications with PM2, it’s important to understand how cluster mode, instances, and CPU cores interact — especially when you’re combining multiple apps like a Next.js frontend and a Feathers.js backend. This post breaks down the core concepts and lessons learned from setting up next-dna and feathers-dna with PM2 cluster mode.

On May 28, I reviewed 20 minutes of live traffic logs from my website to evaluate whether my 2-core server could keep up with demand. The data showed over 13,000 requests — roughly 11 per second — with a mix of bot and real user traffic hitting SSR pages and API routes. While the server handled it, signs of strain appeared: spikes in TIME_WAIT, socket hang-up errors, and MongoDB lag. The conclusion? My setup is nearing its safe limits. Upgrading to 4 cores or offloading some processing (e.g., MongoDB or caching) may be necessary to maintain performance and stability as traffic grows.