DEV Community: Tien Nguyen Huynh

Jenkins: Core Concepts and Declarative Pipelines for Modern Developers

Tien Nguyen Huynh — Wed, 09 Sep 2026 22:28:38 +0000

In the fast-evolving landscape of DevOps, Continuous Integration and Continuous Delivery (CI/CD) have transitioned from being "nice-to-have" to absolute necessities. While modern SaaS platforms like GitHub Actions, GitLab CI, and CircleCI have gained massive popularity, Jenkins remains an undisputed heavyweight champion of the automation world. It powers the build and deployment pipelines of thousands of enterprises globally.

However, many intermediate developers find Jenkins intimidating. It is often perceived as a legacy tool filled with convoluted UI menus, fragile configurations, and a confusing ecosystem of plugins.

This guide is designed to change that. We will strip away the noise and focus on the fundamental concepts you need to master Jenkins, transitioning from GUI-based configurations to modern, maintainable Pipeline-as-Code using Declarative Pipelines.

Understanding the Core Architecture

Before writing a single line of configuration, it is crucial to understand how Jenkins operates under the hood. Jenkins follows a distributed, master-agent architecture.

1. The Controller (formerly Master)

The Controller is the brain of your Jenkins installation. It is responsible for:

Hosting the Web UI.
Storing configuration details.
Parsing and orchestrating the execution of jobs.
Managing plugins and user authentication.

Crucial rule: Do not run heavy build jobs on the Controller. Doing so risks running out of memory or CPU resources, which can take down your entire CI/CD infrastructure.

2. Agents (formerly Slaves / Workers)

Agents are the workhorses. These are separate machines (virtual machines, bare metal, or Docker containers) that register with the Controller. The Controller delegates job executions to these agents.

3. Executors

An Executor is a slot for execution of work on a node (Controller or Agent). Think of it as a thread. If an agent has 4 executors, it can run up to 4 build steps concurrently.

The Paradigm Shift: Freestyle vs. Pipeline

Historically, developers configured Jenkins using Freestyle Projects. This involved clicking through a long web form, selecting checkboxes, and writing shell scripts in text areas inside the Jenkins UI.

While easy to start with, Freestyle jobs have severe drawbacks:

No Version Control: Changes to the build process are untracked.
No Code Review: You cannot submit a Pull Request to change a build step.
Hard to Replicate: If your Jenkins server dies, recreating your complex jobs is a nightmare.

To solve this, Jenkins introduced Pipelines. Pipelines treat your build workflow as code (usually saved as a Jenkinsfile in your repository). This is the industry standard for modern Jenkins usage.

Declarative vs. Scripted Pipelines

Jenkins offers two syntaxes for writing pipelines:

Scripted Pipelines: Written in a Groovy-based DSL. Highly flexible, but requires deep knowledge of Groovy and is prone to spaghetti code.
Declarative Pipelines: A newer, structured schema. It provides a more predictable, opinionated syntax that is easier to read and write.

For 95% of use cases, Declarative Pipelines are the recommended choice. Let's focus on them.

Anatomy of a Declarative Pipeline

A Declarative Pipeline must follow a strict, structured block syntax. Here are the foundational blocks:

pipeline {
    agent any // Where to run the pipeline

    stages {
        stage('Build') {
            steps {
                // Commands to compile your code
            }
        }
    }
}

Let's break down the key directives:

pipeline: The outer boundary of your configuration.
agent: Instructs Jenkins where to run the pipeline. You can target specific labels, run inside a Docker container, or use any to let Jenkins assign any available agent.
stages: A sequence of one or more conceptual steps (e.g., Build, Test, Deploy).
stage: A logical grouping of work. Each stage appears as a distinct column in the Jenkins visualization UI.
steps: The actual execution block. This is where you run shell scripts, run tests, or call plugins.

Writing a Practical Jenkinsfile

Let's write a realistic, production-ready Jenkinsfile for a Node.js application. We will include a build phase, a testing phase with error handling, and post-execution cleanup.

pipeline {
    agent {
        docker {
            image 'node:18-alpine'
        }
    }

    environment {
        APP_ENV = 'staging'
        API_URL = 'https://api.staging.example.com'
    }

    stages {
        stage('Install Dependencies') {
            steps {
                echo 'Installing project dependencies...'
                sh 'npm ci'
            }
        }

        stage('Lint & Format') {
            steps {
                echo 'Checking code style...'
                sh 'npm run lint'
            }
        }

        stage('Run Tests') {
            steps {
                echo 'Running unit tests...'
                sh 'npm run test'
            }
        }

        stage('Build') {
            steps {
                echo 'Building production assets...'
                sh 'npm run build'
            }
        }
    }

    post {
        always {
            echo 'Cleaning up workspace...'
            deleteDir() // Clean up directory to keep agent clean
        }
        success {
            echo 'Pipeline completed successfully!'
        }
        failure {
            echo 'Pipeline failed. Sending notifications...'
            // Integrate with Slack, Email, or Discord here
        }
    }
}

Why this approach works:

Isolation (agent { docker ... }): Instead of installing Node.js globally on the Jenkins agent, Jenkins dynamically spins up a Docker container, runs the build steps inside it, and terminates it when finished. This ensures pristine build environments.
Clean Execution Environment (post { always { deleteDir() } }): Prevents disk space issues on the Jenkins agent by cleaning up files after the run completes, whether it succeeded or failed.

Handling Credentials Safely

Hardcoding API keys, SSH keys, or passwords in your Jenkinsfile is a major security vulnerability. Jenkins provides a built-in Credentials Provider to store secrets securely.

To use credentials inside your Declarative Pipeline, use the credentials() helper method:

pipeline {
    agent any
    environment {
        // Fetch credentials stored with ID 'my-db-password' in Jenkins GUI
        DB_PASSWORD = credentials('my-db-password')
    }
    stages {
        stage('Database Migration') {
            steps {
                // The secret is automatically masked as **** in the console output
                sh "echo \"Connecting with password: $DB_PASSWORD\""
            }
        }
    }
}

Note: Jenkins automatically filters console output to mask secrets with `**` if they are printed by accident.

Jenkins Best Practices for Developers

As you begin configuring your own pipelines, keep these architectural best practices in mind:

Keep Jenkinsfiles in Source Control: Treat your pipelines exactly like your source code. Code-review them via pull requests.
Use Ephemeral Agents: Avoid running builds on raw servers where historical artifacts can cause "it worked on my machine" issues. Utilize Docker-based agents or Kubernetes pods.
Minimize Console Output: Do not output enormous log files to the console, as this can degrade Jenkins performance and clog memory.
Leverage Shared Libraries: If you find yourself copying and pasting the exact same logic across 10 different Jenkinsfiles, extract that logic into a Jenkins Shared Library written in Groovy. This allows you to centralize pipeline logic and keep individual repository pipelines slim.

Wrapping Up

Jenkins doesn't have to be a dark art. By ignoring legacy UI-based configurations and dedicating yourself to Declarative Pipelines, you can build reliable, secure, and scalable CI/CD pipelines as part of your application development lifecycle.

