DEV Community: Pau Dang

Playwright vs Cucumber: The Ultimate Developer's Guide to Modern Testing

Pau Dang — Sat, 13 Jun 2026 02:29:22 +0000

Let's be real: Behavior-Driven Development (BDD) looked great on paper. The idea of writing tests in plain English (Given, When, Then) using Cucumber so that your Product Owner could read them was a beautiful dream.

But if we are honest, how often does your PO actually read those .feature files?

For developers, Cucumber often feels like an unnecessary abstraction. You have to maintain two layers of files, context sharing between steps gets weird, and debugging can be a pain.

If you just want to ship code and know that your app works without the BDD overhead, say hello to Playwright.

The "Aha!" Moment: Let's Look at the Code

Let's say we want to test a simple login page.

The Cucumber Way (Painful):

# login.feature
Feature: Login
  Scenario: User can login
    Given I navigate to the login page
    When I type "admin" in the username field
    And I click the submit button

// steps.js
Given('I navigate to the login page', async () => { /* code */ });
When('I type {string} in the username field', async (user) => { /* code */ });
// Imagine doing this for 500 different actions...

The Playwright Way (Beautiful):

test('User can login', async ({ page }) => {
  await page.goto('https://myapp.com/login');
  await page.getByLabel('Username').fill('admin');
  await page.getByRole('button', { name: 'Submit' }).click();
});

One file. Strong typing. Auto-completion in VS Code. It just makes sense.

Why Playwright is Technically Superior

Here is a deep dive into why Playwright is dominating the testing space right now.

The Complete Workflow: From Engine to Report

Before we dive into the specific features, let's look at the entire lifecycle of a Playwright test. Understanding this flow is key to understanding why it's so fast and reliable:

1. Bi-directional Architecture (No more HTTP latency!)

Older frameworks like Selenium use the WebDriver protocol. Every command (like clicking a button) is sent as an HTTP request. This is slow and prone to timing issues.

Playwright connects directly to the browser engine using WebSockets (via Chrome DevTools Protocol - CDP). Playwright instantly knows when a network request fires or when the DOM changes.

2. Auto-Waiting (Goodbye `sleep()`... mostly)

Flaky tests are the enemy of CI/CD.
Playwright has built-in Actionability Checks. Before it clicks a button, it automatically ensures the button is:

Attached to the DOM
Visible
Stable (not jumping around due to CSS animations)

This eliminates 99% of the need for hardcoded sleep statements. While Playwright still provides await page.waitForTimeout() for specific edge cases (like waiting for an unpredictable third-party API or backend cron job), for standard UI interactions, it just waits intelligently.

3. Browser Contexts (Fast Isolation)

Launching a browser is expensive. Playwright solves this with Browser Contexts.
Think of a Context as a lightning-fast Incognito window. Playwright launches the browser binary once, and then spins up a new isolated Context for each test case in milliseconds. Clean cookies, clean local storage, zero cross-test pollution.

The Game Changer: Trace Viewer

If you take away one thing from this article, let it be this. Trace Viewer

When your test fails on GitHub Actions, Playwright outputs a Trace file. You download it, run npx playwright show-trace, and you get a full time-travel GUI:

A DOM snapshot (the actual DOM you can inspect!) for every single action.
Network requests, console logs, and source code mapping.

It's literally a DVR for your test failures.

The Verdict: Cucumber vs Playwright

It's important to remember that Cucumber isn't a bad tool—it just solves a different problem. Cucumber is a collaboration tool designed to bridge the gap between business stakeholders and developers using plain English. If your Product Owners are actively involved in writing and reviewing .feature files, Cucumber is doing exactly what it was built for.

However, if your E2E tests are strictly an engineering endeavor—written by devs, for devs—that Gherkin layer becomes an unnecessary translation burden. Playwright removes that friction, offering incredible speed, modern architecture, and debugging tools that actually make sense to engineers.

Are you team Cucumber or team Playwright? Drop your thoughts in the comments below!

How We Prevented Cascading Failures in our Node.js Microservices (Timeout, Retry, Circuit Breaker)

Pau Dang — Mon, 08 Jun 2026 08:00:00 +0000

Have you ever seen a massive, scalable architecture crash just because an internal email service took too long to reply?

In the world of backend engineering, we often focus on SQL Injection, XSS, or zero-day exploits. However, one of the most devastating issues you'll face isn't a complex buffer overflow—it's an Application-Layer Denial of Service (DoS) that turns your own microservices against each other.

Welcome to the concept of Cascading Failures. Today, we're diving into how this happens in Node.js, and how you can implement the "Resilience Trio" (Timeout, Retry, Circuit Breaker) to stop it.

The Scenario: The Weakest Link

Imagine an e-commerce platform built on a robust Node.js microservices architecture. The front-facing API Gateway is protected by a WAF and Rate Limiting.

However, deep inside the system, the core OrderService communicates with a low-priority, internal EmailNotificationService to send order receipts.

An attacker (or even just a massive spike in traffic) hits the API. The API Gateway handles it fine. But the EmailNotificationService gets overwhelmed and starts slowing down.

The System Collapse

Here is where the vulnerability lies: Unbounded Promises and Infinite Waits.

Node.js handles non-blocking I/O brilliantly. But if the OrderService calls a dying EmailNotificationService and awaits a response without a strict Timeout, the connection hangs.

Connection Exhaustion: Hundreds of requests to the OrderService are stuck in a PENDING state.
Resource Starvation: Memory usage spikes. The connection pool to the database is tied up by pending transactions.
The Domino Effect: OrderService runs out of RAM, stops responding to the API Gateway. The Gateway queues up requests until it too crashes.

The entire e-commerce platform goes offline just because an email service was slow.

The Defense: The Resilience Trio

To prevent your system from being its own worst enemy, you must adopt a "Zero Trust" mindset regarding internal network calls: assume every downstream service will eventually fail or hang.

We implement defense-in-depth using three core patterns.

The Prevention Flow

1. The Shield: Timeout

Never trust the default HTTP timeout (which can be minutes). You must enforce strict application-level timeouts.

