Forem: Hoang Duy

Object vs Map in JavaScript — A Performance Cheat Sheet

Hoang Duy — Fri, 10 Apr 2026 06:46:12 +0000

It's duythenights again! Great to have you back.

When should you use Object and when should you use Map? In this post, I'll break it down with a side-by-side comparison, benchmarks, gotchas, and practical rules — cheat sheet style.

Try the Interactive Demo — benchmark Object vs Map with real API data in your own browser.

TL;DR

	Object	Map
Key types	`string` or `Symbol` only	Any value (object, function, number...)
Insertion order	Not guaranteed (except integer keys)	Guaranteed
Size	`Object.keys(obj).length`	`map.size` — O(1)
Iteration	`Object.keys()` / `for...in`	`for...of` / `.forEach()` — native
Prototype pollution	Yes	No
Serialization	`JSON.stringify()` native	Manual conversion needed
Best for	Struct-like data, fixed shape	Dictionary, dynamic keys, frequent add/delete

Creating & Basic Operations

Object

// Create
const obj = {};
const obj2 = { name: "Alice", age: 30 };
const obj3 = Object.create(null); // no prototype — safer as dictionary

// Set
obj["key"] = "value";
obj.key = "value";

// Get
const val = obj["key"];
const val2 = obj.key;

// Check
"key" in obj;              // true — but checks prototype chain too
obj.hasOwnProperty("key"); // true — own properties only

// Delete
delete obj["key"];

// Size
Object.keys(obj).length;

Map

// Create
const map = new Map();
const map2 = new Map([["name", "Alice"], ["age", 30]]);

// Set
map.set("key", "value");
map.set(42, "number key");       // any type as key
map.set(document.body, "DOM");   // even objects

// Get
const val = map.get("key");

// Check
map.has("key"); // true — no prototype chain issue

// Delete
map.delete("key");

// Size
map.size; // O(1) — direct property

Iteration

Object

const user = { name: "Alice", age: 30, role: "admin" };

// Keys only
Object.keys(user);    // ["name", "age", "role"]

// Values only
Object.values(user);  // ["Alice", 30, "admin"]

// Entries
Object.entries(user); // [["name","Alice"], ["age",30], ["role","admin"]]

// for...in (includes inherited — usually not what you want)
for (const key in user) {
  if (user.hasOwnProperty(key)) {
    console.log(key, user[key]);
  }
}

Map

const config = new Map([["theme", "dark"], ["lang", "en"], ["debug", false]]);

// Native iterable — no intermediate array created
for (const [key, value] of config) {
  console.log(key, value);
}

// forEach
config.forEach((value, key) => {
  console.log(key, value);
});

// Destructured iterators
config.keys();    // MapIterator {"theme", "lang", "debug"}
config.values();  // MapIterator {"dark", "en", false}
config.entries(); // MapIterator {["theme","dark"], ["lang","en"], ...}

The Prototype Trap

const obj = {};

// Looks empty, but...
"toString" in obj;      // true — inherited from Object.prototype
"constructor" in obj;   // true
"hasOwnProperty" in obj; // true

// This can cause bugs:
const cache = {};
cache["constructor"] = "my value";
// Shadows Object.prototype.constructor — unexpected behavior

// Safe alternative:
const safeObj = Object.create(null); // no prototype chain
"toString" in safeObj; // false

const map = new Map();

// Clean — no prototype pollution
map.has("toString");    // false
map.has("constructor"); // false
// Map keys live in a completely separate namespace

Key Type Flexibility

// Object: keys are coerced to strings
const obj = {};
obj[1] = "one";
obj["1"] = "string one";
console.log(obj[1]); // "string one" — 1 was coerced to "1"

obj[true] = "bool";
console.log(obj["true"]); // "bool" — true was coerced to "true"

const key = { id: 1 };
obj[key] = "object key";
console.log(obj["[object Object]"]); // "object key" — objects become "[object Object]"

// Map: keys keep their original type
const map = new Map();
map.set(1, "number one");
map.set("1", "string one");
console.log(map.get(1));   // "number one"
console.log(map.get("1")); // "string one" — different keys!