Start small: convert one of your existing project builds into a basic 3-stage Jenkinsfile, test it locally using a Docker-based Jenkins container, and gradually build up to complex multi-stage deployments. Happy building!

Beyond the Static: The Ultimate Guide to Serverless Website Deployment Platforms

Tien Nguyen Huynh — Thu, 03 Sep 2026 10:58:19 +0000

Remember when deploying a website meant setting up an Apache server, configuring FTP credentials, and hoping your database didn't crash overnight?

Today, the landscape is entirely different. We build modern, highly dynamic web applications using frameworks like Next.js, Nuxt, Remix, and SvelteKit. To host these frameworks efficiently, we rely on serverless architecture.

In a serverless paradigm, you don't manage virtual machines or container orchestration. Instead, your frontend assets are distributed globally via CDNs, and your dynamic backend logic runs inside ephemeral, auto-scaling environments (like Cloudflare Workers, AWS Lambda, or Vercel Functions).

But with so many platforms vying for your attention, how do you choose the right one? In this guide, we will break down the top serverless deployment platforms, categorized by their strengths, developer experience (DX), and underlying architecture.

Category 1: The Developer Experience Champions (Frontend-First)

These platforms are optimized for frontend developers who want zero-configuration deployments, seamless Git integration, and instant preview environments.

1. Vercel

As the creators of Next.js, Vercel is the gold standard for developer experience. It is designed to deploy frontend frameworks with virtually no configuration.

How it works: Vercel automatically detects your framework, configures the build steps, splits your API routes into serverless/edge functions, and serves static assets from their global Edge Network.
Key Features: Instant git-push deployments, collaborative preview deployments with visual comments, and built-in analytics.
Runtimes: Supports both Node.js Serverless Functions (AWS Lambda under the hood) and V8-based Edge Functions.

Code Example: A simple Vercel API Route (Next.js App Router)

// app/api/hello/route.js
export const runtime = 'edge'; // Run this on Vercel's global edge network

export async function GET(request) {
  return new Response(
    JSON.stringify({ message: 'Hello from Vercel Edge!' }),
    {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
    }
  );
}

Best For: Next.js projects, teams prioritizing fast iteration/collaboration, and Jamstack sites requiring minimal backend configuration.

2. Netlify

Netlify pioneered the "Jamstack" movement and remains one of the strongest alternatives to Vercel.

How it works: Similar to Vercel, Netlify connects to your Git provider, builds your project, and deploys it to its custom "Application Delivery Network."
Key Features: Netlify Forms (automatic form handling without a backend), Netlify Identity (user authentication), and Background Functions (for long-running async tasks up to 15 minutes).
Best For: Nuxt, Astro, and SvelteKit applications, or teams looking for out-of-the-box form and identity management.

Category 2: The Edge Powerhouses (Performance & Cost-Efficiency)

If you want the absolute fastest global response times and zero cold starts at a fraction of the cost, edge-first platforms are your answer.

3. Cloudflare Pages & Workers

Cloudflare is built differently. Instead of relying on traditional AWS Lambda-style virtual containers, Cloudflare runs code on V8 Isolates across their massive global network of 300+ data centers.

How it works: Cloudflare Pages handles static asset hosting, while Cloudflare Workers handle dynamic logic. They integrate seamlessly, letting you deploy full-stack applications (like Remix or SvelteKit) entirely at the edge.
Key Features: Virtually zero cold starts, incredibly generous free tier (100k requests/day for Workers), and native integrations with edge-native storage like KV (Key-Value), D1 (SQL Database), and R2 (Object Storage).

Code Example: Cloudflare Pages Function

// functions/api/greet.js
export async function onRequest(context) {
  const data = { greeting: 'Hello from Cloudflare Edge!' };
  return new Response(JSON.stringify(data), {
    headers: { 'content-type': 'application/json' },
  });
}

Pros: Unmatched global latency, highly cost-efficient, immune to standard serverless cold starts.
Cons: V8 isolate environment has limitations. You cannot run arbitrary Node.js binaries or libraries that rely heavily on native C++ extensions.
Best For: High-traffic applications, real-time APIs, globally distributed users, and cost-conscious side projects.

Category 3: The Infrastructure Heavyweights (Maximum Control)

For enterprise systems or applications requiring deep integrations with databases, queues, and container services, deploying directly to raw cloud infrastructure is often necessary.

4. AWS (Amplify & SST)

While raw AWS Lambda can be daunting to configure manually, modern tools have bridged the developer experience gap.

AWS Amplify: AWS’s managed hosting service for frontend frameworks. It provides hosting, authentication, and database generation with a Git-based workflow similar to Vercel.
SST (Serverless Stack): An open-source framework that lets you deploy modern full-stack apps directly to your own AWS account using AWS CDK. It compiles SvelteKit, Next.js, or Astro apps into pure AWS infrastructure (S3, CloudFront, Lambda, API Gateway).

Code Example: SST Configuration (sst.config.ts)

import { SSTConfig } from 'sst';
import { NextjsSite } from 'sst/constructs';

export default {
  config(_input) {
    return {
      name: 'my-serverless-app',
      region: 'us-east-1',
    };
  },
  stack({ stack }) {
    const site = new NextjsSite(stack, 'site');
    stack.addOutputs({
      SiteUrl: site.url,
    });
  },
} satisfies SSTConfig;

Pros: Complete ownership of your cloud infrastructure, zero markup on AWS billing, access to the entire AWS catalog (SQS, EventBridge, RDS).
Cons: Steeper learning curve, complex IAM configuration, and potential cost surprises if your security controls aren't configured properly.
Best For: Mid-to-large-scale companies already using AWS, projects requiring long-running backend background jobs, and heavy database-driven applications.

Category 4: The Backend-as-a-Service (BaaS) Ecosystems

If your serverless website is deeply integrated with real-time data or user authentications, hosting with a BaaS provider can simplify your architecture.

5. Firebase Hosting + Cloud Functions

Google's Firebase is a veteran in the serverless space. It integrates static web hosting with serverless functions and a real-time NoSQL database (Firestore).

Pros: Excellent SDKs for mobile and web, real-time listeners out of the box, robust local emulator suite.
Cons: Hard vendor lock-in to Google Cloud Platform; Firestore querying can feel restrictive.

6. Supabase (Self-hosted or Cloud)

Often called the open-source Firebase alternative, Supabase provides hosting for Edge Functions alongside a fully-featured Postgres database.

Pros: Real Postgres database (not NoSQL), built-in Row-Level Security (RLS), instant REST/GraphQL APIs generated from your database schema.
Best For: Database-heavy applications that need relational integrity, real-time subscriptions, and fast serverless edge functions.

Choosing the Right Platform: The Decision Matrix

To help you decide, here is a quick reference table based on your project priorities:

Platform	Primary Strength	Ideal Use Case	Cost at Scale
Vercel	Developer Experience & Next.js integration	Corporate websites, SaaS frontends, Next.js apps	Moderate to High
Netlify	Jamstack features (Forms, Identity)	Content sites, multi-framework apps	Moderate
Cloudflare Pages	Cost, raw speed, global distribution	Real-time APIs, high-traffic tools, microservices	Low
AWS / SST	Architecture control, ownership	Enterprise apps, high-volume production systems	Very Low (Raw AWS cost)
Supabase / Firebase	Integrated real-time database & Auth	Dynamic CRUD apps, dashboards, mobile-web hybrids	Moderate

Conclusion

There has never been a better time to build serverless websites. If you want the fastest route to production with high collaborative velocity, Vercel remains the king. If you want ultra-low latencies and to minimize your hosting bill, Cloudflare Pages & Workers are unbeatable.

For those who need the reliability, scalability, and safety of owning their own AWS cloud without the complexity, SST is the future of full-stack serverless deployment.

What is your go-to platform for serverless hosting? Let me know in the comments below!

Why Developers Should Use Bitwarden for Credential Management

Tien Nguyen Huynh — Mon, 31 Aug 2026 09:30:58 +0000

Introduction: The Developer's Credential Dilemma

As developers, we manage dozens—if not hundreds—of sensitive credentials daily. From database connection strings and SSH keys to API tokens and third-party service logins, keeping track of these secrets securely without destroying developer velocity is a constant challenge.

Far too often, developers fall into bad habits: reusing simple passwords, storing raw API keys in unencrypted .env files committed to Git, or sharing production tokens over Slack. These practices are major security risks.

While there are many password managers on the market, Bitwarden has rapidly become the preferred choice for software engineers and DevOps teams. In this article, we will explore why Bitwarden is uniquely suited for developers, examine its developer-centric feature set, and walk through practical CLI examples.

1. True Open-Source Transparency

For security software, trust is paramount. Closed-source proprietary password managers force you to trust the vendor's claims without verification. Bitwarden flips this model on its head.

The entire Bitwarden codebase—including web vaults, mobile applications, desktop clients, browser extensions, and backend infrastructure—is 100% open source under GPLv3 and AGPLv3 licenses. You can inspect the source code directly on GitHub.

Why Open Source Matters for Security:

Public Auditing: Security researchers and the global developer community continuously audit the code for vulnerabilities.
No Hidden Backdoors: Transparency ensures there are no intentional backdoors or tracking mechanisms.
Longevity: Even if the company behind Bitwarden were to disappear, the software and server implementations could be maintained by the community.

2. Developer-First Workflows: The Bitwarden CLI (`bw`)

Most password managers focus exclusively on GUI interfaces designed for non-technical users. Bitwarden provides a full-featured Command Line Interface (CLI) that allows developers to interact with their vault directly from the terminal or automate tasks within shell scripts.

Installing the Bitwarden CLI

You can install bw via NPM, Homebrew, or direct binary downloads:

# Via NPM
npm install -g @bitwarden/cli

# Via Homebrew (macOS)
brew install bitwarden-cli

Practical CLI Usage

Once installed, you can authenticate and unlock your vault dynamically in scripts without exposing plain-text master passwords.

# 1. Log in to your Bitwarden account
bw login

# 2. Unlock your vault to get a session key
export BW_SESSION=$(bw unlock --raw)

# 3. Search for items in JSON format using jq
bw list items --search "Stripe API" | jq '.[0].fields[] | select(.name=="Secret Key").value'

By leveraging the bw CLI, you can inject secret values directly into application environments during local execution or automated testing, eliminating the need to store static secrets on your local disk.

3. End-to-End Encryption Architecture

Bitwarden uses zero-knowledge, end-to-end encryption. All vault data is encrypted on your local device before it is ever transmitted to synchronization servers.

Key Cryptographic Details:

Symmetric Encryption: Vault items are encrypted using AES-CBC 256-bit encryption.
Key Derivation: Master key generation uses PBKDF2 SHA-256 (with configurable iteration counts) or Argon2id (the state-of-the-art memory-hard key derivation function).
Zero-Knowledge Architecture: Bitwarden employees cannot read your vault data, reset your master password, or access your decrypted items. Encryption keys are derived entirely from your master password and stored in memory only when unlocked.

4. Self-Hosting Capabilities

Many organizations operate under strict compliance constraints (such as HIPAA, SOC2, or GDPR) or simply prefer to keep infrastructure internal. Bitwarden officially supports self-hosted deployments using Docker containers.

For individual developers or light-resource homelabs, there is also Vaultwarden, an alternative backend written in Rust that is fully compatible with official Bitwarden clients while using minimal RAM.

Docker Compose Example for Official Deployment

Bitwarden provides a streamlined installation script for Docker environments:

# Download the installation script
curl -sH 'Cache-Control: no-cache' -o bitwarden.sh https://raw.githubusercontent.com/bitwarden/self-host/main/bitwarden.sh

# Make script executable and run
chmod +x bitwarden.sh
./bitwarden.sh install

Self-hosting gives you complete control over your database, backups, network firewalls, and audit logs.

5. Bitwarden Secrets Manager for CI/CD Pipelines

Beyond basic user password management, Bitwarden offers Bitwarden Secrets Manager, tailored specifically for DevOps engineers and software development teams.

Secrets Manager centralizes infrastructure secrets, environment variables, and API tokens across multi-cloud infrastructure and CI/CD tools (like GitHub Actions, GitLab CI, and Kubernetes).

Key Advantages over Standalone Key-Value Stores:

Unified Access Control: Manage developer personal access logins and infrastructure machine tokens from a centralized administrative control plane.
Native Integrations: First-party SDKs available for Node.js, Python, Go, and Rust.
Secret Rotation & Auditing: Complete history of who accessed or modified environment keys.

# Example using Bitwarden Secrets Manager Python SDK
from bitwarden_sdk import BitwardenClient, DeviceType

client = BitwardenClient()
client.auth().login_access_token(access_token)

secret = client.secrets().get("00000000-0000-0000-0000-000000000000")
print(f"Retrieved DB Secret: {secret.value}")

Conclusion: Elevate Your Security Posture

Managing credentials shouldn't be an afterthought or a friction point in your development pipeline. Bitwarden strikes an optimal balance between top-tier security, developer accessibility, and open-source flexibility.

Whether you are looking for a personal password manager with CLI capabilities, self-hosting a vault for your team, or managing infrastructure secrets in production, Bitwarden provides a modern ecosystem designed for engineering needs.

Next Steps:

Sign up for a free account or spin up a self-hosted instance.
Install the bw CLI tool and experiment with scripting credential retrievals.
Migrate away from plain-text credentials in .env files once and for all!

Under the Hood: 5 JavaScript Fundamentals Every Intermediate Dev Should Master

Tien Nguyen Huynh — Mon, 31 Aug 2026 04:15:21 +0000

We’ve all been there: you can build full-stack web applications, write React components with ease, or deploy Node.js microservices, yet every now and then, a subtle JavaScript bug leaves you scratching your head for hours.