export const withTimeout = <T>(promise: Promise<T>, ms: number): Promise<T> => {
    return Promise.race([
        promise,
        new Promise<T>((_, reject) => setTimeout(() => reject(new Error('Operation Timed Out')), ms))
    ]);
};

Impact: When the Email service hangs, withTimeout forcefully severs the connection after a few seconds, freeing up memory and DB connections.

2. The Shock Absorber: Exponential Backoff

When a timeout occurs, naive systems immediately retry the request. This leads to a Retry Storm (The Thundering Herd Problem), effectively DDoS-ing the recovering downstream service.

// Conceptual Exponential Backoff with Jitter
const delay = Math.pow(2, attempt) * 1000 + Math.random() * 1000;
await sleep(delay);

Impact: By adding exponential backoff and jitter (randomness), the retry traffic is smoothed out, giving the downstream service breathing room to recover.

3. The Kill Switch: Circuit Breaker

If a service is under attack, sending any traffic to it is dangerous. The Circuit Breaker monitors the failure rate. If it crosses a critical threshold, the circuit "Trips" (opens).

if (circuitBreaker.isOpen()) {
    throw new Error('Circuit is OPEN - Fast Failing');
}

Impact: When the Circuit Breaker trips, the OrderService instantly returns a "Graceful Degradation" response (e.g., "Order placed, email will be sent later") without even attempting a TCP connection.

Stop Writing Boilerplate

Implementing this "Resilience Trio" correctly from scratch is tedious. One wrong configuration in the Retry logic, and you've built a DDoS cannon into your own system.

That's why we integrated these enterprise-grade patterns directly into our open-source CLI: Nodejs Quickstart Generator.

With our AI-ready CLI, you can automatically generate over 1.06M unique project architectures:

Architecture: Clean Architecture or MVC
Language: TypeScript or JavaScript
Databases: MySQL, PostgreSQL, MongoDB
Security & Resilience: Helmet, CORS, Snyk integration, and the full Timeout, Retry, Circuit Breaker trio out-of-the-box!
Infrastructure: Terraform configurations (Single EC2 up to High Availability WAF + ALB)

Try it out today and generate an enterprise-grade, resilient backend in under 60 seconds:

npx nodejs-quickstart-structure@latest init -n "nodejs-service" -l "TypeScript" -a "Clean Architecture" -d "MySQL" --db-name "demo" -c "REST APIs" --caching "None" --ci-provider "GitHub Actions" --auth JWT --terraform None --no-include-security --resilience Timeout Retry CircuitBreaker --advanced-options

If this tool saves you hours of setup, please give us a Star on GitHub! ⭐

Stay secure, build resiliently, and never let the weakest link bring you down.

I Replaced a Costly LLM API with a 100% Offline NLP Engine (And Achieved 0ms Latency)

Pau Dang — Tue, 02 Jun 2026 08:00:00 +0000

Why building a Domain-Specific Rule-Based Engine natively in JavaScript was the best architectural decision for my open-source project.

🔗 Live Demo: nodejs-quickstart-generator.netlify.app

If you are building an open-source project in 2024, there is an unspoken pressure to slap an OpenAI API key on it and call it "AI-powered."

For my latest project—an advanced Node.js architecture scaffolding tool, I wanted users to be able to configure their microservices using natural language. For example: "Give me a Clean Architecture project using TypeScript, PostgreSQL, and Kafka, but I don't need any CI/CD."

The industry standard solution? Send that prompt to an LLM, wait 3-5 seconds, and parse the JSON response.

But when I looked at the realities of deploying this to thousands of users, I hit a massive wall:

The Cost of "Hype AI": As an open-source maintainer, swallowing API costs for every user prompt is financial suicide.
Network Latency: Waiting 3-5 seconds for an API call destroys the instantaneous, snappy feel of a modern web tool.
The Hallucination Danger: When configuring software architecture (like Terraform scripts or database orchestrations), a single hallucinated setting can break the entire project. I needed 100% deterministic outputs, not creative guesses.

So, I threw away the LLM approach. Instead, I built a Domain-Specific Rule-Based AI Engine that runs entirely on the Client-side (Browser).

Here is how I achieved 0ms latency and $0 operating costs without sacrificing natural language understanding.

The Core Mechanism: Moving from Cloud to Browser

Instead of relying on deep learning models, the engine operates on highly optimized, mathematically verified principles. It is built natively in JavaScript and ships directly to the browser.

1. Lean Regex & The "Code-Switching" Beast

My user base is global. They don't just speak English; they mix English with Vietnamese, Japanese, Chinese, and Hindi—often in the same sentence (a phenomenon known as code-switching).

Instead of training a model on 50 languages, I mapped the technical intents and negative patterns across multiple languages using highly refined Regular Expressions.

Look at how the engine handles negations: Github