const objKey = { id: 1 };
map.set(objKey, "object key");
map.get(objKey); // "object key" — works with reference equality
map.size; // 3

Serialization

// Object: native JSON support
const obj = { name: "Alice", age: 30 };
const json = JSON.stringify(obj); // '{"name":"Alice","age":30}'
const parsed = JSON.parse(json);  // { name: "Alice", age: 30 }

// Map: requires manual conversion
const map = new Map([["name", "Alice"], ["age", 30]]);

// Map → JSON
const json = JSON.stringify(Object.fromEntries(map));

// JSON → Map
const restored = new Map(Object.entries(JSON.parse(json)));

// Or for non-string keys:
const json2 = JSON.stringify([...map]); // serialize as array of entries
const restored2 = new Map(JSON.parse(json2));

Performance: When It Matters

Both are O(1) for get/set/delete in Big-O terms, but constant factors differ significantly depending on how many keys you have.

Small collections (< ~30 keys)

Object wins or ties. V8 uses Hidden Classes and Inline Caching — property access is nearly as fast as accessing a field in a C struct.

// V8 internally creates a "hidden class" for this shape:
const user = { name: "Alice", age: 30, role: "admin" };

// Subsequent access is extremely fast because V8 knows
// the exact memory offset of each property.
user.name; // direct offset lookup — no hash needed

Large collections (1000+ dynamic keys)

Map wins. When an Object has too many dynamically-added keys, V8 switches to "dictionary mode" — a hash table that's less optimized than Map's purpose-built one.

const lookup = {};
for (let i = 0; i < 10000; i++) {
  lookup[`key_${i}`] = i; // V8 gives up on hidden classes → dictionary mode
}
// At this point, lookup["key_500"] is a hash table access
// Map would be faster here because its hash table has
// less overhead (no prototype chain, no property descriptors)

Frequent add/delete

Map wins clearly. delete obj[key] is one of the slowest operations in V8 because it breaks the hidden class chain and forces the engine to rebuild internal structures.

// This is expensive — don't do this in hot paths:
const cache = {};
cache["session_123"] = data;
delete cache["session_123"]; // breaks hidden class

// This is fast — Map is designed for this:
const cache = new Map();
cache.set("session_123", data);
cache.delete("session_123"); // O(1), no side effects

Benchmark summary (1,000 entries)

Operation	Winner	Why
Insert	Map	Designed for dynamic additions
Lookup	Map	Object falls into dictionary mode at this size
Update	Tie	Both are simple hash table operations
Delete	Map	`delete` on Object breaks hidden classes
Has Key	Map	`map.has()` vs `in` (prototype chain traversal)
Iterate	Map	Native iterator vs `Object.keys()` array allocation

Try it yourself: Interactive Demo — benchmark Object vs Map with real API data in your own browser.

Decision Flowchart

Do you need JSON serialization?
├── Yes → Object
└── No
    └── Are keys always strings?
        ├── No → Map (only Map supports non-string keys)
        └── Yes
            └── Fixed shape, known at write time?
                ├── Yes → Object (V8 optimizes this heavily)
                └── No
                    └── Frequent add/delete?
                        ├── Yes → Map
                        └── How many keys?
                            ├── < 100 → Object (simpler, good enough)
                            └── 100+ → Map

Quick Reference

Use Object when:

Representing a record/struct with fixed fields (user.name, user.age)
Response/payload objects from APIs (JSON-native)
You need destructuring (const { name, age } = user)
Writing config/options objects passed to functions
Keys are always strings and the set is small and static

Use Map when:

Building a cache, lookup table, or registry
Keys are not strings (DOM nodes, objects, numbers)
You need guaranteed insertion order
You add and remove entries frequently
You need .size without counting
You want to iterate without Object.keys() overhead
You want no prototype pollution risk

Common Patterns

Pattern: Object as struct, Map as index

interface User {
  id: number;
  name: string;
  email: string;
}

// Object for data shape (struct)
const user: User = { id: 1, name: "Alice", email: "alice@dev.to" };

// Map for lookup index (dictionary)
const usersById = new Map<number, User>();
usersById.set(user.id, user);

// Fast lookup
const found = usersById.get(1); // O(1), type-safe key

Pattern: Map for counting