Often, these bugs stem not from complex framework intricacies, but from a shaky understanding of core JavaScript fundamentals.

In this article, we'll strip away the abstractions and look under the hood at five fundamental concepts that every intermediate JavaScript developer should deeply understand.

1. Execution Context and the Temporal Dead Zone

Before any JavaScript code runs, the JavaScript engine creates an Execution Context. Think of it as an environment that manages the code currently being evaluated.

An Execution Context consists of two phases:

Creation Phase: The engine allocates memory for variables and functions (Hoisting).
Execution Phase: The engine executes the code line-by-line.

Hoisting: `var` vs. `let` / `const`

Many developers believe let and const aren't hoisted. They actually are, but they behave differently due to the Temporal Dead Zone (TDZ).

console.log(a); // Output: undefined (hoisted & initialized to undefined)
var a = 10;

console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 20;

When var is hoisted, memory is allocated and immediately initialized with undefined. When let and const are hoisted, memory is allocated, but they remain uninitialized. The time between entering the scope and reaching the variable declaration is the Temporal Dead Zone.

2. Demystifying `this` Once and For All

The this keyword is notoriously confusing because its value is determined how a function is called, not where it is defined (with the exception of arrow functions).

Here are the 4 primary rules of this binding:

Implicit Binding

When a function is called as a method of an object, this points to that object.

const user = {
  name: 'Alex',
  greet() {
    console.log(`Hello, I am ${this.name}`);
  }
};

user.greet(); // Output: Hello, I am Alex

Explicit Binding

Using .call(), .apply(), or .bind(), you explicitly define what this refers to.

function showRole(role) {
  console.log(`${this.name} is a ${role}`);
}

const dev = { name: 'Sarah' };
showRole.call(dev, 'Frontend Engineer'); // Output: Sarah is a Frontend Engineer

Arrow Functions

Arrow functions do not have their own this. They lexically bind this, inheriting it from the surrounding outer scope.

const timer = {
  seconds: 0,
  start() {
    setInterval(() => {
      this.seconds++;
      console.log(this.seconds);
    }, 1000);
  }
};

timer.start(); // Works as expected because arrow function inherits 'this' from start()

3. Closures: Power, Memory, and Encapsulation

A closure is created when a function is defined inside another function, allowing the inner function to retain access to variables in the outer function's lexical scope—even after the outer function has finished executing.

Practical Use Case: Data Encapsulation

JavaScript didn't always have private class fields (#private). Closures provided a way to create private variables.

function createCounter() {
  let count = 0; // Private state

  return {
    increment() {
      count++;
      return count;
    },
    decrement() {
      count--;
      return count;
    },
    getCount() {
      return count;
    }
  };
}

const counter = createCounter();
console.log(counter.increment()); // 1
console.log(counter.increment()); // 2
console.log(counter.count);       // undefined (cannot be accessed directly!)

Watch Out for Memory Leaks

Because closure variables are retained in memory as long as the inner function is reachable, holding references unnecessarily can prevent Garbage Collection and cause memory leaks.

4. The Event Loop: Microtasks vs. Macrotasks

JavaScript is single-threaded, meaning it can only perform one task at a time. Concurrency is handled by the Event Loop, which coordinates the Call Stack, Microtask Queue, and Macrotask (Callback) Queue.

The Order of Execution

Execute all synchronous code on the Call Stack.
When the Call Stack is empty, execute all tasks in the Microtask Queue (Promises, queueMicrotask, MutationObserver).
Execute one task from the Macrotask Queue (setTimeout, setInterval, I/O, UI rendering).
Repeat.

Consider this classic interview question:

console.log('1: Sync');

setTimeout(() => {
  console.log('2: Macrotask (setTimeout)');
}, 0);

Promise.resolve().then(() => {
  console.log('3: Microtask (Promise)');
});

console.log('4: Sync');

Output:

1: Sync
4: Sync
3: Microtask (Promise)
2: Macrotask (setTimeout)

Even with a delay of 0ms, setTimeout must wait for the Microtask Queue to completely clear before it gets pushed onto the Call Stack.

5. Prototypal Inheritance Beyond `class` Syntax

ES6 introduced the class keyword, making JavaScript look like classic object-oriented languages. However, under the hood, JavaScript still uses prototypal inheritance.

Every object in JavaScript has a internal link to another object called its prototype ([[Prototype]]). When you attempt to access a property on an object, JavaScript searches the object itself first, then traverses up the prototype chain until it finds it or reaches null.

function Person(name) {
  this.name = name;
}

Person.prototype.sayHi = function() {
  console.log(`Hi, my name is ${this.name}`);
};

const dev = new Person('Maya');

dev.sayHi(); // Output: Hi, my name is Maya
console.log(dev.__proto__ === Person.prototype); // true

Understanding this mechanic is critical when extending built-in objects, writing high-performance code, or working with legacy codebases.

Conclusion

Frameworks come and go, but core JavaScript mechanics remain constant. Mastering execution contexts, scoping rules, this binding, closures, the event loop, and prototypes will make you a far better troubleshooter and architect.

The next time you encounter an unexpected value or asynchronous bug, take a step back and think about what the engine is doing behind the scenes!

Shift Left: Why Security Mindset is a Non-Negotiable Developer Skill

Tien Nguyen Huynh — Mon, 31 Aug 2026 04:15:04 +0000

For a long time, software development followed a predictable pipeline: developers wrote code, pushed features, and handed the application over to the Security or SecOps team right before release. If security issues were found, tickets were created, deadlines were pushed, and frustrations flared.

Today, that model is dead. With continuous integration and rapid deployment pipelines, waiting until the end of the release cycle to address security is like building a house, painting it, and only then checking if the foundation is made of sand.

Security is no longer just a specialized role—it is a core software engineering skill. Here is why having security knowledge makes you a significantly better developer and how it changes the way you write code.

1. Catching Vulnerabilities Early is Cheaper and Faster

The "Shift Left" philosophy isn't just industry jargon; it's basic economics. According to the Systems Sciences Institute at IBM, fixing a security bug in production costs up to 30 times more than fixing it during the design or development phase.

When you understand basic attack vectors while writing code:

You write secure code on the first pass.
You avoid long code-review friction cycles.
You protect your application from costly data breaches and downtime.

2. You Are the First Line of Defense

Automated tools (SAST, DAST, dependency scanners) are great, but they are far from perfect. They miss context-specific business logic flaws that human attackers excel at exploiting.

Consider a common vulnerability like Insecure Direct Object Reference (IDOR). An automated scanner won't know if User A should have access to User B's invoices—only you, the developer who understands the domain logic, can enforce proper authorization checks.

Let's look at how code evolves when a developer understands security context.

Bad Example: Insecure API Endpoint

// Vulnerable Express.js route
app.get('/api/documents/:id', async (req, res) => {
    // IDOR Vulnerability: Fetching document directly by ID without checking ownership
    const document = await db.collection('documents').findOne({ _id: req.params.id });

    if (!document) {
        return res.status(404).json({ error: 'Document not found' });
    }

    res.json(document);
});