// Forward-facing negation check (Up to 30 chars before the match)
const isNegativeBefore = /(?:no|without|không|khong|don't|dont|skip|remove|ko|đừng|khỏi|不要|不|无|没|bina)\s*$/i.test(beforeText.trim());

// Backward-facing negation check (Needed for Japanese 'なし' / Hindi 'nahi')
const isNegativeAfter = /^\s*(?:は|が|を)?\s*(?:nahi|なし|ない|いらない)/i.test(afterText);

Whether a user types "không dùng db" (Vietnamese), "no database" (English), or "不要 db" (Japanese), the engine parses it identically. It acts as a relentless technical tokenizer that extracts precisely what is needed while actively sanitizing inputs to neutralize XSS risks.

2. The Deterministic State Machine (Mapping 1 Million States)

Asking an AI to generate code from scratch is risky. Instead, my NLP engine maps the user's intent directly into a Deterministic State Machine.

The underlying scaffolding system has exactly 1,064,448 mathematically verified architectural states (combinations of Databases, Message Brokers, Cloud Providers, etc.).

The NLP engine evaluates the extracted technical keywords against this pre-defined logical matrix. It securely selects the exact, verified configuration. There are no "maybe"s, no hallucinations—only absolute precision.

The Ultimate Result: Fast, Free, and Flawless

By stepping off the LLM hype train and engineering a Local Heuristic NLP Engine, the results were staggering:

0ms Response Time: Parsing happens locally in the user's browser instantaneously.
$0 Permanent Operating Cost: No API keys, no server computing costs, no rate limits.
Absolute Privacy: No user prompts or architectural choices are ever sent to a third-party server.
100% Offline-Capable: You can literally unplug your router, load the cached PWA, and the natural language engine will continue to parse prompts flawlessly.

The Takeaway

Large Language Models are incredible tools for generative and creative tasks. But for domain-specific, deterministic routing, we often over-engineer. Sometimes, the most elegant, scalable, and cost-effective AI is the one you build with strict rules, clever regex, and zero server dependencies.

Experience the 0ms offline NLP engine yourself: Try out the newly released v2.6.0 Web UI at the Node.js Quickstart Generator.

Production-Ready Logging: An Agnostic ELK Stack Setup for Node.js (with a 512MB RAM Local Constraint)

Pau Dang — Mon, 01 Jun 2026 00:53:34 +0000

The Logging Nightmare

Deploying microservices across Multi-Cloud environments using tools like Terraform is an exhilarating milestone. But the moment something breaks, that excitement quickly turns into a nightmare.

The SSH Grind: If you find yourself SSH-ing into disparate instances just to run tail -f and grep through scattered log files, you're doing it wrong.
The Agnostic Approach: The industry standard demands Centralized Logging, but chaining your application to vendor-specific solutions like AWS CloudWatch or GCP Cloud Logging limits your architectural freedom. Implementing a true "Cloud-Agnostic" ELK stack gives you back control over your observability data.

Clean Architecture & The Non-Blocking Logger Factory

Building this robust observability pipeline requires adhering to Clean Architecture principles, specifically through a Non-Blocking Logger Factory.

Standardized Interface: By wrapping modern logging libraries like Winston or Pino, we standardize our application's logging interface.
The Secret Sauce: The winston-elasticsearch transport module buffers your logs and pushes them directly to your Elasticsearch cluster in the background.
Non-Blocking: This architectural choice is crucial: it ensures that high-volume log streaming happens without blocking the Node.js event loop.

Here is how the data flows through the system:

Resilience Fallback (The Failsafe)

A centralized system introduces a dangerous dependency. Your logging infrastructure must never be the reason your application crashes.

The Threat: If the remote Elasticsearch cluster is unreachable due to network partitions or rate limits, a poorly configured logger will throw uncaught exceptions, bringing down the app.
The Solution: We implement a strict Resilience Fallback (Failsafe) mechanism. The transport module safely catches the connection errors and seamlessly falls back to standard output (console), guaranteeing continuous operation.

The 512MB Local-Test Challenge

While this setup is a powerhouse in production, it presents a massive Developer Experience (DX) challenge locally. Elasticsearch is notorious for claiming 4GB to 8GB of RAM. Spinning up ELK locally on standard laptops is a guaranteed way to freeze the OS.

The "Aha!" Moment for Local Dev: We can tame the JVM by strictly limiting its memory footprint in the docker-compose.elk.yml configuration:

version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.10.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - ES_JAVA_OPTS="-Xms512m -Xmx512m"

Limiting Heap Size: ES_JAVA_OPTS="-Xms512m -Xmx512m" limits the Elasticsearch heap size to exactly 512MB, keeping your local dev environment snappy.
Frictionless Auth: Setting xpack.security.enabled=false removes the friction of managing certificates and passwords on your local machine.

Cloud Deployment Strategy

When transitioning to Production, your strategy must shift dramatically:

Managed Services: The strongly recommended approach is to leverage Managed Services like AWS OpenSearch or Elastic Cloud.
Self-Hosted Reality: If you must Self-Host on EC2 or GCP, you need at least 4GB of RAM (e.g., t3.medium/e2-medium). You must enable xpack.security, enforce TLS, and strictly firewall port 9200 from the public internet.

Conclusion

Achieving a balance between robust production observability and a frictionless, lightweight developer experience is the hallmark of mature software engineering.

I'd love to hear how you handle logging in your own microservices—drop a comment below! If you want to explore a project structure that supports this architecture out-of-the-box, check out the official docs for the Node.js Quickstart Generator - Observability (ELK Stack).

Try it yourself:

YouTube Guide: Watch the walkthrough
GitHub: nodejs-quickstart-structure
Author: Pau Dang (Senior SE).

How We Built a Node.js Scaffolding Engine with Over 1 Million Mathematically Verified Architecture States

Pau Dang — Sat, 30 May 2026 04:04:26 +0000

The Scaffolding Fatigue

Setting up an Enterprise-grade Node.js project from scratch is notoriously time-consuming. Development teams often spend days or weeks on configuration before writing any business logic.

The Pain Point: Configuring linting, testing frameworks, CI/CD pipelines, Docker environments, and logging systems repeatedly for every new microservice.
The Old Solution: Traditional "boilerplates". These quickly become outdated, bloated, or overly opinionated, forcing developers to untangle pre-written code.
The New Approach: We shifted away from static repositories and built a Dynamic Scaffolding Engine—a system capable of generating tailored, up-to-date architectures on demand.

The Mathematical Matrix

The true scale of this engine lies in the underlying mathematics of architectural combinations. Our system operates on a precise formula:

Core Stack (6,048) x DevOps Multiplier (176) = 1,064,448 States

This isn't an arbitrary number. Here is how it breaks down:

Core Stack: Represents the foundational application layer. This includes choices between TypeScript/JavaScript, MVC or Clean Architecture patterns, various ORMs (Prisma, TypeORM, Sequelize), and Message Brokers (RabbitMQ, Kafka).
DevOps Multiplier: Layers on infrastructure configurations, covering cloud providers (AWS, GCP, Azure), containerization (Docker, Kubernetes), and Infrastructure as Code (Terraform).

The crucial distinction is that these 1,064,448 combinations are not random, unverified pairings. Every single state represents a mathematically verified architecture where the chosen components integrate flawlessly.

Architecture Integrity & Decoupling

Managing a million potential architectural states presents a monumental technical challenge: preventing dependency hell and avoiding broken code.

Decoupled Modules: We organized our templating system so that complex modules (e.g., Kafka event streaming, Multi-Cloud Terraform configurations, ELK stack observability) are completely isolated.
Dynamic Injection: When a developer selects advanced options, the engine intelligently injects the required configurations into the base template.
Zero Silent Crashes: This dynamic injection ensures variables, dependencies, and environment files are orchestrated perfectly, eliminating the risk of silent code crashes ("crash code ngầm").

The 80% Coverage Policy

Generating code is the easy part; generating production-ready code is significantly harder.

Strict Quality Control: We enforce a strict 80% minimum test coverage policy across all generated scenarios.
Run-Ready Assets: This ensures the engine doesn't merely spit out an empty skeleton. The output is a clean, run-ready production asset complete with passing tests, giving teams the confidence to deploy immediately.

Conclusion

By transitioning from manual, error-prone setups to automated, scalable architecture generation, development teams can reclaim hundreds of engineering hours. The engine transforms a tedious week-long task into a few clicks start Generator.

Try it yourself:

YouTube Guide: Watch the walkthrough
GitHub: nodejs-quickstart-structure
Author: Pau Dang (Senior SE).

Stop Wrestling with AWS: I Built a Tool to Generate Production-Ready Node.js & Terraform

Pau Dang — Thu, 21 May 2026 03:31:19 +0000

A deep dive into how I automated setting up Node.js backends and AWS infrastructure using Terraform.

If you’re anything like me, starting a new project is the most exciting part of development. You get to choose your architecture, set up your folders, and start writing code.

But then comes the deployment phase...

Suddenly, you're wrestling with the AWS Console. You need a VPC, public/private subnets, an Internet Gateway, Route Tables, NAT Gateways, Security Groups, an ALB, EC2 instances, and an RDS database.

It takes hours, and if you miss a single route table entry, nothing works.

I got tired of repeating this painful process. So, I decided to solve it. I built a CLI tool that not only generates a robust Node.js backend (Clean Architecture, TypeScript, etc.) but also includes production-ready AWS infrastructure as code (IaC) using Terraform.

Here is how it works, and how you can use it to spin up an AWS environment locally for free.

The "Everything is a Click" Problem

ClickOps (configuring infrastructure manually via the AWS UI) is fine for learning, but terrible for repeatability. If you want to replicate a setup or tear it down, you have to click through 20 different screens.

With Node.js Quickstart Structure, you can generate a complete backend with the infrastructure already wired up:

npx nodejs-quickstart-structure@latest init -n "nodejs-service" -l "TypeScript" -a "Clean Architecture" -d "MySQL" --db-name "demo" -c "REST APIs" --caching "None" --ci-provider "GitHub Actions" --auth None --terraform "Production" --no-include-security --advanced-options

( Pro tip: Insert a cool GIF or screenshot of your CLI running here!)

The CLI asks you a few questions (TypeScript? Clean Architecture? Postgres?) and then creates a complete repository. But the real magic happens in the terraform/ folder.

Two Flavors of Infrastructure (Because Cost Matters)

Not every project is a massive enterprise app. Side projects need to be cheap, while production apps need to be highly available. I designed two Terraform templates to match these needs:

1. Standard Tier (The "Keep it Cheap" Setup)

Perfect for side projects, MVPs, and dev environments.

Single EC2 instance
Single-AZ RDS database
Shared NAT Gateway

Goal: Keep your AWS bill under $30/month (or even within the Free Tier).

Snippet of what gets generated:

module "ec2" {
  source        = "./modules/ec2"
  instance_type = "t3.micro"
  # ... automatically wired to your VPC and DB
}

2. Production Tier (High Availability)

When you're ready for the big leagues. This tier provisions:

Multi-AZ Architecture for zero-downtime failover.
Application Load Balancer (ALB) to distribute traffic smoothly.
AWS WAF (Web Application Firewall) to block SQLi and XSS automatically.
Air-gapped RDS in isolated subnets for maximum security.

The Best Part: Testing Locally for FREE with LocalStack

I know what you're thinking: "Terraform is great, but running terraform apply on AWS costs money. How do I test this without going broke?"

This was a major pain point, so I integrated LocalStack support right out of the box. You can spin up the entire AWS architecture on your local machine using Docker—completely free. Setup Local Testing

Just start LocalStack:

localstack start -d

Create a localstack.tf file to point Terraform to your local machine:

provider "aws" {
  region                      = "us-east-1"
  access_key                  = "test"
  secret_key                  = "test"
  skip_credentials_validation = true
  skip_requesting_account_id  = true
  skip_metadata_api_check     = true
  s3_use_path_style           = true

  endpoints {
    ec2 = "http://localhost:4566"
    rds = "http://localhost:4566"
    # ...
  }
}

And run:

terraform apply -auto-approve

Boom. You now have a local VPC, EC2 instance, and RDS database running on your laptop. You can validate your entire infrastructure setup without giving Amazon your credit card.

Try it out!

I built this tool to save developers time and enforce best practices from day one. Whether you're building a quick weekend hackathon project or a serious enterprise application, the foundation is ready for you.

Give it a spin, and let me know what you think!

👉 Nodejs Quickstart Generator
👉 How to use the tool and video demo
👉 Sample Project: nodejs-service-terraform

If this saves you a few hours of AWS headaches, dropping a ⭐ on the repo would mean the world to me. I'd love to hear your feedback in the comments!

Stop Blindly Trusting Passport.js: How to Implement Secure OAuth CSRF Protection Manually

Pau Dang — Mon, 18 May 2026 08:00:00 +0000

OAuth 2.0 is the backbone of modern authentication. But many developers treat it as a "set it and forget it" feature by using libraries like Passport.js. While these libraries are great, they often hide the critical security handshake happening under the hood—leaving your app vulnerable to OAuth CSRF attacks.

In this post, I'll show you how we implemented a Zero-Trust Social Login flow in nodejs-quickstart-structure v2.2.1 using plain Node.js and Axios.

The Attack: How a Hacker Steals Your Identity

Most developers know about standard CSRF (Cross-Site Request Forgery). OAuth CSRF is a specific variant where an attacker tricks a victim into linking the attacker's social account to the victim's application account.

Here is exactly how the attack happens:

The Attacker's Setup: A hacker visits your site and clicks "Link Google." They log into their own Google account, but when Google redirects them back to your site, they stop and copy the code from the URL.
The Phish: The hacker sends a victim a link: https://your-app.com/api/auth/google/callback?code=HACKER_CODE.
The Click: The victim (already logged into your app) clicks the link.
The Link: Your server receives the HACKER_CODE, validates it with Google, and sees it's a valid account. Since the victim is the one who sent the request, your server links the hacker's Google ID to the victim's user profile.
The Takeover: The hacker can now simply click "Login with Google" on your site and they are instantly logged in as the victim.

The result? A quiet, total account takeover.

The Attack Flow

The Solution: The `state` Parameter

The OAuth2 spec provides a state parameter specifically to prevent this. Here is how it looks:

The Secure Flow

Step 1: Generate and Store a Secure State

When the user clicks "Login with Google," don't just redirect them. Generate a random string, store it in a secure cookie, and pass it to the provider.

// authController.js
async googleLogin(req, res) {
  const state = crypto.randomBytes(16).toString('hex');

  // Store state in an HttpOnly, SameSite=Lax cookie
  res.cookie('oauth_state', state, { 
    httpOnly: true, 
    secure: true, // Always use HTTPS in production
    sameSite: 'lax',
    maxAge: 10 * 60 * 1000 // Valid for 10 minutes
  });

  const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?` + 
    new URLSearchParams({
      client_id: process.env.GOOGLE_CLIENT_ID,
      redirect_uri: process.env.GOOGLE_CALLBACK_URL,
      response_type: 'code',
      scope: 'profile email',
      state: state // <--- The magic happens here
    }).toString();

  res.redirect(authUrl);
}

Step 2: Verify the State on Callback

When Google redirects the user back to your site, the first thing you must do is check if the state in the URL matches the state in your cookie.

async googleCallback(req, res) {
  const { code, state } = req.query;
  const savedState = req.cookies?.oauth_state;

  // Always clear the cookie immediately to prevent reuse
  res.clearCookie('oauth_state');

  if (!state || state !== savedState) {
    return res.status(403).send('Security Alert: State mismatch detected!');
  }

  // Now it's safe to exchange the code for a token
  const tokenResponse = await axios.post('https://oauth2.googleapis.com/token', {
    code,
    client_id: process.env.GOOGLE_CLIENT_ID,
    client_secret: process.env.GOOGLE_CLIENT_SECRET,
    redirect_uri: process.env.GOOGLE_CALLBACK_URL,
    grant_type: 'authorization_code'
  });

  // Handle user data...
}

Why This Manual Approach Wins

By ditching "black-box" libraries and using a deterministic flow with Axios, you get:

Full Auditability: You can log exactly what was sent and received.
Explicit Security: You can't "forget" to validate the state because you are writing the logic yourself.
Leaner App: No need for heavy middleware if you only need social login.

Want a Battle-Tested Template?

Implementing this correctly across every project is tedious. That's why I built the Node.js Quickstart Generator.

If you want to see this implementation in action, check out these resources:

Sample Project: paudang/nodejs-social-auth
Framework: paudang/nodejs-quickstart-structure
Source: The OAuth Integration Debt: Why Your Social Login Is a CSRF Risk

If you found this helpful, check out the repo and give it a ⭐!

GitHub Repo: nodejs-quickstart-structure

OAuth2 Account Takeovers: Building a Bulletproof Social Login Architecture

Pau Dang — Wed, 06 May 2026 15:45:54 +0000

When implementing Social Login (Google, GitHub), many developers assume that the heavy lifting is handled by the provider. The truth is: the integration layer is where your system is most vulnerable.

To tackle these vulnerabilities head-on, we must rethink the integration. Here is how to build a bulletproof, Zero-Trust social login architecture.

The Pitfall 1: The Black Box Dependency

Libraries like Passport.js are incredibly popular, but they wrap the OAuth flow into a "black box." In enterprise environments, you need total auditability. We opted for a custom Axios implementation. This reduces the attack surface and allows precise domain-level error handling.

// https://github.com/paudang/nodejs-social-auth/blob/main/src/infrastructure/auth/socialAuthService.ts
export class GoogleProvider implements ISocialProvider {
  name = 'Google';
  async getProfile(code: string, redirectUri: string): Promise<ISocialProfile> {
    const params = new URLSearchParams();
    params.append('code', code);
    params.append('client_id', process.env.GOOGLE_CLIENT_ID!);
    params.append('client_secret', process.env.GOOGLE_CLIENT_SECRET!);
    params.append('redirect_uri', redirectUri);
    params.append('grant_type', 'authorization_code');

    // Deterministic Token Exchange
    const tokenResponse = await axios.post('https://oauth2.googleapis.com/token', params.toString(), {
      headers: { 'Content-Type': 'application/x-www-form-urlencoded' }
    });

    const { access_token } = tokenResponse.data;
    const profileResponse = await axios.get('https://www.googleapis.com/oauth2/v2/userinfo', {
      headers: { Authorization: `Bearer ${access_token}` },
    });

    return {
      id: profileResponse.data.id,
      email: profileResponse.data.email,
      name: profileResponse.data.name,
    };
  }
}

The Pitfall 2: Blind Account Linking

What happens if an attacker registers on a secondary OAuth provider using your email address, and your system automatically links it? You just gave them an Account Takeover (ATO) vector.

Our system prevents this by intelligently linking social profiles and nullifying passwords for OAuth-created accounts:

// https://github.com/paudang/nodejs-social-auth/blob/main/src/usecases/auth/socialLoginUseCase.ts
let user = await this.userRepository.findByEmail(profile.email);

if (!user) {
  user = new User(
    null,
    profile.name,
    profile.email,
    null, // Disable traditional login
    this.provider.name === 'Google' ? profile.id : null,
    this.provider.name === 'GitHub' ? profile.id : null,
  );
  user = await this.userRepository.save(user);
} else {
  // Controlled linking
  let updated = false;
  if (this.provider.name === 'Google' && !user.googleId) {
    user.googleId = profile.id;
    updated = true;
  }
  // Update user...
}

Bridging the Zero-Trust Gap

Once authenticated via Google, we do not trust their session indefinitely. We immediately bridge the user into our internal JWT system, fortified by a Redis "Nuclear Revoke" mechanism.

Note: The Verify 'state' mechanism (CSRF protection) shown in the diagram represents the ideal architecture target. Cryptographic state validation is actively in development and will be codified in the next version of the generator.

You can generate this exact, secure architecture for your next project using:

npx nodejs-quickstart-structure@latest init -n "my-secure-app" -l "TypeScript" -a "Clean Architecture" -d "PostgreSQL" --db-name "demo" -c "REST APIs" --caching "Redis" --ci-provider "GitHub Actions" --auth JWT --social-auth Google GitHub --no-include-security --advanced-options

Check out the CLI tool at Nodejs Quickstart Generator and the reference implementation code at nodejs-social-auth.

If you missed the first part of this architectural series on JWT Revocation, you can read it here: The Illusion of Stateless Security: Rethinking JWT Revocation at Scale

Slashed My Automation Suite from 9 Hours to 1 Hour with This Simple Caching Trick

Pau Dang — Thu, 30 Apr 2026 01:21:32 +0000

We've all been there: you build an amazing automation suite, hit "Run", and realize it's going to take until next Tuesday to finish.

Last week, I faced a massive bottleneck in my CI/CD pipeline. Here’s how I optimized a 9-hour test suite down to just 1 hour using a "Base Cache" strategy.

The Problem: The `npm install` Nightmare

I'm building a Node.js Quickstart Generator. To ensure quality, I have to validate 720 different combinations of technologies (Clean Architecture, MVC, TypeScript, JavaScript, MySQL, MongoDB, Kafka, etc.).

For every single test run, the script was doing a fresh npm install.

The Result: 9 hours of total execution time.
The Culprit: Redundant network fetches and disk I/O for the same packages over and over again.

The Solution: Smart "Base Caching"

The mindset shift was simple: Stop treating every project as a unique snowflake.

Even with 720 combinations, they share 95% of the same core dependencies. Here is the 3-step workflow I implemented:

1. Identify the "Base"

I grouped projects by their heaviest dependencies: Language + Database. This resulted in only 8 unique Base Caches (e.g., TypeScript_PostgreSQL).

2. Bootstrap via Copy

Instead of running npm install from scratch, the script now uses this optimized logic, code example: https://github.com/paudang/nodejs-quickstart-structure/blob/feature/oauht2-google-github/scripts/lib/validation-core.js#L500

// 1. Define the Base Cache key (Language + DB)
const baseHashKey = `${config.language}_${config.database}`;
const cachePath = path.join(testDir, `node_modules_base_${baseHashKey}`);

// 2. If a base cache exists, copy it in seconds
let usedCache = false;
if (await fs.pathExists(cachePath)) {
    await fs.copy(cachePath, path.join(projectPath, 'node_modules'));
    usedCache = true;
}

// 3. Run npm install (Use --prefer-offline for ultra-fast delta updates)
const npmCmd = usedCache 
    ? 'npm install --prefer-offline --no-audit' 
    : 'npm install --no-audit';

await runCommand(npmCmd, projectPath);

// 4. Save the cache if it's the first run
if (!usedCache) {
    await fs.copy(path.join(projectPath, 'node_modules'), cachePath);
}

Because most of the packages are already in the node_modules folder, npm just performs a quick delta update.

The Results

The optimization was a game-changer:

Execution Time: 9 Hours ➡️ 1 Hour.
Storage Efficiency: 80GB (if full-cached) ➡️ 1.2GB.
Dev Experience: I can now run the full validation suite multiple times a day instead of once a week.

Key Takeaways for Developers

Find the Real Bottleneck: Don't micro-optimize your code if your Network/IO is the one killing your productivity.
Think in "Deltas": If you can't cache everything, cache the 90% and compute the rest.
Automate the Automation: Always monitor your scripts. If it's slow, it’s a bug.

How do you handle heavy node_modules in your CI/CD? I'd love to hear your tricks in the comments! 👇

If you found this helpful, feel free to give it a ❤️ and follow for more DevOps and Performance tips!

When Logout is not enough: Defending against Token Theft with Big Tech-grade Rotation.

Pau Dang — Mon, 20 Apr 2026 05:47:58 +0000

Hi, I’m Pau Dang.

Imagine a silent intruder. They steal a single Refresh Token and maintain persistence in your system for months. Your user changes their password, logs out, and feels safe—but the intruder remains. This is the reality of systems that lack Stateless Invalidation.

I’m tired of boilerplates that ignore this Attack Vector. In this post, I want to discuss the architectural blueprint for Enterprise-grade JWT security.

1. The Revocation Gap: The Silent Crisis

A signed JWT is a rogue agent if you cannot kill it. Pure statelessness is a high-risk gamble. Most developers treat JWT as a "set and forget" solution, but if you cannot revoke a session instantly, your security is an illusion.

This is the Revocation Gap—the space between a user's intent to logout and the token's hardcoded expiration.

2. The Solution: Redis Blacklisting & JTI

To mitigate this without introducing a database bottleneck, we use JTI (JWT ID) and Redis.

JTI: Every token must carry a unique identifier.
Revocation List: On logout, we don't "delete" the token; we add its JTI to a high-speed Redis blacklist.
TTL Precision: By calculating the exact remaining life of the token, we ensure the Redis list remains lean and performant.

3. The Climax: "Nuclear Revoke" (Reuse Detection)

Standard token rotation is not enough. We need proactive defense. In my v2.1.0 implementation, we use Refresh Token Rotation with an integrated tripwire.

If the system receives an old Refresh Token that has already been rotated => This is a definitive sign of an attack (Reuse). Instead of just rejecting the request, the system triggers a "Nuclear Revoke": every active session for that user is instantly purged. It represents the ultimate trade-off: forcing a logout for the real user to ensure the absolute eviction of the intruder.

The Implementation: Knowledge-as-Code

View the full production-ready logic (automatically generated by nodejs-quickstart-structure) on GitHub.

// AuthController.ts - Enterprise Refresh Logic
async refresh(req: Request, res: Response) {
  try {
    const { refreshToken } = req.body;
    const decoded = JwtService.verifyRefreshToken(refreshToken);

    // 1. Integrity Check (Redis Whitelist)
    const cacheKey = `refresh_tokens:${decoded.id}`;
    let activeTokens = await cacheService.get<string[]>(cacheKey) || [];

    // --- THE TRIPWIRE: REUSE DETECTION ---
    if (!activeTokens.includes(decoded.jti)) {
        logger.warn(`Security Breach: Session revoking for user ${decoded.id}`);
        await cacheService.del(cacheKey); // "NUCLEAR REVOKE" - Kill all sessions
        return res.status(401).json({ message: 'Critical: Session compromised' });
    }

    // --- ROTATION ---
    activeTokens = activeTokens.filter(t => t !== decoded.jti);
    const newTokens = JwtService.generateTokens({ id: decoded.id });

    activeTokens.push(newTokens.refreshJti);
    await cacheService.set(cacheKey, activeTokens, 7 * 24 * 60 * 60);

    res.json(newTokens);
  } catch (error) {
    next(error);
  }
}

4. Scaffolding as an Architectural Mitigation

I’ve automated this entire "Engineering Soul" into my open-source project, nodejs-quickstart-structure. It supports 5,280 combinations of architecture and databases, but the core security blueprint remains rock-solid in all of them.

Don't settle for "Hello World" security. Automate the excellence.

Visual Configurator: Nodejs Quickstart Generator
Stats: 4,000+ downloads.
Video Demo: Advanced JWT Security: Refresh Token Rotation & Nuclear Revoke Demo
Author: Pau Dang (Senior SE).
Source: The Illusion of Stateless Security: Rethinking JWT Revocation at Scale.

I Tested 5 CI/CD Providers for 2,640 Node.js Projects. Here’s What I Learned.

Pau Dang — Thu, 09 Apr 2026 08:48:29 +0000

Hi DEV community,

Stop manually configuring your .yaml files. After benchmarking 5 major CI providers across 2,640 unique project scaffolding permutations, I’ve gathered the ultimate list of "Gotchas," fixes, and rankings to help you pick the right one for your enterprise Node.js app.

📊 The Ultimate CI/CD Ranking (2026 Edition)

Based on stability, ease of networking, and resource management across 2,640 repositories.

🥇 #1. GitHub Actions (The "It Just Works" Choice)

If your code is on GitHub, this is the winner.

Developer Experience: 10/10.
Secret Management: Seamless.
Pro-Tip: Use actions/cache aggressively. It cuts E2E startup time for databases and Kafka by nearly 40%.

🥈 #2. GitLab CI (The "Total Control" Engine)

Powerful, but requires more networking knowledge than GitHub.

The "Wait-On" Trick: When running healthchecks in GitLab CI, the hostname is almost always docker. Standardize your testing URLs to http://docker:3001 to save hours of debugging.

🥉 #3. Jenkins (The "Swiss Army Knife" of Enterprises)

The hardest to set up, but the most rewarding for complex, private infra.

The "Network Wall": Jenkins running in a container often can't see the app it just "upped" via Docker Compose.
The Fix: Use host.docker.internal as your WAIT_ON_HOST. It allows the Jenkins container to bridge out to the host-mapped ports.

🥉 #4. CircleCI (The Speed Demon)

Fast builds, but stay alert on memory limits.

OOM Prevention: Don't let Jest eat your RAM. We found that adding --maxWorkers=2 to your test script prevents the dreaded SIGKILL on free tier runners.

🥉 #5. Bitbucket Pipelines (The Team Connector)

Great for Atlassian-heavy workflows.

Legacy Stability: If your builds fail with weird gRPC transport errors, add DOCKER_BUILDKIT: "0" to your environment. It fixes compatibility issues with older pipeline runners.

📊 The Comparison Matrix (Developer Experience focus)

I tracked these metrics across 2,640 builds to see which one makes life easiest for us.

Feature	GitHub Actions	GitLab CI	Jenkins	CircleCI	Bitbucket
Ease of Setup	⚡ Instant	✅ Fast	🏗️ Complex	✅ Fast	✅ Fast
"Cool" Factor	Market Actions	DinD Sidecars	Plugins	Orbs	Pipes
Debug Mode	Good Logs	Great Logs	Hard to Read	SSH Debug	Good Logs
Free Tier Limit	2,000 mins	400 mins	Unlimited	2,500 mins	50 mins
Verdict	Best for OSS	Best for DevOps	Best for Pros	Best for Speed	Best for Jira

🛠️ How we validated this at scale

We built an automation tool that generates entire project structures (Clean Architecture, Typescript, Kafka, MySQL, etc.) and injects the perfect CI configuration for any of these 5 providers.

We didn't just write these configs—we refined them through 2,640 builds. We solved the hard stuff so you don't have to:

🐳 Docker-Out-Of-Docker: Fixed the Jenkins permission and networking walls.
🚀 Wait-On Master: Standardized healthchecks across host and container bridges.
📉 OOM Prevention: Added --maxWorkers=2 to keep CircleCI from killing your build.

💡 The Verdict

Pick the provider that matches your code hosting platform first. But if you have complex, multi-service testing needs, GitHub Actions and GitLab CI are currently pulling ahead in the "Enterprise Free" space.

Which one are you using? Drop a comment below with your biggest CI/CD headache! 👇

🛠️ Try it yourself:

🚀 Live Web UI: Node.js Quickstart Generator
🎬 YouTube Guide: Watch the walkthrough
📂 GitHub: paudang/nodejs-quickstart-structure

Love automation? Check out our Node.js Quickstart generator to get these CI configs out-of-the-box.

Stop Wasting Time on Boilerplate: Real-world Kafka & PostgreSQL Demo in 8 minutes

Pau Dang — Tue, 07 Apr 2026 13:00:00 +0000

After releasing the v2.0.0 Web UI for Node.js Quickstart Generator, the most common question was: "How does it handle real-world complexity?"

So, I decided to record a full, 8-minute implementation demo building a Payment Service from scratch.

📺 Watch: UI to Production Code in 8 Minutes

https://youtu.be/PmmxJLloZ1Q

🛠️ The Tech Stack (Zero-Prompt Setup)

Instead of answering 20 CLI prompts, I used our new Web Configurator to generate this exact stack:

Language: TypeScript
Architecture: Clean Architecture (Domain, UseCase, Infra)
Database: PostgreSQL
Caching: Redis
Messaging: Kafka
Security: Snyk Verified

🏗️ Clean Architecture in Action

The video shows exactly how the folder structure reflects a production-grade system:

src/domain: Pure entities with no dependencies.
src/usecases: Where the transaction logic lives.
src/infrastructure: Concrete implementations for Postgres connections and Kafka producers.

📡 Live Kafka Flow

The "Wow" moment is at 05:00 in the video. We trigger a REST API call that producers a Kafka event, which is then picked up by a separate consumer.

Zero configuration required.
Pre-mapped events.
Ready for microservices.

🛡️ Enterprise-Grade Security

We don't skip security. I ran npm run security:check in the video to show how Snyk is integrated from the start. Clean code is nothing if it isn't secure.

💻 Try it yourself

Want to generate the exact same project as in the video? Run this:

npx nodejs-quickstart-structure@latest init -n "payment-service-nodejs" -l "TypeScript" -a "Clean Architecture" -d "PostgreSQL" --db-name "payment-db" -c "Kafka" --caching "Redis" --ci-provider "GitHub Actions" --include-security

Check out our GitHub Repo and let's end boilerplate fatigue together! 🌟

DEV Community: Pau Dang

Playwright vs Cucumber: The Ultimate Developer's Guide to Modern Testing

The "Aha!" Moment: Let's Look at the Code

Why Playwright is Technically Superior

The Complete Workflow: From Engine to Report

1. Bi-directional Architecture (No more HTTP latency!)

2. Auto-Waiting (Goodbye sleep()... mostly)

3. Browser Contexts (Fast Isolation)

The Game Changer: Trace Viewer

The Verdict: Cucumber vs Playwright

How We Prevented Cascading Failures in our Node.js Microservices (Timeout, Retry, Circuit Breaker)

The Scenario: The Weakest Link

The System Collapse

The Defense: The Resilience Trio

The Prevention Flow

1. The Shield: Timeout

2. The Shock Absorber: Exponential Backoff

3. The Kill Switch: Circuit Breaker

Stop Writing Boilerplate

I Replaced a Costly LLM API with a 100% Offline NLP Engine (And Achieved 0ms Latency)

The Core Mechanism: Moving from Cloud to Browser

1. Lean Regex & The "Code-Switching" Beast

2. The Deterministic State Machine (Mapping 1 Million States)

The Ultimate Result: Fast, Free, and Flawless

The Takeaway

Production-Ready Logging: An Agnostic ELK Stack Setup for Node.js (with a 512MB RAM Local Constraint)

The Logging Nightmare

Clean Architecture & The Non-Blocking Logger Factory

Resilience Fallback (The Failsafe)

The 512MB Local-Test Challenge

Cloud Deployment Strategy

Conclusion

Try it yourself:

How We Built a Node.js Scaffolding Engine with Over 1 Million Mathematically Verified Architecture States

The Scaffolding Fatigue

The Mathematical Matrix

Architecture Integrity & Decoupling

The 80% Coverage Policy

Conclusion

Try it yourself:

Stop Wrestling with AWS: I Built a Tool to Generate Production-Ready Node.js & Terraform

A deep dive into how I automated setting up Node.js backends and AWS infrastructure using Terraform.

The "Everything is a Click" Problem

Two Flavors of Infrastructure (Because Cost Matters)

1. Standard Tier (The "Keep it Cheap" Setup)

2. Production Tier (High Availability)

The Best Part: Testing Locally for FREE with LocalStack

Try it out!

Stop Blindly Trusting Passport.js: How to Implement Secure OAuth CSRF Protection Manually

The Attack: How a Hacker Steals Your Identity

The Attack Flow

The Solution: The state Parameter

The Secure Flow

Step 1: Generate and Store a Secure State

Step 2: Verify the State on Callback

Why This Manual Approach Wins

Want a Battle-Tested Template?

OAuth2 Account Takeovers: Building a Bulletproof Social Login Architecture

The Pitfall 1: The Black Box Dependency

The Pitfall 2: Blind Account Linking

Bridging the Zero-Trust Gap

Slashed My Automation Suite from 9 Hours to 1 Hour with This Simple Caching Trick

The Problem: The npm install Nightmare

The Solution: Smart "Base Caching"

1. Identify the "Base"

2. Bootstrap via Copy

The Results

Key Takeaways for Developers

When Logout is not enough: Defending against Token Theft with Big Tech-grade Rotation.

1. The Revocation Gap: The Silent Crisis

2. The Solution: Redis Blacklisting & JTI

3. The Climax: "Nuclear Revoke" (Reuse Detection)

The Implementation: Knowledge-as-Code

4. Scaffolding as an Architectural Mitigation

I Tested 5 CI/CD Providers for 2,640 Node.js Projects. Here’s What I Learned.

📊 The Ultimate CI/CD Ranking (2026 Edition)

🥇 #1. GitHub Actions (The "It Just Works" Choice)

🥈 #2. GitLab CI (The "Total Control" Engine)

🥉 #3. Jenkins (The "Swiss Army Knife" of Enterprises)

🥉 #4. CircleCI (The Speed Demon)

2. Auto-Waiting (Goodbye `sleep()`... mostly)

The Solution: The `state` Parameter

The Problem: The `npm install` Nightmare