function wordFrequency(text: string): Map<string, number> {
  const freq = new Map<string, number>();
  for (const word of text.split(/\s+/)) {
    freq.set(word, (freq.get(word) ?? 0) + 1);
  }
  return freq; // iteration order = insertion order
}

Pattern: Map for caching with object keys

const cache = new Map<HTMLElement, DOMRect>();

function getCachedRect(el: HTMLElement): DOMRect {
  if (cache.has(el)) return cache.get(el)!;
  const rect = el.getBoundingClientRect();
  cache.set(el, rect); // DOM element as key — impossible with Object
  return rect;
}

Pattern: WeakMap for private data (no memory leak)

const metadata = new WeakMap<object, { createdAt: number }>();

function track(obj: object) {
  metadata.set(obj, { createdAt: Date.now() });
}

// When obj is garbage collected, its WeakMap entry is automatically removed
// This is impossible with Object or Map

If you found this useful, drop a reaction. Questions? Let's discuss in the comments.

What if: we have two same keys in Reactjs?

Hoang Duy — Thu, 09 Apr 2026 09:23:22 +0000

It is duythenights again! Great to have you back.

If you’ve seen that yellow warning in your console: "Encountered two children with the same key," don't ignore it.

This is not just a cosmetic console error; it is a fundamental logic failure that results in what I call "Reconciliation Chaos." To understand why this happens, we need to look at how React manages the relationship between your data and the physical DOM.

The Core Problem: How React Logic Breaks

To see the disaster in action, let's look at exactly what happens step-by-step when you use duplicate keys.

The Setup:

Repository link: demo-two-same-keys
Demo link: https://demo-two-same-keys-in-reactjs.vercel.app/
Suppose you have an array of 4 items: A, B, C, D.

Item A: ID = "1"
Item B: ID = "1" (Duplicate!)
Item C: ID = "3"
Item D: ID = "4"

  const [items, setItems] = useState([
    { id: "1", text: "Item A" },
    { id: "1", text: "Item B" }, // Duplicate ID
    { id: "3", text: "Item C" },
    { id: "4", text: "Item D" },
  ]);

  const removeA = () => {
    setItems(items.filter((item) => item.text !== "Item A"));
  };

  const idCount: Record<string, number> = {};
  items.forEach((item) => {
    idCount[item.id] = (idCount[item.id] || 0) + 1;
  });

 <ul className="item-list">
          {items.map((item) => {
            const isDuplicate = idCount[item.id] > 1;
            return (
              <li
                key={item.id}
                className={`item-row${isDuplicate ? " duplicate" : ""}`}
              >
                <span className="item-id">{item.id}</span>
                <span className="item-text">{item.text}</span>
                <input className="item-input" placeholder="Type here…"    />
                {isDuplicate && (
                  <span className="badge-duplicate">dup</span>
                )}
              </li>
            );
          })}
</ul>

The Action:

You type some text in A and B

You click a button to delete Item A.

Result: title B with input content A

The Step-by-Step Breakdown:

Step 1 (Data Update): Your code runs a filter through the array. The data is updated correctly. The new array now contains only B, C, D.
Step 2 (Virtual DOM Check): React’s Virtual DOM checks the IDs needed for the new render. It sees it needs to render ID "1" (Item B), ID "3" (Item C), and ID "4" (Item D).
Step 3 (The Wrong Reuse): React looks at the existing physical DOM. It sees a DOM node with ID=1 already exists at the top. Because React is "lazy" to save performance, it says: "Since ID=1 is already in the DOM and still in my data, I will just reuse it." But this is actually Item A's DOM node. React then assumes the actual DOM node for Item B is a redundant duplicate and deletes it. Items C and D remain untouched.
Step 4 (Data Injection): Now, React loads the new data into the existing DOM nodes. It takes the text "B" from your array and sets it as the innerText for Item A's old DOM node.

Reconciliation Chaos: The Ghost and the Shell

This process creates a "Frankenstein" component where the "Shell" (The DOM) belongs to one item, but the "Ghost" (The Data) belongs to another.

1. The Shell (The Physical DOM)

Because the physical DOM node of Item A was never destroyed, it keeps everything that React doesn't explicitly control through props. This includes Internal States such as:

Uncontrolled Input values: The text a user typed into a box.
Focus state: Which element the cursor is currently in.
Scroll position: How far down a specific div has been scrolled.
CSS Animations: A transition that was halfway finished.

2. The Ghost (The Injected Data)

React pours Item B’s data into Item A’s old "Shell." The labels update, the images change, but the "Shell" is still haunted by Item A's state.

The Result: You see the name "Item B" on the screen, but if you had typed "Hello A" into an input field, that text is still there. The UI has lied to the user because the identity was not unique.

3. The Performance Collapse (Re-render Panic)

Beyond just visual bugs, duplicate keys act as a "performance killer" for your application. React's speed relies on Surgical Updates—the ability to change only the tiny piece of the DOM that actually changed. When keys are duplicated, this surgical precision is destroyed.

Breaking Memoization: If you are using React.memo or PureComponent to optimize your list, duplicate keys make them useless. React cannot reliably compare the previous props with the new props because it can't verify which data belongs to which instance.
The "Panic" Remount: Because React is confused about the identity of your items, it often gives up on "updating" and resorts to "remounting." Instead of just changing a text label, React may destroy the entire DOM subtree and recreate it from scratch.
The Domino Re-render: In a healthy list, deleting one item should only trigger a change at that specific index. With duplicate keys, a single change can trigger a "Domino Effect," forcing React to re-evaluate and re-render every single item in the list because it has lost the "map" of your UI.

How to Stay Safe

If your data source returns duplicate IDs, follow these steps:

Uniqueness is Law: Treat the key prop like a Primary Key in a database. It must be unique among siblings.
Sanitize Data: If your API returns duplicate IDs, fix them before they reach your state.
Stable Identity: Never use the array index as a key if the list can be filtered or deleted.

The Bottom Line: React’s speed comes from its ability to reuse DOM nodes. If you provide duplicate keys, React reuses the wrong nodes, resulting in corrupted UI states that are a nightmare to debug.

Good vs Bad Next.js Rendering: How to Choose the Right Strategy

Hoang Duy — Tue, 07 Apr 2026 06:02:06 +0000

It is duythenights again! Great to have you back.

Choosing the right rendering strategy in Next.js is absolutely critical for your app's performance. Honestly, selecting the wrong one can lead to painfully slow page loads, sky-high server costs, and a pretty poor user experience—none of which we want!

But don't worry, I've got you covered. This cheat sheet is here to simplify the whole process. Let's break down exactly when to use each method effectively so you can stop second-guessing your architecture and start building faster.

Quick Comparison Table

Strategy	Timing	Best Use Case	SEO	Performance
Static Site Generation (SSG)	Build Time	Blogs, Documentation	Excellent	Fastest
Server-Side Rendering (SSR)	Request Time	Personalized Feeds	Excellent	Slower
Incremental Static Regeneration (ISR)	Background	E-commerce, News	Excellent	Fast
Client-Side Rendering (CSR)	Browser Runtime	Search Filters, Chat	Limited	Fast (Post-load)

Decision Logic: Good vs Bad Practice

Static Site Generation (SSG)

Good: Using SSG for a blog post that stays the same for all users.
Bad: Rebuilding your entire site every time you fix a single typo in a post.

Server-Side Rendering (SSR)

Good: Using SSR for a banking dashboard where data must be 100% current and private.
Bad: Using SSR for a public "About Us" page. This adds unnecessary latency and server load.

Incremental Static Regeneration (ISR)

Good: Using ISR for a product catalog with 10,000 items. It keeps the site fast while updating prices in the background.
Bad: Setting a revalidation timer of 1 second for data that only changes once a week.

Implementation (Next.js App Router)

1. The Good Default: Static Site Generation

Next.js caches fetch requests by default. This is the most cost-effective and fastest method.

async function Page() {
  const data = await fetch('[https://api.example.com/data](https://api.example.com/data)'); 
  return <div>{data.title}</div>;
}

2. The Dynamic Choice: Server-Side Rendering

Use this only when data must be fetched at the exact moment of the request.