Good Example: Authorization Enforced

// Secure Express.js route with authorization check
app.get('/api/documents/:id', authenticateUser, async (req, res) => {
    const document = await db.collection('documents').findOne({
        _id: req.params.id,
        ownerId: req.user.id // Ensures user can only access their own document
    });

    if (!document) {
        // Use 404 or 403 to prevent resource enumeration
        return res.status(404).json({ error: 'Document not found' });
    }

    res.json(document);
});

3. SQL Injection is Still Alive Today

Despite decades of warnings, flaws like SQL Injection (SQLi) and Cross-Site Scripting (XSS) consistently rank high on the OWASP Top 10. Why? Because developers often rely on string concatenation when building queries under pressure.

Vulnerable Python SQL Query

# Vulnerable to SQL Injection
def get_user_profile(username):
    query = f"SELECT * FROM users WHERE username = '{username}'"
    cursor.execute(query) # If username is: admin' --
    return cursor.fetchone()

Secure Parameterized Query

# Secure using parameterized queries
def get_user_profile(username):
    query = "SELECT * FROM users WHERE username = %s"
    cursor.execute(query, (username,))
    return cursor.fetchone()

Understanding how parameterized queries work under the hood separates amateur developers from software engineers who build resilient systems.

4. Third-Party Dependencies Are a Massive Attack Vector

Modern software engineering is largely about composing open-source packages. While npm, PyPI, and Crates.io accelerate development, they also introduce supply chain risks.

A developer with security awareness doesn't just npm install blindly. They understand:

Dependency Auditing: Regularly running npm audit or using tools like Snyk and Dependabot.
Typosquatting & Malicious Packages: Verifying package names, maintainer reputation, and release history.
Pinning Dependency Versions: Preventing unexpected code updates from pulling compromised releases into production builds.

5. Security Knowledge Elevates Your Career

Senior developers aren't defined by how quickly they write code; they are defined by their ability to design system architectures that are reliable, scalable, and secure.

When you demonstrate security awareness during code reviews, system design interviews, and architectural discussions:

You gain trust from engineering leadership.
You reduce technical debt and compliance headaches (GDPR, SOC2, HIPAA).
You stand out as a well-rounded engineer capable of taking end-to-end responsibility.

Essential Security Habits to Start Today

You don't need a degree in cybersecurity to write secure software. Incorporate these four habits into your daily workflow:

Never Trust User Input: Sanitize and validate every piece of data coming from query parameters, request bodies, headers, and external APIs.
Practice the Principle of Least Privilege: Ensure services, database credentials, and API keys only have the minimum permissions necessary to function.
Automate Static Analysis: Add linters with security rules (e.g., eslint-plugin-security) to your local setup and CI/CD pipelines.
Keep Secrets Out of Code: Store API keys and database URIs in environment variables and secret management vaults—never commit them to Git.

Conclusion

Writing code that works is only half the job. Writing code that continues to work securely in an untrusted environment is what true software craftsmanship is all about.

By taking the time to understand common security vulnerabilities and adopting defensive coding practices, you protect your users, save your organization from devastating security incidents, and elevate your career as an engineer.

What security practices do you implement in your daily workflow? Share your tips in the comments below!

Mastering Keycloak: Essential Concepts Every Developer Should Know for Application Security

Tien Nguyen Huynh — Mon, 31 Aug 2026 04:14:53 +0000

Managing authentication and authorization in modern web applications can quickly become a maintenance nightmare. Between handling password resets, multi-factor authentication (MFA), social logins, and role-based access control (RBAC), building an in-house solution consumes valuable time that could be spent on core business logic.

Enter Keycloak: an open-source Identity and Access Management (IAM) solution maintained by Red Hat. Keycloak acts as a centralized authentication server that supports industry standards like OAuth 2.0, OpenID Connect (OIDC), and SAML 2.0.

Whether you are building a microservices architecture or a single-page application (SPA), understanding Keycloak's foundation is crucial. In this guide, we will break down the essential Keycloak concepts and look at how to integrate it into your application workflow.

Core Concepts: Demystifying Keycloak Terminology

To work effectively with Keycloak, you need to understand its core building blocks. Let's look at how Keycloak organizes users, permissions, and applications.

1. Realms

A Realm is a management space inside Keycloak that manages a set of users, credentials, roles, and clients. It provides an isolated domain where entities cannot access resources in another realm.

Master Realm: Created by default. It contains the administrative accounts used to manage Keycloak itself. Rule of thumb: Never use the Master realm for managing your application users.
Custom Realms: You create custom realms (e.g., company-dev, my-app-production) for your actual applications.

2. Clients

In Keycloak terminology, a Client is an entity that requests Keycloak to authenticate a user. Clients can be front-end web apps, mobile apps, backend REST APIs, or third-party services.

Keycloak categorizes clients based on their ability to keep credentials secret:

Public Clients: Cannot hold client secrets safely (e.g., React/Vue SPAs, React Native mobile apps). They must use the Authorization Code Flow with PKCE (Proof Key for Code Exchange).
Confidential Clients: Backend applications capable of maintaining a client secret securely (e.g., Node.js Express, Spring Boot, Ruby on Rails apps).
Bearer-only Clients: Backend APIs that do not initiate logins themselves; they only verify incoming HTTP bearer tokens (JWTs).

3. Users, Groups, and Roles

Users: Individual entities that log into your applications.
Groups: Collections of users. Roles assigned to a group are automatically inherited by its members.
Roles: Permissions granted to users. Keycloak supports two levels of roles:
- Realm Roles: Global permissions valid across all clients inside the realm (e.g., global-admin).
- Client Roles: Permissions specific to a particular client (e.g., reports-service-viewer).

The Authentication Flow in Action

When using OpenID Connect (OIDC) with Keycloak, a typical login flow for a Single Page Application with a Backend API looks like this:

Login Request: User clicks "Login" in the React/Vue frontend.
Redirect to Keycloak: Frontend redirects the user to Keycloak's login page.
User Authenticates: User enters credentials (and MFA if configured).
Authorization Code: Keycloak redirects back to the frontend with a short-lived authorization code.
Token Exchange: Frontend exchanges the code (and PKCE verifier) for tokens via Keycloak's token endpoint.
Access Token Issue: Keycloak returns an Access Token (JWT), ID Token, and Refresh Token.
API Requests: Frontend attaches the Access Token in the Authorization: Bearer <token> header on backend requests.
Token Validation: The backend API verifies the JWT's signature and claims without calling Keycloak every time.

Quick Start: Running Keycloak with Docker

The fastest way to experiment with Keycloak locally is via Docker:

docker run -d \
  --name keycloak_dev \
  -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:24.0.0 \
  start-dev

Once running, navigate to http://localhost:8080, access the Admin Console, log in with admin/admin, and create a new realm (e.g., dev-realm).

Practical Example: Validating Keycloak JWTs in a Node.js Backend

