DEV Community: EME GUG

Writing better API error responses

EME GUG — Wed, 23 Sep 2026 07:04:53 +0000

Most APIs return errors like {"error": "Something went wrong"}. That's not helpful for anyone — not the frontend dev, not the user, not the on-call engineer debugging at 3 AM.

The Problem

// Bad
{"error": "Invalid request"}

// Also bad
{"message": "Error", "code": 400}

// Worst
500 Internal Server Error (empty body)

A Better Format

{
    "error": {
        "code": "VALIDATION_ERROR",
        "message": "Email address is invalid",
        "details": [
            {
                "field": "email",
                "message": "Must be a valid email address",
                "value": "not-an-email"
            }
        ],
        "request_id": "req_abc123"
    }
}

Why each field matters:

code: Machine-readable, stable across versions. Frontend uses this to show the right UI.
message: Human-readable, can change. For developer debugging.
details: Field-level errors for forms. Frontend maps these to input fields.
request_id: Links to server logs. Makes debugging 10x faster.

Implementation (Express.js)

class AppError extends Error {
    constructor(code, message, statusCode = 400, details = null) {
        super(message);
        this.code = code;
        this.statusCode = statusCode;
        this.details = details;
    }
}

// Middleware
app.use((err, req, res, next) => {
    const requestId = req.id || crypto.randomUUID();

    if (err instanceof AppError) {
        return res.status(err.statusCode).json({
            error: {
                code: err.code,
                message: err.message,
                details: err.details,
                request_id: requestId
            }
        });
    }

    // Unknown error — don't leak internals
    console.error(`[${requestId}]`, err);
    res.status(500).json({
        error: {
            code: "INTERNAL_ERROR",
            message: "An unexpected error occurred",
            request_id: requestId
        }
    });
});

// Usage
app.post("/users", (req, res) => {
    const errors = validateUser(req.body);
    if (errors.length > 0) {
        throw new AppError(
            "VALIDATION_ERROR",
            "Invalid user data",
            400,
            errors
        );
    }
});

HTTP Status Codes That Matter

Code	When
400	Validation error, bad input
401	Not authenticated
403	Authenticated but not authorized
404	Resource not found
409	Conflict (duplicate email, version mismatch)
422	Semantically invalid (valid JSON but wrong values)
429	Rate limited
500	Server bug

Rules

Never return 200 for errors. Some APIs do 200 {"success": false} — this breaks HTTP tooling.
Never expose stack traces in production. Log them server-side with the request_id.
Use consistent error codes across your API. Document them.
Include the request_id in every response (success too). It's the fastest path from "it's broken" to "here's why".
Validate early, fail fast. Don't process half the request then error on field 7.

How does your API handle errors? I'd love to see other patterns.

Makefile cho developer: không chỉ dành cho C/C++

EME GUG — Wed, 23 Sep 2026 01:03:26 +0000

Makefile không chỉ dành cho compile C/C++. Mình dùng nó như một task runner đơn giản cho mọi dự án.

Tại sao Makefile?

Không cần cài thêm tool (có sẵn trên mọi Linux/Mac)
Tự document: make help liệt kê tất cả commands
Dependency tracking: chỉ chạy lại khi cần

Makefile cho dự án Python

.PHONY: help install test lint format run clean

help:  ## Hiện danh sách commands
    @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | \
        awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2}'

install:  ## Cài dependencies
    pip install -r requirements.txt
    pip install -r requirements-dev.txt

test:  ## Chạy tests
    pytest tests/ -v --cov=src --cov-report=term-missing

lint:  ## Check code style
    ruff check src/ tests/
    mypy src/

format:  ## Format code
    ruff format src/ tests/

run:  ## Chạy app
    python -m src.main

clean:  ## Xóa cache files
    find . -type d -name __pycache__ -exec rm -rf {} +
    find . -type f -name "*.pyc" -delete
    rm -rf .pytest_cache .mypy_cache .ruff_cache

Makefile cho dự án Node.js

.PHONY: dev build test deploy

dev:  ## Start dev server
    npm run dev