async function Page() {
  const data = await fetch('[https://api.example.com/data](https://api.example.com/data)', { cache: 'no-store' });
  return <div>{data.user_balance}</div>;
}

3. The Balanced Choice: Incremental Static Regeneration

This allows you to update static content without a full site rebuild.

async function Page() {
  const data = await fetch('[https://api.example.com/data](https://api.example.com/data)', { 
    next: { revalidate: 3600 } // Updates every hour
  });
  return <div>{data.stock_level}</div>;
}

Summary Checklist

Good: Default to SSG whenever possible.
Good: Use ISR to scale dynamic content efficiently.
Bad: Using CSR for content that needs to rank on search engines.
Bad: Overusing SSR for public pages that don't change per user.

How to Create an Animated Button with Hover Sound in React

Hoang Duy — Fri, 06 Jun 2025 14:46:58 +0000

[TL;DR] Demo

Buttons are essential UI elements in any web application, but making them interactive and delightful can truly elevate the user experience. In this post, we’ll build a stylish React button component with a hover animation and sound effect when the user hovers over it.

By the end, you'll have a reusable button component with:

Smooth hover text animation
Optional icons (left and right)
A tick sound when hovered

🔧 Technologies Used

React
Tailwind CSS (for styling and animation)
HTML5 Audio API

📦 The Button Component

Below is the complete Button component you can copy into your React project.

import clsx from "clsx";
import { useEffect, useRef } from "react";

const Button = ({
  id,
  title,
  rightIcon,
  leftIcon,
  containerClass,
  hoverSound = "/audio/ui.mp3", // Sound file path
  hoverSoundAt = 0,
  children,
}) => {
  const audioRef = useRef(null);

  // Preload the hover sound
  useEffect(() => {
    if (hoverSound) {
      audioRef.current = new Audio(hoverSound);
      audioRef.current.currentTime = hoverSoundAt;
      audioRef.current.preload = "auto";
    }
  }, [hoverSound, hoverSoundAt]);

  // Play sound on hover
  const handleMouseEnter = () => {
    if (audioRef.current) {
      audioRef.current.currentTime = 0;
      audioRef.current.play();
    }
  };

  // Reset sound on mouse leave
  const handleMouseLeave = () => {
    if (audioRef.current) {
      audioRef.current.pause();
      audioRef.current.currentTime = 0;
    }
  };

  return children ? (
    <span
      id={id}
      onMouseEnter={handleMouseEnter}
      onMouseLeave={handleMouseLeave}
    >
      {children}
    </span>
  ) : (
    <button
      id={id}
      onMouseEnter={handleMouseEnter}
      onMouseLeave={handleMouseLeave}
      className={clsx(
        "group relative z-10 w-fit cursor-pointer overflow-hidden rounded-full bg-violet-50 px-7 py-3 text-black",
        containerClass
      )}
    >
      {leftIcon}

      <span className="relative inline-flex overflow-hidden font-general text-xs uppercase">
        <div className="translate-y-0 skew-y-0 transition duration-500 group-hover:translate-y-[-160%] group-hover:skew-y-12">
          {title}
        </div>
        <div className="absolute translate-y-[164%] skew-y-12 transition duration-500 group-hover:translate-y-0 group-hover:skew-y-0">
          {title}
        </div>
      </span>

      {rightIcon}
    </button>
  );
};

export default Button;

🎨 Styling Explained

We use Tailwind utility classes to achieve a sleek sliding animation for the button text:

<span className="relative inline-flex overflow-hidden font-general text-xs uppercase">
  <div className="translate-y-0 skew-y-0 transition duration-500 group-hover:translate-y-[-160%] group-hover:skew-y-12">
    {title}
  </div>
  <div className="absolute translate-y-[164%] skew-y-12 transition duration-500 group-hover:translate-y-0 group-hover:skew-y-0">
    {title}
  </div>
</span>

The first div moves up and skews on hover.
The second div takes its place from below, giving a smooth slide-in effect.

🔊 Adding Hover Sound

We preload and play the sound using the native Audio API:

const audioRef = useRef(null);
audioRef.current = new Audio(hoverSound);

This ensures the tick sound plays instantly on hover.

💡 Tip:

Make sure your audio file (ui.mp3) is placed correctly in the public/audio/ directory (or adjust the path).