Backend services need to verify the JWT tokens sent by client applications. Instead of querying Keycloak on every incoming HTTP request, backend APIs download Keycloak's public keys via JWKS (JSON Web Key Set) to verify signatures locally.

Here is how you can implement token verification in a Node.js / Express application using jsonwebtoken and jwks-rsa:

const express = require('express');
const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

const app = express();

const KEYCLOAK_URL = 'http://localhost:8080';
const REALM_NAME = 'dev-realm';

// Configure JWKS client to fetch public keys from Keycloak
const client = jwksClient({
  jwksUri: `${KEYCLOAK_URL}/realms/${REALM_NAME}/protocol/openid-connect/certs`
});

// Helper to get signing key from JWKS
function getKey(header, callback) {
  client.getSigningKey(header.kid, function(err, key) {
    if (err) return callback(err);
    const signingKey = key.getPublicKey();
    callback(null, signingKey);
  });
}

// Authentication Middleware
function authenticateToken(req, res, next) {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) return res.sendStatus(401);

  jwt.verify(token, getKey, {
    issuer: `${KEYCLOAK_URL}/realms/${REALM_NAME}`,
    algorithms: ['RS256']
  }, (err, decoded) => {
    if (err) {
      console.error('Token verification failed:', err.message);
      return res.sendStatus(403);
    }

    // Attach decoded user payload to request
    req.user = decoded;
    next();
  });
}

// Protected endpoint
app.get('/api/protected', authenticateToken, (req, res) => {
  res.json({
    message: "Access granted to secure resource!",
    user: req.user.preferred_username,
    roles: req.user.realm_access?.roles || []
  });
});

app.listen(3000, () => console.log('Backend running on port 3000'));

Inspecting User Roles in the JWT

When Keycloak issues an access token, it includes realm and client roles inside the payload:

{
  "exp": 1710000000,
  "iss": "http://localhost:8080/realms/dev-realm",
  "preferred_username": "johndoe",
  "email": "john@example.com",
  "realm_access": {
    "roles": ["user", "developer"]
  },
  "resource_access": {
    "my-backend-api": {
      "roles": ["read:reports"]
    }
  }
}

Your backend middleware can inspect realm_access.roles or resource_access.<client>.roles to enforce fine-grained access policies.

Essential Best Practices for Production

If you are planning to deploy Keycloak to production, keep these operational rules in mind:

Always Use HTTPS: OAuth tokens are sensitive authorization credentials. Transmitting them over unencrypted HTTP exposes your app to man-in-the-middle (MitM) attacks.
Keep Token Lifetimes Short: Set Access Token expiration to short durations (e.g., 5 to 15 minutes). Rely on Refresh Tokens to get new access tokens seamlessly.
Use Realm Export/Import for CI/CD: Keycloak allows exporting realm configurations to JSON format. Keep your realm settings in source control and import them during deployment pipelines rather than configuring production realms manually through the UI.
Never Store Secrets in Front-end Code: Always use PKCE for browser and mobile applications. Client secrets belong strictly on server-side code.
Use an External Database: Keycloak ships with an embedded H2 database by default. Never use H2 in production; connect Keycloak to a resilient PostgreSQL or MySQL cluster instead.

Conclusion

Keycloak takes the heavy lifting out of application security by providing a battle-tested, standard-compliant authorization service. By mastering basic concepts like Realms, Clients, Scopes, and JWKS-based token verification, you can easily integrate secure single sign-on and role management into any modern software architecture.

Have you used Keycloak in production, or are you exploring it for your next project? Let me know your thoughts and questions in the comments below!

Codex vs Cursor vs Claude Code: Choosing the Right AI Coding Assistant

Tien Nguyen Huynh — Mon, 31 Aug 2026 04:14:40 +0000

The developer landscape has shifted dramatically over the past few years. We have moved from simple syntax highlighting and basic tab-completion to fully context-aware, agentic AI assistants capable of building entire features across complex codebases.

Today, three prominent paradigms dominate the AI-assisted development space:

OpenAI Codex (and its underlying legacy/API ecosystem, which laid the foundation for tools like GitHub Copilot).
Cursor (the AI-native VS Code fork designed from the ground up for deep codebase integration).
Claude Code (Anthropic’s agentic CLI tool powered by Claude 3.5 Sonnet, bringing AI directly into your terminal).

If you are an intermediate developer trying to streamline your stack, deciding between these tools can be confusing. Are you better off with inline completion, an AI-native editor, or a CLI agent? Let’s dissect their strengths, architecture, real-world performance, and ideal use cases.

1. OpenAI Codex: The Pioneer of Code Generation

Overview

Released by OpenAI, Codex was a fine-tuned descendant of GPT-3 trained on billions of lines of public GitHub code. While OpenAI deprecated the standalone Codex API endpoint in favor of general-purpose models (like GPT-4o and GPT-4o-mini), "Codex" remains synonymous with the inline auto-complete paradigm that powered the early versions of GitHub Copilot.

Key Features

Inline Autocomplete: Low-latency suggestions as you type comments or function signatures.
Broad Model Support: Modern derivatives leverage OpenAI’s fast speculative decoding models for real-time completion.
Integration Flexibility: Can be embedded into almost any editor via plugins (Neovim, JetBrains, VS Code).

Where It Shines

Codex-style inline tools excel at micro-completions. When writing boilerplate code, standard algorithms, or predictable interface types, inline completion provides seamless velocity without breaking your flow state.

// Example: Quick utility function generated via inline prompt
// Function to validate and sanitize an email address
export function sanitizeEmail(email: string): string {
  const trimmed = email.trim().toLowerCase();
  const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
  if (!emailRegex.test(trimmed)) {
    throw new Error('Invalid email format');
  }
  return trimmed;
}

Where It Falls Short

Traditional Codex workflows struggle with broad project context. Because inline completions rely heavily on open files or small token windows, they often lack awareness of cross-file abstractions, custom utility libraries, or repository-wide architectural patterns.

2. Cursor: The AI-Native IDE Standard

Overview

Cursor is not just an extension; it is a full fork of VS Code engineered specifically around AI interaction. It integrates localized codebase indexing, context querying (@codebase), and multi-file editing features directly into the editor UI.

Key Features

Repository Indexing: Scans vector embeddings of your entire repository for deep context lookup.
Composer (Multi-file Edits): Generates, refactors, and updates code across multiple files simultaneously using Cmd + I or Cmd + K interfaces.
Model Agnostic Flexibility: Allows you to switch between Claude 3.5 Sonnet, GPT-4o, and custom local models seamlessly.
Privacy Controls: Offers privacy mode where code is not stored or used for model training.

Where It Shines

Cursor shines when working inside complex, modern web applications (like Next.js, React, or microservices). If you need to refactor a component and automatically update its corresponding API route, types, and unit tests, Cursor's Composer handles multi-file mutations smoothly inside a visual diff editor.

// User prompts Cursor Composer:
// "Refactor UserProfile to use Server Actions and update the TypeScript interface in @types/user.ts"