build:  ## Build production
    npm ci
    npm run build

test:  ## Run tests
    npm test

deploy: build  ## Deploy (build trước)
    rsync -avz dist/ server:/app/public/
    ssh server 'pm2 restart app'

docker-up:  ## Start Docker containers
    docker compose up -d

docker-down:  ## Stop Docker containers
    docker compose down

logs:  ## Xem logs
    docker compose logs -f --tail=100

Makefile cho dự án có Docker

IMAGE := myapp
TAG := $(shell git rev-parse --short HEAD)

build:  ## Build Docker image
    docker build -t $(IMAGE):$(TAG) .
    docker tag $(IMAGE):$(TAG) $(IMAGE):latest

push:  ## Push to registry
    docker push $(IMAGE):$(TAG)
    docker push $(IMAGE):latest

shell:  ## Shell vào container
    docker run -it --rm $(IMAGE):latest /bin/sh

db-migrate:  ## Run database migrations
    docker compose exec api python manage.py migrate

db-seed:  ## Seed database
    docker compose exec api python manage.py seed

Variables và Conditionals

ENV ?= development  # Default, có thể override: make deploy ENV=production

deploy:
ifeq ($(ENV),production)
    @echo "Deploying to PRODUCTION..."
    ./deploy.sh production
else
    @echo "Deploying to staging..."
    ./deploy.sh staging
endif

Tips

.PHONY: Khai báo targets không phải file, tránh conflict với file cùng tên
@ prefix: Ẩn command, chỉ hiện output
## comment: Dùng cho make help tự động
Tab, không space: Makefile BẮT BUỘC dùng tab để indent recipes

Bạn có dùng Makefile không? Hay prefer npm scripts / just / task runner khác?

How to write tests that actually catch bugs

EME GUG — Tue, 22 Sep 2026 16:27:34 +0000

Most test suites I've inherited test the wrong things. They have 90% coverage and still miss every real bug. Here's what I've learned about writing tests that matter.

Test Behavior, Not Implementation

// Bad: tests implementation details
test('should call database.save', () => {
    const spy = jest.spyOn(database, 'save');
    createUser({ name: 'Alice' });
    expect(spy).toHaveBeenCalledWith({ name: 'Alice', role: 'user' });
});

// Good: tests behavior
test('new users get the default role', () => {
    const user = createUser({ name: 'Alice' });
    expect(user.role).toBe('user');
});

The bad test breaks if you rename the method, change the ORM, or refactor the internals — even if the behavior is correct. The good test only breaks if the actual behavior changes.

Test Boundaries, Not Everything

┌─────────────────────┐
│   API Endpoint      │ ← Integration test
├─────────────────────┤
│   Business Logic    │ ← Unit test (pure functions)
├─────────────────────┤
│   Database Layer    │ ← Integration test
└─────────────────────┘

Unit test pure functions: validators, calculators, formatters, parsers
Integration test boundaries: API endpoints, database queries
Don't test glue code: getUser that just calls db.users.findById(id)

The 3 Tests That Catch Real Bugs

1. Edge Cases

test('handles empty cart', () => {
    expect(calculateTotal([])).toBe(0);
});

test('handles negative quantities', () => {
    expect(() => addToCart(item, -1)).toThrow('Quantity must be positive');
});

test('handles concurrent updates', async () => {
    const [result1, result2] = await Promise.all([
        updateBalance(userId, +100),
        updateBalance(userId, -50),
    ]);
    const balance = await getBalance(userId);
    expect(balance).toBe(initialBalance + 50);
});

2. Error Paths

test('returns 404 when user not found', async () => {
    const res = await request(app).get('/users/nonexistent');
    expect(res.status).toBe(404);
    expect(res.body.error.code).toBe('USER_NOT_FOUND');
});

test('retries on transient database error', async () => {
    database.query
        .mockRejectedValueOnce(new Error('connection reset'))
        .mockResolvedValueOnce({ rows: [user] });

    const result = await getUser(userId);
    expect(result).toEqual(user);
    expect(database.query).toHaveBeenCalledTimes(2);
});