✅ Usage Example

<Button
  title="Click Me"
  hoverSound="/audio/ui.mp3"
  leftIcon={<MyLeftIcon />}
  rightIcon={<MyRightIcon />}
  containerClass="bg-blue-200 hover:bg-blue-300"
/>

🚀 Final

This button is great for game UIs, modern websites, or any interface where tactile feedback enhances the experience. You can customize it further by changing:

The animation style
The sound file
The icon positions

📁 Resources

Happy coding! _duythenights 🔊💻✨

Who tf wrote this code?

Hoang Duy — Wed, 19 Mar 2025 08:04:47 +0000

Automate Next.js Deployment to AWS EC2 using GitHub Actions

Hoang Duy — Fri, 14 Mar 2025 05:12:37 +0000

Automating your Next.js deployment process can significantly streamline updates and reduce manual effort. This guide will walk through setting up GitHub Actions to automatically deploy your Next.js application to an AWS EC2 instance.

Prerequisites

Refer to the previous post for setting up the AWS EC2 instance, installing Node.js, configuring Nginx, and optimizing with Cloudflare.

1. Setting Up GitHub Secrets

Before configuring GitHub Actions, store the following secrets in your GitHub repository:

EC2_HOST: Public IP of your EC2 instance
EC2_USER: SSH username (e.g., ubuntu)
SSH_PRIVATE_KEY: Private key for SSH authentication
FOLDER_NAME: Folder name where the app is stored on EC2
PM2_NAME: PM2 process name

To add these secrets:

Go to your repository on GitHub.
Navigate to Settings > Secrets and variables > Actions.
Click New repository secret and add the required secrets.

2. Creating the GitHub Actions Workflow

Create a .github/workflows/deploy.yml file in your repository with the following content:

name: YOUR_APP

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

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

      - name: Install Node.js 20
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm install

      - name: Build Next.js application
        run: npm run build

      - name: Upload files to EC2
        uses: appleboy/scp-action@v0.1.4
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          source: "."
          target: "/home/${{ secrets.EC2_USER }}/${{ secrets.FOLDER_NAME }}"
          rm: true
          strip_components: 1

      - name: Run deployment commands on EC2
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /home/${{ secrets.EC2_USER }}/${{ secrets.FOLDER_NAME }}
            npm install --production

            # Ensure PM2 is installed
            sudo npm install -g pm2

            # Restart or start PM2 process
            pm2 restart ${{ secrets.PM2_NAME }} || pm2 start npm --name ${{ secrets.PM2_NAME }} -- start

3. How It Works

Triggers on push: The workflow runs whenever new code is pushed to the main branch.
Installs dependencies: Node.js 20 and required npm packages are installed.
Builds the application: Next.js is built before deployment.
Uploads files to EC2: The app is securely copied to the instance using SCP.
Runs deployment commands:
- Installs necessary dependencies on the server.
- Ensures PM2 is running and restarts the application.

4. Testing the Deployment

Push a commit to main branch:

git add .
git commit -m "Deploy update"
git push origin main

Monitor the workflow under GitHub Actions > PORTFOLIO.
Verify the deployment on your EC2 instance:

pm list -g pm2
pm2 list

5. Common Issues & Fixes

1. SSH Authentication Fails

Ensure your private key matches the one on EC2 (~/.ssh/authorized_keys).
Set correct permissions for the key: chmod 600 your-key.pem.

2. PM2 Not Restarting

Run pm2 list to check if the process is running.
Manually restart: pm2 restart <your-app-name>.

3. Deployment Not Updating