// Cursor updates types/user.ts and components/UserProfile.tsx simultaneously:
export interface UserProfileProps {
  userId: string;
  initialData: {
    name: string;
    email: string;
  };
}

export async function UserProfile({ userId, initialData }: UserProfileProps) {
  // Cursor generates inline server action integration
  async function updateName(formData: FormData) {
    'use server';
    const newName = formData.get('name') as string;
    await db.user.update({ where: { id: userId }, data: { name: newName } });
  }

  return (
    <form action={updateName}>
      <input name="name" defaultValue={initialData.name} />
      <button type="submit">Save</button>
    </form>
  );
}

Where It Falls Short

Cursor requires leaving your default terminal-centric environment if you prefer lightweight text editors (like Helix or Neovim). Additionally, UI multi-file diffing can occasionally become slow on massive monorepos.

3. Claude Code: The Terminal-Native Agent

Overview

Claude Code is Anthropic’s developer agent operating directly inside your command-line interface (CLI). Powered by Claude 3.5 Sonnet, Claude Code doesn't just write text—it acts as an agent that reads your repo structure, runs bash commands, executes git operations, executes tests, and fixes syntax errors autonomously.

Key Features

CLI First: Runs natively in your terminal alongside your existing shell tools and text editors.
Tool Use & Execution: Can run terminal commands like npm test, git status, or pytest, observe output errors, and self-correct code autonomously.
Deep Reasoning: Leverages Claude 3.5 Sonnet’s top-tier logic capabilities for architecture decisions and debugging complex logical edge cases.

Where It Shines

Claude Code excels at autonomous problem solving and task completion. You can issue high-level commands, and Claude Code executes the cycle of edit-test-fix without constant user hand-holding.

# Example CLI command in Claude Code terminal
$ claude "Fix all failing tests in the /tests/auth directory and commit the changes with a descriptive message"

# Claude Code executes under the hood:
# 1. Runs `npm test tests/auth`
# 2. Analyzes stack trace outputs
# 3. Edits auth service files
# 4. Re-runs tests to verify pass state
# 5. Executes `git commit -am 'fix(auth): update token expiration check logic'`

Where It Falls Short

Because it runs in the terminal, it lacks visual rich-text UI components for inline side-by-side diff review (unlike Cursor). It can also consume token credits quickly if left on complex loop-based debugging tasks.

Comparison Breakdown

Feature	OpenAI Codex (Legacy / Copilot)	Cursor IDE	Claude Code (CLI)
Primary Interface	Inline plugin / Chat sidebar	VS Code Fork (GUI)	Terminal / Command Line
Context Window Scope	File-level / Localized	Entire Repository Vector Index	Project Workspace / Bash Context
Agentic Execution	Limited	Moderate (Composer mode)	High (Runs bash, git, tests)
Multi-File Refactoring	Weak	Excellent (Visual Diffs)	Excellent (File mutations)
Editor Flexibility	Works in Neovim, JetBrains, VS Code	Requires Cursor IDE	Agnostic (Runs in any shell)
Primary Engine	GPT-4o / Codex variants	Multi-model (Sonnet 3.5 default)	Claude 3.5 Sonnet

Which Tool Should You Choose?

Choosing the right tool comes down to your primary development style:

Pick OpenAI Codex / GitHub Copilot if:

You want simple, low-friction inline completions.
You use specialized IDEs like JetBrains WebStorm/CLion or Vim/Neovim and don't want to switch editors.
You prioritize speed and tab-completion over complex agentic workflows.

Pick Cursor if:

You are already a VS Code user and want an upgraded experience.
You prefer visual diffs when reviewing code generated across multiple files.
You want a hybrid workflow: low-latency inline completions combined with high-level prompt generation (Cmd+K).

Pick Claude Code if:

You live in the terminal (tmux, Neovim, zsh).
You want an agent that can test its own code, inspect build failures, and execute git commands.
You deal with complex refactoring tasks where logical reasoning and step-by-step troubleshooting are crucial.

Conclusion

The software engineering landscape is moving past simple code completion. While Codex paved the way for AI-driven autocompletion, tools like Cursor and Claude Code represent the next stage of agentic execution.

Many senior engineers are adopting a hybrid approach: using Cursor for visual frontend work and multi-file code editing, alongside Claude Code in the terminal for complex debugging, test suite repairs, and git automations. Try incorporating one of these advanced tools into your daily workflow to see your productivity multiply!

Docker for Developers: From Zero to Production-Ready Containers

Tien Nguyen Huynh — Sun, 30 Aug 2026 16:40:09 +0000

Every modern developer encounters Docker eventually. You have likely run docker run -p 8080:80 nginx or copied a snippet from a README to get a local database running. But moving from blindly running commands to structuring production-grade container workflows requires a deeper understanding of how Docker operates under the hood.

In this article, we will move beyond the basics of containerization. We will explore core container concepts, build a highly optimized multi-stage Dockerfile for a web application, orchestrate local environments with Docker Compose, and review production best practices that keep your images small and secure.

1. Demystifying the Core Architecture

Before writing code, let us clear up common misconceptions about Docker components.

Image: A read-only template containing your application code, runtime, system tools, libraries, and dependencies. Think of an image as a class definition in OOP.
Container: A runnable instance of an image. It is isolated from the host machine and other containers using Linux namespaces (for isolation) and cgroups (for resource limiting). Think of a container as an object instantiated from a class.
Volume: Persistent storage detached from the container lifecycle. Because containers are ephemeral by default, any data written inside a container disappears when it is destroyed. Volumes mount a directory from the host OS into the container.
Network: The abstraction layer allowing containers to communicate with each other or with external services.

2. Writing a Production-Grade Dockerfile

A simple Dockerfile gets your app running, but an optimized Dockerfile ensures fast CI/CD builds, minimal attack surfaces, and tiny deployment artifacts.

Let's look at a typical Node.js application. Here is a common mistake beginners make:

# Bad Dockerfile Example
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["node", "server.js"]

What is wrong with this approach?

Massive image size: node:18 is based on a full Debian distribution, weighing around 1GB.
Broken build cache: Copying . before running npm install invalidates Docker's layer cache on every single code change, forcing node modules to reinstall every time.
Security risk: The application runs as the root user inside the container.

The Optimized Multi-Stage Approach

Multi-stage builds allow you to use a heavy base image to compile dependencies and a lightweight image to run the final app.

Here is how to structure it properly:

# Stage 1: Build & Dependencies
FROM node:18-alpine AS builder
WORKDIR /usr/src/app

# Copy package manifests first to leverage Docker layer caching
COPY package*.json ./

# Install all dependencies (including devDependencies for building)
RUN npm ci

# Copy remaining source code
COPY . .

# Build application (if using TypeScript or bundlers)
RUN npm run build

# Prune non-production dependencies
RUN npm prune --production

# ---------------------------------------------------
# Stage 2: Production Execution
FROM node:18-alpine AS runner
WORKDIR /usr/src/app