3. State Transitions

test('order lifecycle', async () => {
    const order = await createOrder(items);
    expect(order.status).toBe('pending');

    await payOrder(order.id, paymentInfo);
    expect((await getOrder(order.id)).status).toBe('paid');

    await shipOrder(order.id, trackingNumber);
    expect((await getOrder(order.id)).status).toBe('shipped');

    // Can't pay a shipped order
    await expect(payOrder(order.id, paymentInfo))
        .rejects.toThrow('Cannot pay a shipped order');
});

What NOT to Test

Trivial code: Getters, setters, constructors with no logic
Framework code: Does Express routing work? Yes. Don't test it.
External services in unit tests: Mock them, or use integration tests
CSS/styling: Unless it's critical business logic (pricing display)

Test Naming

// Bad
test('test1', ...);
test('createUser', ...);

// Good: describes the scenario and expected outcome
test('createUser with duplicate email returns conflict error', ...);
test('expired tokens are rejected with 401', ...);

When a test fails, the name should tell you what broke without reading the code.

What's your testing philosophy? I'm always refining my approach.

Cách mình setup CI/CD đơn giản với GitHub Actions

EME GUG — Tue, 22 Sep 2026 09:41:01 +0000

GitHub Actions miễn phí cho public repo và có 2000 phút/tháng cho private repo. Đây là setup mình dùng cho hầu hết dự án.

Workflow cơ bản: Test + Deploy

# .github/workflows/deploy.yml
name: CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - run: npm ci
      - run: npm test
      - run: npm run lint

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /app
            git pull
            npm ci --production
            pm2 restart app

Chạy test với nhiều phiên bản

jobs:
  test:
    strategy:
      matrix:
        node-version: [18, 20, 22]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci && npm test

Cache để build nhanh hơn

      - name: Cache node_modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
          restore-keys: ${{ runner.os }}-npm-