Ensure old files are removed: rm -rf /home/your-user/your-app/* before uploading.

Conclusion

With GitHub Actions, deploying Next.js to AWS EC2 is automated, efficient, and scalable. This setup allows for seamless updates, ensuring minimal downtime. Next, we’ll explore adding a CI/CD pipeline with automated testing!

Deploy Next.js on AWS EC2 with PM2, Nginx, and Cloudflare CDN

Hoang Duy — Fri, 14 Mar 2025 03:06:35 +0000

Deploying a Next.js application on AWS EC2 can be an efficient way to host a scalable web application. This guide will provide a detailed step-by-step approach to setting up and deploying a Next.js application on an EC2 instance, managing the process using PM2, configuring Nginx as a reverse proxy, and optimizing the domain with Cloudflare CDN.

Prerequisites

AWS EC2 instance running Ubuntu (20.04 or later)
A Next.js application ready for deployment
Domain registered on Namecheap
A Cloudflare account
Basic knowledge of Linux commands

1. Setting Up an AWS EC2 Instance

Step 1: Launch an EC2 Instance

Log in to your AWS Console and navigate to EC2.
Click on Launch Instance.
Choose Ubuntu 22.04 LTS as the OS.
Select an instance type:
- t2.micro (Free-tier eligible for testing/small apps)
- t3.medium or higher for production apps
Configure security groups:
- SSH (port 22): Allow only your IP for security.
- HTTP (port 80): Allow public access.
- HTTPS (port 443): Allow public access.
- Custom TCP (port 3000): Allow only if testing Next.js directly.

Launch the instance and download the key pair for SSH access.

Step 2: Connect to the Instance

Use SSH to connect:

ssh -i your-key.pem ubuntu@your-ec2-public-ip

If got permission error, please run this before:

chmod 400 your-key.pem

2. Install Node.js and PM2

Step 1: Install Node.js and npm

Update and install Node.js:

sudo apt update && sudo apt upgrade -y
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Verify installation:

node -v
npm -v

Step 2: Install PM2 for Process Management

npm install -g pm2
pm2 startup

3. Deploy the Next.js Application

Step 1: Clone Your Repository

Navigate to the home directory and clone your Next.js project:

cd ~
git clone https://github.com/yourusername/your-nextjs-app.git
cd your-nextjs-app

Step 2: Install Dependencies

npm install

Step 3: Build the Next.js Application

npm run build

Step 4: Start the App with PM2

pm2 start npm --name "nextjs-app" -- start
pm2 save

Check status:

pm2 list

4. Setting Up Nginx as a Reverse Proxy

Step 1: Install Nginx

sudo apt install nginx -y

Step 2: Configure Nginx

Open the Nginx configuration file:

sudo nano /etc/nginx/sites-available/default

Replace its contents with:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Save and exit (CTRL+X, then Y, then ENTER).

Step 3: Restart Nginx

sudo systemctl restart nginx

Check status:

sudo systemctl status nginx

5. Configure Namecheap DNS Settings

Log in to your Namecheap account.
Go to Domain List > Select your domain > Click Manage.
Under the Advanced DNS tab, add an A Record:
- Host: @
- Value: Your EC2 public IP address
- TTL: Automatic
Add a CNAME Record:
- Host: www
- Value: yourdomain.com
- TTL: Automatic
Save changes and wait for propagation (~30 minutes to a few hours).

6. Optimize with Cloudflare CDN

Step 1: Add Your Site to Cloudflare

Sign up/log in to Cloudflare.
Click Add a Site and enter your domain.
Cloudflare will scan your DNS records.
Choose Free Plan and continue.
Update your Namecheap nameservers with the ones provided by Cloudflare.
Wait for DNS propagation.

Step 2: Enable CDN and Security Features

Enable Automatic HTTPS Rewrites.
Enable Always Use HTTPS.
Turn on CDN caching for improved performance.
Enable DDoS protection and security features.

7. Secure Your Site with SSL

Once Cloudflare is active:

Go to Cloudflare dashboard > SSL/TLS.
Set SSL mode to Full (Strict).
Restart Nginx to apply changes:

sudo systemctl restart nginx

8. Deploying Updates

To deploy updates, SSH into the instance and run:

cd ~/your-nextjs-app
git pull origin main
npm install
npm run build
pm2 restart nextjs-app

9. Common Errors and Solutions

Error 1: PM2 Not Restarting on Reboot

Run:

pm2 startup
pm2 save

Error 2: Nginx 502 Bad Gateway

Check if the Next.js app is running:

pm2 list

If not running, restart:

pm2 restart nextjs-app

Error 3: DNS Propagation Delay

Check DNS propagation:
www.whatsmydns.net

Conclusion

Congratulations! Your Next.js application is now live on AWS EC2 with PM2 for process management, Nginx as a reverse proxy, and a custom domain from Namecheap optimized with Cloudflare CDN. This setup ensures high availability, security, and performance for your web application.
In the next post, I'll show you how to add a GitHub Action to automate CI/CD for your application.

Making API Calls with Axios More Readable Using the Builder Pattern

Hoang Duy — Thu, 13 Mar 2025 09:40:26 +0000

If you’ve been working as a frontend developer for a while, you’ve probably written your fair share of API calls. At first, using Axios feels super straightforward. But as the project grows, API calls start getting messy, repetitive, and hard to manage.

Let’s be real—when a new dev joins the team, they’ll probably struggle to figure out what’s going on (just like I did during my first internship!). So how do we keep things clean, readable, and scalable? That’s where the Builder Pattern comes in.

The Problem with Basic Axios Calls

Here’s a typical API call using Axios:

import axios from "axios";

async function fetchUser(userId) {
  try {
    const response = await axios.get(`https://api.example.com/users/${userId}`, {
      headers: {
        "Content-Type": "application/json",
        Authorization: "Bearer someToken",
      },
      params: { includePosts: true },
    });
    console.log(response.data);
  } catch (error) {
    console.error("API Error:", error);
  }
}

What’s Wrong With This?

Too much repetition – If you need the same headers or params elsewhere, you’ll have to copy-paste them.
Hard to read – New developers might take time to understand the request structure.
Not scalable – As the number of API calls increases, maintaining consistency across them gets painful.

The Fix: Using the Builder Pattern

The Builder Pattern helps us structure API calls in a reusable and readable way.

Step 1: Create a Request Builder

Here’s how we can wrap Axios calls into a reusable class:

import axios from "axios";

class ApiRequestBuilder {
  constructor() {
    this.config = {
      method: "get",
      url: "",
      headers: {},
      params: {},
      data: null,
    };
  }

  setMethod(method) {
    this.config.method = method;
    return this;
  }

  setUrl(url) {
    this.config.url = url;
    return this;
  }

  setHeaders(headers) {
    this.config.headers = { ...this.config.headers, ...headers };
    return this;
  }

  setParams(params) {
    this.config.params = params;
    return this;
  }

  setData(data) {
    this.config.data = data;
    return this;
  }

  async send() {
    try {
      const response = await axios(this.config);
      return response.data;
    } catch (error) {
      console.error("API Error:", error);
      throw error;
    }
  }
}

export default ApiRequestBuilder;

Step 2: Use the Builder to Make API Calls

Now, instead of writing messy API calls, we can use the ApiRequestBuilder like this:

Fetching a User (GET Request)

import ApiRequestBuilder from "./ApiRequestBuilder";

async function fetchUser(userId) {
  try {
    const user = await new ApiRequestBuilder()
      .setMethod("get")
      .setUrl(`https://api.example.com/users/${userId}`)
      .setHeaders({ "Content-Type": "application/json", Authorization: "Bearer someToken" })
      .setParams({ includePosts: true })
      .send();

    console.log("User Data:", user);
  } catch (error) {
    console.error("Error fetching user:", error);
  }
}

Creating a User (POST Request)

async function createUser(userData) {
  try {
    const newUser = await new ApiRequestBuilder()
      .setMethod("post")
      .setUrl("https://api.example.com/users")
      .setHeaders({ "Content-Type": "application/json" })
      .setData(userData)
      .send();

    console.log("User Created:", newUser);
  } catch (error) {
    console.error("Error creating user:", error);
  }
}

Why Use the Builder Pattern for Axios?

Cleaner Code – No more long, repetitive API calls.

Reusable & Scalable – Define headers, params, and methods once and reuse them anywhere.

Easier to Maintain – Changing API structure? Just update the builder class!

Better for Teams – New devs can understand API calls faster.

If you’ve ever had to hunt down inconsistent API calls across a project, this pattern will save you a ton of headaches. 😅

Wrapping Up

The Builder Pattern is an awesome way to clean up Axios API calls in frontend projects. It improves readability, maintainability, and scalability, making your life (and your team’s) much easier.

If you’re tired of messy API calls, give this pattern a shot! 🚀