# Set production environment
ENV NODE_ENV=production

# Create a non-privileged system user
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodejs -u 1001 -G nodejs

# Copy built assets and production node_modules from builder
COPY --from=builder /usr/src/app/package*.json ./
COPY --from=builder /usr/src/app/node_modules ./node_modules
COPY --from=builder /usr/src/app/dist ./dist

# Change ownership to non-root user
USER nodejs

EXPOSE 3000

CMD ["node", "dist/server.js"]

Key Improvements Made:

Minimal Base Image: Switching to alpine reduces the base footprint down to ~150MB.
Layer Caching: package*.json is copied separately before npm ci. Re-building after changing application logic takes seconds instead of minutes.
Multi-Stage Build: Development dependencies and build tools stay in the builder stage, keeping the runner image lean.
Least Privilege Security: Setting USER nodejs prevents potential container breakout exploits from obtaining host root access.

3. Don't Forget `.dockerignore`!

Just as .gitignore keeps clutter out of your Git repository, a .dockerignore file prevents unneeded files from entering the Docker build context. Sending gigabytes of local node modules or git history over to the Docker daemon slows down your builds.

Create a .dockerignore file alongside your Dockerfile:

node_modules
npm-debug.log
.git
.gitignore
Dockerfile
docker-compose.yml
README.md
dist
.env

4. Local Environment Orchestration with Docker Compose

Applications rarely live in isolation. You usually need an app server, a database, and perhaps a caching layer like Redis.

Rather than executing long docker run commands manually, use Docker Compose to define your stack declaratively in docker-compose.yml.

version: '3.8'

services:
  app:
    build:
      context: .
      target: runner
    ports:
      - "3000:3000"
    environment:
      - PORT=3000
      - DATABASE_URL=postgres://devuser:secretpass@db:5432/devdb
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:15-alpine
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: secretpass
      POSTGRES_DB: devdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U devuser -d devdb"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

Useful Compose Commands:

Start all services in background: docker compose up -d
View aggregated stream logs: docker compose logs -f
Stop and remove containers + networks: docker compose down
Destroy persistent volumes: docker compose down -v

5. Essential CLI Commands for Debugging

When a container refuses to start or acts unexpectedly, these commands will save your sanity:

Inspect container logs:

   docker logs -f --tail 100 <container_id_or_name>

Execute an interactive shell inside a running container:

   docker exec -it <container_id_or_name> sh

Check running container metrics (CPU, Memory, Network I/O):

   docker stats

Clean up unused images, containers, and volumes:

   docker system prune -a --volumes

Summary Checklist for Developers

To ensure your application is containerized cleanly, keep these rules in mind:

[ ] Leverage layer caching: Put commands that change infrequently (installing dependencies) near the top of your Dockerfile.
[ ] Use lightweight base images: Prefer alpine or slim tags over default full distributions.
[ ] Utilize multi-stage builds: Keep build tools out of runtime images.
[ ] Never run as root: Create and switch to a non-root system user inside the Dockerfile.
[ ] Include a .dockerignore: Do not transfer heavy build outputs or confidential .env files to the build context.
[ ] Store state outside containers: Use named volumes or managed database services for persistent storage.

Containerization transforms software delivery from predictable local builds to dependable production deployments. Master these fundamentals, and your workflows will be faster, safer, and far easier to maintain.

DEV Community: Tien Nguyen Huynh

Jenkins: Core Concepts and Declarative Pipelines for Modern Developers

Understanding the Core Architecture

1. The Controller (formerly Master)

2. Agents (formerly Slaves / Workers)

3. Executors

The Paradigm Shift: Freestyle vs. Pipeline

Declarative vs. Scripted Pipelines

Anatomy of a Declarative Pipeline

Writing a Practical Jenkinsfile

Why this approach works:

Handling Credentials Safely

Jenkins Best Practices for Developers

Wrapping Up

Beyond the Static: The Ultimate Guide to Serverless Website Deployment Platforms

Category 1: The Developer Experience Champions (Frontend-First)

1. Vercel

Code Example: A simple Vercel API Route (Next.js App Router)

2. Netlify

Category 2: The Edge Powerhouses (Performance & Cost-Efficiency)

3. Cloudflare Pages & Workers

Code Example: Cloudflare Pages Function

Category 3: The Infrastructure Heavyweights (Maximum Control)

4. AWS (Amplify & SST)

Code Example: SST Configuration (sst.config.ts)

Category 4: The Backend-as-a-Service (BaaS) Ecosystems

5. Firebase Hosting + Cloud Functions

6. Supabase (Self-hosted or Cloud)

Choosing the Right Platform: The Decision Matrix

Conclusion

Why Developers Should Use Bitwarden for Credential Management

Introduction: The Developer's Credential Dilemma

1. True Open-Source Transparency

Why Open Source Matters for Security:

2. Developer-First Workflows: The Bitwarden CLI (bw)

Installing the Bitwarden CLI

Practical CLI Usage

3. End-to-End Encryption Architecture

Key Cryptographic Details:

4. Self-Hosting Capabilities

Docker Compose Example for Official Deployment

5. Bitwarden Secrets Manager for CI/CD Pipelines

Key Advantages over Standalone Key-Value Stores:

Conclusion: Elevate Your Security Posture

Under the Hood: 5 JavaScript Fundamentals Every Intermediate Dev Should Master

1. Execution Context and the Temporal Dead Zone

Hoisting: var vs. let / const

2. Demystifying this Once and For All

Implicit Binding

Explicit Binding

Arrow Functions

3. Closures: Power, Memory, and Encapsulation

Practical Use Case: Data Encapsulation

Watch Out for Memory Leaks

4. The Event Loop: Microtasks vs. Macrotasks

The Order of Execution

5. Prototypal Inheritance Beyond class Syntax

Conclusion

Shift Left: Why Security Mindset is a Non-Negotiable Developer Skill

1. Catching Vulnerabilities Early is Cheaper and Faster

2. You Are the First Line of Defense

Bad Example: Insecure API Endpoint

Good Example: Authorization Enforced

3. SQL Injection is Still Alive Today

Vulnerable Python SQL Query

Secure Parameterized Query

4. Third-Party Dependencies Are a Massive Attack Vector

5. Security Knowledge Elevates Your Career

Essential Security Habits to Start Today

Conclusion

Mastering Keycloak: Essential Concepts Every Developer Should Know for Application Security

Core Concepts: Demystifying Keycloak Terminology

1. Realms

2. Clients

3. Users, Groups, and Roles

The Authentication Flow in Action

Quick Start: Running Keycloak with Docker

Practical Example: Validating Keycloak JWTs in a Node.js Backend

Inspecting User Roles in the JWT

Essential Best Practices for Production

2. Developer-First Workflows: The Bitwarden CLI (`bw`)

Hoisting: `var` vs. `let` / `const`

2. Demystifying `this` Once and For All

5. Prototypal Inheritance Beyond `class` Syntax

3. Don't Forget `.dockerignore`!