Chạy khi có tag (release)

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

      - name: Create Release
        uses: softprops/action-gh-release@v2
        with:
          files: dist/*

Tips

Secrets: Đặt ở repo Settings → Secrets, KHÔNG hardcode trong workflow
npm ci thay npm install: nhanh hơn, deterministic
needs: test: Deploy chỉ chạy khi test pass
Branch protection: Bật required checks cho PR
Timeout: Thêm timeout-minutes: 10 tránh workflow chạy mãi

CI/CD setup của bạn trông như thế nào? Share workflow hay nhé!

Why your Docker images are too big (and how to fix it)

EME GUG — Tue, 22 Sep 2026 05:36:18 +0000

I've seen production Docker images over 2GB. For a Node.js app. That's 10x larger than it needs to be. Here's how to shrink them.

The Usual Suspect

FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]

This image: ~1.1GB. Why?

node:20 base image: ~900MB (full Debian + build tools)
node_modules with dev dependencies
Source files, .git, tests, docs all included

Fix 1: Use Alpine

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
CMD ["node", "server.js"]

Image: ~150MB. node:20-alpine is ~130MB vs ~900MB.

Fix 2: Multi-stage Build

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm ci --production && npm cache clean --force
CMD ["node", "dist/server.js"]

Image: ~100MB. Build tools and dev deps stay in the build stage.

Fix 3: .dockerignore

node_modules
.git
.env*
*.md
tests
coverage
.github
docker-compose*.yml

Without this, COPY . . copies everything — including .git (often 100MB+).

Fix 4: Order Layers for Caching

# Bad: any code change invalidates npm install cache
COPY . .
RUN npm ci

# Good: npm install only reruns when package.json changes
COPY package*.json ./
RUN npm ci --production
COPY . .

Docker caches layers. Put rarely-changing steps first.

Fix 5: Distroless (for Go, Java, Python)

# Go example
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /server .

FROM gcr.io/distroless/static
COPY --from=builder /server /server
CMD ["/server"]

Image: ~15MB. Distroless has no shell, no package manager — just your binary.

Quick Wins Summary

Technique	Typical Savings
Alpine base	-70%
Multi-stage	-30-50%
.dockerignore	-10-30%
`--production` flag	-20-40%
Distroless	-90% (compiled langs)

Checking Image Size

docker images myapp
docker history myapp:latest  # See each layer's size
docker scout quickview myapp  # CVE scan + size analysis

What's the smallest Docker image you've built? I got a Go API down to 8MB once.

Environment variables done right

EME GUG — Mon, 21 Sep 2026 22:16:29 +0000

I've seen API keys committed to Git, .env files with 50+ variables, and production secrets stored in plain text files. Here's how to manage environment variables properly.

The Basics

# .env file (development only)
DATABASE_URL=postgresql://localhost:5432/mydb
REDIS_URL=redis://localhost:6379
API_KEY=dev_key_123
PORT=3000

// Load with dotenv (Node.js)
require('dotenv').config();
const dbUrl = process.env.DATABASE_URL;

Rule #1: .env goes in .gitignore. Always.

Structure Your Variables

# .env.example (committed to Git — no real values)
DATABASE_URL=
REDIS_URL=
API_KEY=
PORT=3000

# .env.development
DATABASE_URL=postgresql://localhost:5432/mydb_dev

# .env.test
DATABASE_URL=postgresql://localhost:5432/mydb_test

# .env.production (never in Git)
DATABASE_URL=postgresql://prod-host:5432/mydb_prod

Validation at Startup

Don't wait for the first database call to discover DATABASE_URL is missing.

// config.js
const required = ['DATABASE_URL', 'REDIS_URL', 'API_KEY'];
const missing = required.filter(key => !process.env[key]);

if (missing.length > 0) {
    console.error(`Missing env vars: ${missing.join(', ')}`);
    process.exit(1);
}

module.exports = {
    db: process.env.DATABASE_URL,
    redis: process.env.REDIS_URL,
    apiKey: process.env.API_KEY,
    port: parseInt(process.env.PORT || '3000'),
    isDev: process.env.NODE_ENV !== 'production',
};

Secrets Management (Production)

Option 1: Platform secrets

# GitHub Actions
env:
  API_KEY: ${{ secrets.API_KEY }}

# Docker Compose
services:
  app:
    environment:
      - API_KEY=${API_KEY}  # From host environment

Option 2: Vault/AWS Secrets Manager

import boto3

def get_secret(name):
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId=name)
    return json.loads(response['SecretString'])

secrets = get_secret('myapp/production')
db_url = secrets['DATABASE_URL']

Option 3: Encrypted .env

# Encrypt
gpg --symmetric --cipher-algo AES256 .env.production
# Creates .env.production.gpg (safe to commit)

# Decrypt
gpg --decrypt .env.production.gpg > .env.production

Common Mistakes

Default values for secrets: API_KEY || 'default' — fails silently in production
Logging env vars: console.log(config) — prints secrets to log files
Different names across environments: DB_URL vs DATABASE_URL vs DB_CONNECTION_STRING
Putting non-secrets in env vars: App name, feature flags → use config files instead

Docker

# Bad: bakes secrets into image layer
ENV API_KEY=secret123

# Good: pass at runtime
# docker run -e API_KEY=secret123 myapp
# or: docker run --env-file .env myapp

How do you manage secrets in production? Always curious about different setups.

WebSocket vs Server-Sent Events: choosing the right tool

EME GUG — Mon, 21 Sep 2026 00:46:04 +0000

Not every real-time feature needs WebSocket. Here's how to pick the right technology.

Quick Comparison

	WebSocket	SSE
Direction	Bidirectional	Server → Client only
Protocol	ws://	HTTP
Reconnection	Manual	Automatic
Binary data	Yes	No (text only)
Browser support	All modern	All modern
Through proxies	Sometimes issues	Works everywhere
Complexity	Higher	Lower

Server-Sent Events (SSE)

Perfect for: notifications, live feeds, dashboards, progress bars.

Server (Node.js)

app.get('/events', (req, res) => {
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive',
    });

    const sendEvent = (data) => {
        res.write(`data: ${JSON.stringify(data)}\n\n`);
    };

    // Send initial data
    sendEvent({ type: 'connected', time: Date.now() });

    // Send updates
    const interval = setInterval(() => {
        sendEvent({ type: 'update', value: Math.random() });
    }, 1000);

    req.on('close', () => {
        clearInterval(interval);
    });
});

Client

const source = new EventSource('/events');

source.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('Received:', data);
};

source.onerror = () => {
    console.log('Connection lost, reconnecting...');
    // EventSource reconnects automatically!
};

That's it. No library needed. Auto-reconnection built in.

WebSocket

Perfect for: chat, gaming, collaborative editing, trading platforms.

Server (ws library)

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
    ws.on('message', (message) => {
        const data = JSON.parse(message);

        // Broadcast to all clients
        wss.clients.forEach((client) => {
            if (client.readyState === WebSocket.OPEN) {
                client.send(JSON.stringify({
                    user: data.user,
                    message: data.message,
                    time: Date.now()
                }));
            }
        });
    });

    ws.on('close', () => {
        console.log('Client disconnected');
    });
});

Client

const ws = new WebSocket('ws://localhost:8080');

ws.onopen = () => {
    ws.send(JSON.stringify({ user: 'Alice', message: 'Hello!' }));
};

ws.onmessage = (event) => {
    const data = JSON.parse(event.data);
    displayMessage(data);
};

// Manual reconnection needed
ws.onclose = () => {
    setTimeout(() => {
        // Reconnect logic here
    }, 1000);
};

Decision Framework

Do you need client → server communication?
├── Yes → Do you need it frequently (>1/sec)?
│   ├── Yes → WebSocket
│   └── No → SSE + regular HTTP POST
└── No → SSE

Use SSE when:

Server pushes updates to client
Client actions use normal HTTP requests
You want simplicity and auto-reconnection
Examples: stock ticker, notifications, live scores

Use WebSocket when:

Both sides send messages frequently
Low latency matters (<50ms)
Binary data needed
Examples: multiplayer games, chat, live collaboration

The Hybrid Approach

Most apps benefit from combining both:

// SSE for real-time updates (notifications, feed)
const events = new EventSource('/api/events');

// Regular HTTP for user actions
async function sendMessage(text) {
    await fetch('/api/messages', {
        method: 'POST',
        body: JSON.stringify({ text })
    });
    // Server broadcasts via SSE to all connected clients
}

Simpler than WebSocket, works through all proxies, auto-reconnects.

What do you use for real-time features? WebSocket, SSE, or something else?

Redis beyond caching: 5 use cases you should know

EME GUG — Sun, 20 Sep 2026 01:45:59 +0000

Most developers know Redis as a cache. But it's capable of much more. Here are 5 patterns I use in production.

1. Rate Limiting

import redis

r = redis.Redis()

def is_rate_limited(user_id, limit=100, window=60):
    key = f"rate:{user_id}"
    current = r.incr(key)
    if current == 1:
        r.expire(key, window)
    return current > limit

Simple, atomic, and fast. No database queries needed.

2. Distributed Locks

When multiple workers might process the same job:

import redis

r = redis.Redis()

def acquire_lock(name, timeout=10):
    return r.set(f"lock:{name}", "1", nx=True, ex=timeout)

def release_lock(name):
    r.delete(f"lock:{name}")

# Usage
if acquire_lock("process-order-123"):
    try:
        process_order(123)
    finally:
        release_lock("process-order-123")

nx=True means "set only if not exists" — atomic mutex.

3. Real-time Leaderboard

# Add scores
r.zadd("leaderboard", {"player_a": 1500, "player_b": 2100, "player_c": 1800})

# Top 10 players
top_10 = r.zrevrange("leaderboard", 0, 9, withscores=True)

# Player rank
rank = r.zrevrank("leaderboard", "player_a")  # 0-indexed

# Update score atomically
r.zincrby("leaderboard", 50, "player_a")

Sorted sets handle millions of entries with O(log N) operations.

4. Pub/Sub for Real-time Events

# Publisher
r.publish("notifications", json.dumps({
    "user_id": 123,
    "message": "New order received"
}))

# Subscriber
pubsub = r.pubsub()
pubsub.subscribe("notifications")

for message in pubsub.listen():
    if message["type"] == "message":
        data = json.loads(message["data"])
        send_push_notification(data)

Lightweight alternative to Kafka/RabbitMQ for simple event streaming.

5. Session Storage

from flask import Flask, session
from flask_session import Session

app = Flask(__name__)
app.config["SESSION_TYPE"] = "redis"
app.config["SESSION_REDIS"] = redis.Redis(host="localhost")
Session(app)

@app.route("/login")
def login():
    session["user_id"] = 123  # Stored in Redis, not cookies

Advantages over cookie-based sessions:

Server-side: can't be tampered with
Shared across instances (horizontal scaling)
Easy to invalidate: just delete the key

When NOT to use Redis

Primary database: Redis is in-memory, data loss risk on crash (even with AOF)
Large objects: Keep values under 1MB
Complex queries: No SQL, limited filtering

What's your favorite Redis use case? I'm curious what patterns work for others.

Understanding async/await pitfalls in JavaScript

EME GUG — Sat, 19 Sep 2026 01:40:56 +0000

Async/await makes asynchronous code look synchronous. But that simplicity hides pitfalls that can cause bugs, memory leaks, and performance issues.

Pitfall 1: Sequential When You Mean Parallel

// Slow: 2 seconds (sequential)
const users = await getUsers();
const orders = await getOrders();

// Fast: 1 second (parallel)
const [users, orders] = await Promise.all([
    getUsers(),
    getOrders()
]);

If two operations don't depend on each other, run them in parallel.

Pitfall 2: Unhandled Rejections

// Bad: if getUser throws, the error silently disappears
async function loadDashboard() {
    getUser(123).then(u => updateUI(u));  // No await, no catch
}

// Good: handle the error
async function loadDashboard() {
    try {
        const user = await getUser(123);
        updateUI(user);
    } catch (err) {
        showError(err);
    }
}

In Node.js, unhandled rejections crash the process (as of Node 15+).

Pitfall 3: Async in forEach

// BROKEN: forEach doesn't await
const ids = [1, 2, 3];
ids.forEach(async (id) => {
    await processItem(id);  // These run in parallel, not sequential
});
console.log('Done!');  // Runs before processing finishes

// Fix: for...of for sequential
for (const id of ids) {
    await processItem(id);
}

// Fix: Promise.all for parallel
await Promise.all(ids.map(id => processItem(id)));

Pitfall 4: Async Constructor Trap

// Can't use async constructor
class Database {
    constructor() {
        // This doesn't work as expected
        this.connection = await connect();  // SyntaxError
    }
}

// Fix: factory function
class Database {
    static async create() {
        const db = new Database();
        db.connection = await connect();
        return db;
    }
}

const db = await Database.create();

Pitfall 5: Error Swallowing in Promise.all

// If one fails, all results are lost
try {
    const results = await Promise.all([
        fetchUser(1),    // succeeds
        fetchUser(999),  // fails
        fetchUser(2),    // succeeds but result lost
    ]);
} catch (err) {
    // Only get the first error, lose all successful results
}

// Fix: Promise.allSettled
const results = await Promise.allSettled([
    fetchUser(1),
    fetchUser(999),
    fetchUser(2),
]);

results.forEach((result, i) => {
    if (result.status === 'fulfilled') {
        console.log(`User ${i}: ${result.value.name}`);
    } else {
        console.log(`User ${i} failed: ${result.reason}`);
    }
});

Pitfall 6: Awaiting Non-Promises

// Works but unnecessary overhead
const x = await 42;  // Wraps in Promise.resolve(42)
const y = await someObj;  // Wraps non-thenable

// This matters in loops
for (const item of items) {
    const result = await syncFunction(item);  // Don't await sync functions
}

Pitfall 7: Missing Return in Async

// Subtle bug: returns undefined, not the user
async function getUser(id) {
    const user = await db.findUser(id);
    if (!user) throw new NotFoundError();
    user;  // Oops, forgot 'return'
}

The async/await Checklist

Independent operations? → Promise.all
Need all results even if some fail? → Promise.allSettled
Iterating async? → for...of, never forEach
Error handling? → try/catch at boundaries
Cleanup needed? → try/finally

What async bug have you spent the most time debugging?

Tại sao mình chuyển từ REST sang GraphQL (và khi nào không nên)

EME GUG — Thu, 17 Sep 2026 22:40:25 +0000

Mình dùng REST 5 năm trước khi thử GraphQL. Đây là những gì mình học được — cả ưu và nhược.

Vấn đề với REST

Over-fetching

GET /api/users/123
→ Trả về 30 fields, frontend chỉ cần name + avatar

Under-fetching

GET /api/posts/456        → Lấy bài viết
GET /api/users/123        → Lấy tác giả
GET /api/posts/456/comments → Lấy comments
→ 3 requests cho 1 trang

Version hell

/api/v1/users
/api/v2/users  (thêm field mới)
/api/v3/users  (đổi format)

GraphQL giải quyết thế nào

query {
    post(id: "456") {
        title
        content
        author {
            name
            avatar
        }
        comments(first: 10) {
            text
            createdAt
        }
    }
}

1 request, lấy đúng data cần. Không over-fetch, không under-fetch.

Setup (Node.js + Apollo)

const { ApolloServer } = require('@apollo/server');

const typeDefs = `
    type User {
        id: ID!
        name: String!
        email: String!
        posts: [Post!]!
    }

    type Post {
        id: ID!
        title: String!
        author: User!
    }

    type Query {
        user(id: ID!): User
        posts(limit: Int): [Post!]!
    }

    type Mutation {
        createPost(title: String!, content: String!): Post!
    }
`;

const resolvers = {
    Query: {
        user: (_, { id }) => getUserById(id),
        posts: (_, { limit }) => getPosts(limit),
    },
    User: {
        posts: (user) => getPostsByUserId(user.id),
    },
};

Khi nào GraphQL tốt hơn REST?

✅ Dùng GraphQL khi:

Frontend cần flexibility (mobile vs web cần data khác nhau)
Quan hệ data phức tạp (social network, e-commerce)
Nhiều team cùng dùng API
Tránh over-fetching quan trọng (mobile, bandwidth thấp)

❌ Giữ REST khi:

API đơn giản, ít endpoints
File upload (GraphQL hỗ trợ nhưng phức tạp)
Caching đơn giản (REST dùng HTTP cache, GraphQL phải dùng client cache)
Team nhỏ, product đơn giản
Microservices giao tiếp nội bộ

Nhược điểm GraphQL (thật sự)

1. N+1 Query Problem

query {
    posts {      # 1 query
        author { # N queries (mỗi post 1 query lấy author)
            name
        }
    }
}

Fix: DataLoader

const DataLoader = require('dataloader');

const userLoader = new DataLoader(async (ids) => {
    const users = await User.findAll({ where: { id: ids } });
    return ids.map(id => users.find(u => u.id === id));
});

2. Caching khó hơn

REST: GET /users/123 → HTTP cache tự nhiên.
GraphQL: Mọi request đều POST → phải dùng client-side cache (Apollo Client).

3. Error handling phức tạp

REST: HTTP status code nói rõ lỗi gì.
GraphQL: Luôn trả 200, lỗi nằm trong errors array.

Kết luận

GraphQL không thay thế REST. Nó giải quyết problems khác. Chọn tool phù hợp với problem của bạn.

Bạn dùng REST hay GraphQL? Hay cả hai?

Nginx reverse proxy: từ zero đến production

EME GUG — Thu, 17 Sep 2026 01:10:43 +0000

Nginx là reverse proxy phổ biến nhất. Bài này từ setup cơ bản đến các config production mình đang dùng.

Cài đặt

# Ubuntu/Debian
sudo apt install nginx

# Kiểm tra
sudo nginx -t
sudo systemctl start nginx

Reverse Proxy cơ bản

# /etc/nginx/sites-available/myapp
server {
    listen 80;
    server_name myapp.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

HTTPS với Let's Encrypt

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d myapp.com

Certbot tự thêm SSL config và auto-renew.

Load Balancing

upstream backend {
    least_conn;  # Chọn server ít connection nhất
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
}

server {
    listen 80;
    server_name myapp.com;

    location / {
        proxy_pass http://backend;
    }
}

Các algorithm: round-robin (mặc định), least_conn, ip_hash (sticky session).

Caching static files

server {
    location /static/ {
        alias /app/public/;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 7d;
        add_header Cache-Control "public";
    }
}

Rate Limiting

# Định nghĩa zone
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
    }
}

10 request/giây/IP, cho phép burst 20 request.

WebSocket

location /ws {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400;
}

Security headers

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'" always;

Monitoring

location /nginx_status {
    stub_status on;
    allow 127.0.0.1;
    deny all;
}

Config Nginx nào bạn thấy hữu ích nhất? Share nhé!

Tmux cho developer: làm việc hiệu quả hơn trên terminal

EME GUG — Wed, 16 Sep 2026 01:34:45 +0000

SSH vào server, chạy một process dài, rồi terminal disconnect — process chết. Tmux giải quyết vấn đề này và nhiều hơn thế.

Cài đặt

# Ubuntu/Debian
sudo apt install tmux

# macOS
brew install tmux

3 Khái niệm cơ bản

Session: Một workspace hoàn chỉnh, tồn tại kể cả khi disconnect
Window: Tab trong session
Pane: Chia đôi/ba/bốn một window

Cheat sheet

# Session
tmux new -s dev          # Tạo session tên "dev"
tmux ls                  # Liệt kê sessions
tmux attach -t dev       # Attach lại session
tmux kill-session -t dev # Xóa session

Prefix key mặc định: Ctrl+b (viết tắt: C-b)

C-b d    → Detach (thoát mà giữ session)
C-b c    → Tạo window mới
C-b n    → Window tiếp
C-b p    → Window trước
C-b 0-9  → Chuyển đến window N
C-b %    → Chia pane dọc
C-b "    → Chia pane ngang
C-b o    → Chuyển pane
C-b x    → Đóng pane
C-b z    → Zoom pane (toggle full screen)

Setup làm việc điển hình

# Tạo session với layout sẵn
tmux new-session -d -s work
tmux send-keys -t work 'cd ~/project && vim' Enter
tmux split-window -h -t work
tmux send-keys -t work 'cd ~/project' Enter
tmux split-window -v -t work
tmux send-keys -t work 'htop' Enter
tmux attach -t work

Kết quả: 3 panes — editor bên trái, terminal phải trên, htop phải dưới.

Config hữu ích (`~/.tmux.conf`)

# Đổi prefix từ C-b sang C-a (dễ bấm hơn)
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Mouse support
set -g mouse on

# Bắt đầu đánh số từ 1 (thay vì 0)
set -g base-index 1
setw -g pane-base-index 1

# Chia pane dễ nhớ hơn
bind | split-window -h -c "#{pane_current_path}"
bind - split-window -v -c "#{pane_current_path}"

# Reload config
bind r source-file ~/.tmux.conf \; display "Config reloaded!"

# Vi mode cho copy
setw -g mode-keys vi

# Tăng history
set -g history-limit 10000

Tmux + SSH = Không mất session

# SSH vào server
ssh server

# Tạo tmux session
tmux new -s deploy

# Chạy deploy script
./deploy.sh

# Detach (C-b d) rồi disconnect SSH
# Ngày hôm sau:
ssh server
tmux attach -t deploy
# Session vẫn còn, output vẫn ở đó

Tmux Resurrect (bonus)

Plugin giữ lại sessions kể cả khi reboot:

# Cài TPM (Tmux Plugin Manager)
git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

# Thêm vào ~/.tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'

C-b Ctrl+s save, C-b Ctrl+r restore.

Bạn dùng tmux hay screen? Có tip nào hay không?