Forem: coder7475

Deploying a React Application to AWS: Implementing a Production-Ready CI/CD Pipeline with Terraform

coder7475 — Wed, 28 Jan 2026 16:21:31 +0000

In this article, I present a reliable configuration for deploying React applications to AWS. This approach utilizes Terraform to manage infrastructure as code, Amazon S3 for static asset storage, Amazon CloudFront for efficient content distribution, and AWS CodePipeline to automate the continuous integration and continuous deployment (CI/CD) process.

The resulting pipeline provides scalable global performance, robust security measures, and uninterrupted service during updates, with zero downtime. Operational costs are projected to range from $5 to $20 monthly, depending on traffic volume.

Rationale for the Selected Technologies

Contemporary web applications require low-latency access, consistent reliability, and streamlined automation. The AWS services employed here address these requirements comprehensively:

AWS CodePipeline coordinates the entire deployment workflow, ensuring orderly progression through each stage.
Amazon S3 offers economical and resilient storage for static files.
Amazon CloudFront employs edge caching to achieve sub-second load times worldwide.
Terraform facilitates declarative infrastructure provisioning, promoting repeatability and auditability.

Architectural Overview

The workflow initiates upon commits to the GitHub repository: the code is built using AWS CodeBuild, artifacts are synchronized to S3, CloudFront caches are invalidated through a Lambda function, and content is served via the CloudFront distribution. This design inherently supports zero-downtime deployments.

End users access the application with immediate availability of updated content, free from caching inconsistencies.

Essential Components

GitHub Repository: Acts as the version control system, triggering the pipeline upon pushes to the main branch.
AWS CodePipeline: Serves as the orchestration layer, sequencing stages for source retrieval, building, deployment, and cache invalidation.
AWS CodeBuild: Executes Node.js-based builds, including dependency installation and the production bundling command (npm ci && npm run build).
Amazon S3 Bucket: Provides private, versioned storage for deployment artifacts, with strict access controls.
Amazon CloudFront with Origin Access Control (OAC): Delivers content securely from S3, incorporating single-page application (SPA) error handling to route 403 and 404 responses appropriately.
AWS Lambda: Performs automated cache invalidation for CloudFront following each deployment, ensuring content freshness.

Prerequisites

To proceed, ensure the following are in place:

An active AWS account, preferably utilizing the free tier for initial validation.
A GitHub repository containing a React application developed with Vite.
Required tools: AWS Command Line Interface (CLI) with configured credentials, Terraform version 1.0 or later, and Node.js version 18 or higher.
Proficiency with basic command-line operations.

A detailed checklist is provided in the repository's README file.

Step 1: Prepare the React Application

Configure the Vite build settings for production deployment by updating vite.config.ts:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  base: '/',
  build: {
    outDir: 'dist',
  },
});

Execute npm run build locally to confirm that the dist directory contains the optimized assets. A sample application is available for cloning: Repository.

Step 2: Infrastructure Definition Using Terraform

Obtain the Terraform configuration files (.tf) from the repository. The following sections highlight the primary resources.

Configuration of the Private S3 Bucket

resource "random_id" "suffix" {
  byte_length = 4
}

# S3 Bucket (Private and Versioned)
resource "aws_s3_bucket" "website_bucket" {
  bucket        = "${var.project_name}-website-${random_id.suffix.hex}"
  force_destroy = true
}

resource "aws_s3_bucket_public_access_block" "website_bucket_public_access" {
  bucket                 = aws_s3_bucket.website_bucket.id
  block_public_acls      = true
  ignore_public_acls     = true
  block_public_policy    = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "website_bucket_versioning" {
  bucket = aws_s3_bucket.website_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

This configuration enforces privacy, permitting access exclusively through authorized CloudFront origins.

Amazon CloudFront Distribution with Origin Access Control

# Origin Access Control for Secure S3 Integration
resource "aws_cloudfront_origin_access_control" "s3_oac" {
  name                              = "${var.project_name}-oac"
  description                       = "OAC for ${var.project_name} S3 bucket"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

# CloudFront Distribution
resource "aws_cloudfront_distribution" "website" {
  origin {
    domain_name              = aws_s3_bucket.website_bucket.bucket_regional_domain_name
    origin_id                = "S3Origin"
    origin_access_control_id = aws_cloudfront_origin_access_control.s3_oac.id
  }

  enabled           = true
  is_ipv6_enabled   = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3Origin"
    compress         = true

    forwarded_values {
      query_string = true
      cookies {
        forward = "none"
      }
      headers = [
        "Accept", "Accept-Charset", "Accept-Encoding", "Accept-Language",
        "Origin", "Referer", "User-Agent"
      ]
    }

    min_ttl                = 0
    default_ttl            = 300  # 5 minutes
    max_ttl                = 86400  # 24 hours
    viewer_protocol_policy = "redirect-to-https"
  }

  # Extended Caching for Assets
  ordered_cache_behavior {
    path_pattern     = "/assets/*"
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3Origin"
    compress         = true

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

    min_ttl                = 0
    default_ttl            = 31536000  # 1 year
    max_ttl                = 31536000
    viewer_protocol_policy = "redirect-to-https"
  }

  # Error Responses for Single-Page Applications
  custom_error_response {
    error_code            = 404
    response_code         = 200
    response_page_path    = "/index.html"
    error_caching_min_ttl = 300
  }

  custom_error_response {
    error_code            = 403
    response_code         = 200
    response_page_path    = "/index.html"
    error_caching_min_ttl = 300
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }

  tags = {
    Name = "${var.project_name}-distribution"
  }
}

This setup ensures compatibility with React Router by redirecting 404 and 403 errors to index.html for client-side handling.

S3 Bucket Policy for CloudFront Access

resource "aws_s3_bucket_policy" "website_bucket_policy" {
  bucket = aws_s3_bucket.website_bucket.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "AllowCloudFrontOAC"
        Effect    = "Allow"
        Principal = { Service = "cloudfront.amazonaws.com" }
        Action    = ["s3:GetObject", "s3:ListBucket"]
        Resource  = [aws_s3_bucket.website_bucket.arn, "${aws_s3_bucket.website_bucket.arn}/*"]
        Condition = {
          StringEquals = { "AWS:SourceArn" = aws_cloudfront_distribution.website.arn }
        }
      }
    ]
  })
}

Inclusion of the s3:ListBucket action avoids erroneous 404 responses during object listings.

AWS CodePipeline and Lambda Integration

The pipeline comprises stages for GitHub source retrieval, CodeBuild execution, S3 synchronization, and Lambda-triggered invalidation.

The Lambda function, implemented in Python with comprehensive error handling, is as follows:

import json
import boto3
import os
from botocore.exceptions import ClientError

def handler(event, context):
    """
    Performs CloudFront cache invalidation following deployment.
    """
    cloudfront = boto3.client('cloudfront')
    codepipeline = boto3.client('codepipeline')
    job_id = event['CodePipeline.job']['id']

    try:
        distribution_id = os.environ.get('DISTRIBUTION_ID')
        if not distribution_id:
            raise ValueError("DISTRIBUTION_ID environment variable not set")

        print(f"Invalidating distribution: {distribution_id}")
        response = cloudfront.create_invalidation(
            DistributionId=distribution_id,
            InvalidationBatch={
                'Paths': {'Quantity': 1, 'Items': ['/*']},
                'CallerReference': f"pipeline-{job_id}-{context.aws_request_id}"
            }
        )
        invalidation_id = response['Invalidation']['Id']
        print(f"Invalidation created: {invalidation_id}")

        codepipeline.put_job_success_result(jobId=job_id)
        return {
            'statusCode': 200,
            'body': json.dumps({'invalidation_id': invalidation_id})
        }

    except ClientError as e:
        error_msg = f"AWS Client Error: {str(e)}"
        print(error_msg)
        codepipeline.put_job_failure_result(
            jobId=job_id,
            failureDetails={'message': error_msg}
        )
        return {'statusCode': 500, 'body': json.dumps({'error': error_msg})}

    except Exception as e:
        error_msg = f"Unexpected error: {str(e)}"
        print(error_msg)
        codepipeline.put_job_failure_result(
            jobId=job_id,
            failureDetails={'message': error_msg}
        )
        return {'statusCode': 500, 'body': json.dumps({'error': error_msg})}

Appropriate IAM permissions must be assigned to the CodePipeline execution role, including lambda:InvokeFunction.

Step 3: Provision the Infrastructure

cd terraform
cp example.terraform.tfvars terraform.tfvars  # Update project_name="myapp"
terraform init
terraform plan
terraform apply

Upon completion, Terraform will output the CloudFront distribution URL and pipeline details for reference.

Step 4: Integrate the GitHub Repository

In the AWS Management Console, navigate to CodePipeline > Connections. Authorize the GitHub App and select the target repository and branch to enable webhook-based triggers.

Step 5: Initiate the Deployment

Commit and push changes to the main branch. Monitor progress in the AWS Console:

Source Stage: Retrieves the latest code from GitHub.
Build Stage: Installs dependencies and executes npm run build.
Deploy Stage: Synchronizes the dist directory to the S3 bucket using aws s3 sync.
Invalidation Stage: Invokes the Lambda function to clear CloudFront caches.

The application will be accessible at the provisioned CloudFront URL (e.g., https://dxxxx.cloudfront.net).

Troubleshooting Common Issues

Issue	Root Cause	Resolution
Pipeline Status "Pending"	GitHub authorization failure	AWS Console > CodePipeline > Connections > Re-authorize GitHub App
CloudFront Returns 404	Missing `s3:ListBucket` permission	Update S3 policy to include the action; execute `terraform apply`
Assets Return 403	"Host" header forwarded	Remove "Host" from CloudFront `forwarded_values` configuration
Blank Application Page	Incorrect MIME types	Configure CodeBuild to set `Content-Type` during S3 synchronization
Lambda Invocation Failure	Insufficient IAM permissions	Attach `lambda:InvokeFunction` policy to the CodePipeline execution role

For manual cache invalidation, execute: aws cloudfront create-invalidation --distribution-id <ID> --paths "/*".

Scaling and Cost Management

Free Tier Benefits: Includes 1 TB of CloudFront data transfer and 5 GB of S3 storage at no additional charge.
Production Enhancements: Incorporate Amazon Route 53 for custom domains and multi-region CloudFront distributions for reduced latency.
Monitoring Practices: Establish Amazon CloudWatch alarms for error rates exceeding 1% to enable proactive remediation.

This configuration readily accommodates enterprise-scale workloads.

Conclusion

This solution establishes a solid foundation for deploying React applications on AWS with professional-grade reliability and efficiency. I recommend forking the repository, customizing as needed, and refining based on operational insights. For further inquiries, please open an issue on GitHub.

Complete Source Code and README

Understanding the ACID Concept with PostgreSQL

coder7475 — Sat, 13 Sep 2025 06:58:23 +0000

Introduction to ACID

ACID is an acronym representing Atomicity, Consistency, Isolation, and Durability, a set of properties that ensure reliable and predictable database transactions. These principles are foundational to relational database management systems (RDBMS) like PostgreSQL, guaranteeing data integrity and robustness, particularly in critical applications such as banking or inventory management. This blog explains each ACID property, demonstrates how PostgreSQL implements them, and provides practical examples.

What is ACID?

ACID properties are designed to ensure that database transactions are processed reliably, even in the presence of errors, concurrency, or system failures. They are particularly critical in systems where data accuracy and consistency are paramount, contrasting with the BASE model used in some NoSQL databases.

Components of ACID

Atomicity: Ensures a transaction is treated as a single, indivisible unit—either all operations succeed, or none are applied.
Consistency: Guarantees that a transaction brings the database from one valid state to another, adhering to all defined constraints and rules.
Isolation: Ensures transactions execute independently, preventing interference from concurrent transactions.
Durability: Guarantees that committed transactions are permanently saved, even in the event of a system failure.

ACID in PostgreSQL

PostgreSQL, a powerful open-source RDBMS, robustly implements ACID properties through its advanced features, making it a reliable choice for applications requiring strict data integrity. Below, we explore each property with PostgreSQL-specific implementations and examples.

1. Atomicity

Definition: Atomicity ensures that all operations within a transaction are completed successfully, or none are applied, preventing partial updates that could lead to data inconsistencies.

PostgreSQL Implementation:

PostgreSQL uses its transaction management system, with BEGIN, COMMIT, and ROLLBACK commands, to enforce atomicity.
If an error occurs (e.g., a constraint violation or system crash), PostgreSQL automatically rolls back the transaction, ensuring no partial changes persist.
Savepoints allow partial rollbacks within a transaction, offering fine-grained control.

Example: Transferring $100 between two bank accounts.

BEGIN;

UPDATE accounts 
SET balance = balance - 100 
WHERE account_id = 'A' AND balance >= 100;

UPDATE accounts 
SET balance = balance + 100 
WHERE account_id = 'B';

-- If both updates succeed, commit the transaction
COMMIT;

-- If an error occurs, rollback ensures no changes are applied
-- ROLLBACK;

Explanation: If the debit from Account A succeeds but the credit to Account B fails, PostgreSQL rolls back both operations, ensuring atomicity.

2. Consistency

Definition: Consistency ensures that a transaction transitions the database from one valid state to another, respecting all constraints, such as primary keys, foreign keys, and check constraints.

PostgreSQL Implementation:

PostgreSQL enforces constraints (e.g., PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE) during transactions to maintain data integrity.
The Multiversion Concurrency Control (MVCC) system ensures that each transaction operates on a consistent snapshot of the database.
Triggers and rules can further enforce custom consistency requirements.

Example: Inserting a record with a constraint.

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    age INT CHECK (age >= 18)
);

BEGIN;
INSERT INTO employees (name, age) VALUES ('Alice', 25); -- Valid
INSERT INTO employees (name, age) VALUES ('Bob', 16);   -- Violates CHECK constraint
COMMIT;

Explanation: The second INSERT fails due to the age >= 18 constraint, causing the transaction to roll back, preserving database consistency.

3. Isolation

Definition: Isolation ensures that transactions execute independently, preventing partial changes from one transaction from affecting others until committed.

PostgreSQL Implementation:

PostgreSQL’s MVCC provides each transaction with a snapshot of the database, isolating it from concurrent changes.
Supported isolation levels include:
- Read Committed (default): Transactions see only committed data.
- Repeatable Read: Prevents non-repeatable reads by using a consistent snapshot.
- Serializable: Ensures transactions behave as if executed sequentially, preventing phantom reads.
Isolation levels are set using SET TRANSACTION ISOLATION LEVEL.

Example: Concurrent updates with Repeatable Read.

-- Transaction 1
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT balance FROM accounts WHERE account_id = 'A'; -- Sees balance as 500
-- (Other transaction updates balance to 600)
SELECT balance FROM accounts WHERE account_id = 'A'; -- Still sees 500
COMMIT;

-- Transaction 2
BEGIN;
UPDATE accounts SET balance = 600 WHERE account_id = 'A';
COMMIT;

Explanation: MVCC ensures Transaction 1 sees a consistent snapshot, isolating it from Transaction 2’s update until it commits.

4. Durability

Definition: Durability guarantees that once a transaction is committed, its changes are permanently saved, even if the system fails immediately after.

PostgreSQL Implementation:

PostgreSQL uses Write-Ahead Logging (WAL) to record transaction details to non-volatile storage before committing.
The fsync configuration ensures data is physically written to disk.
Checkpoints optimize recovery by periodically syncing the database state with the WAL.

Example: Committing a transaction.

BEGIN;
INSERT INTO orders (order_id, product, amount) VALUES (1, 'Laptop', 999.99);
COMMIT;

Explanation: The INSERT is logged to the WAL before the COMMIT completes. If the server crashes, PostgreSQL replays the WAL to recover the committed transaction, ensuring durability.

PostgreSQL-Specific Features Supporting ACID

MVCC: Enables consistency and isolation by providing transaction snapshots, reducing conflicts in concurrent environments.
WAL: Ensures durability and supports crash recovery by logging all changes.
Checkpoints: Improve recovery efficiency by marking stable database states.
Transaction Commands: BEGIN, COMMIT, ROLLBACK, and SAVEPOINT provide precise control over transactions.
Constraint Enforcement: Validates data integrity with primary keys, foreign keys, and custom triggers.

Practical Example: Bank Transfer

A complete example of a bank transfer demonstrating all ACID properties.

CREATE TABLE accounts (
    account_id VARCHAR(10) PRIMARY KEY,
    balance NUMERIC CHECK (balance >= 0)
);

INSERT INTO accounts (account_id, balance) VALUES ('A', 500), ('B', 200);

BEGIN;
-- Check sufficient funds
UPDATE accounts 
SET balance = balance - 100 
WHERE account_id = 'A' AND balance >= 100;

-- Credit the recipient
UPDATE accounts 
SET balance = balance + 100 
WHERE account_id = 'B';

-- Ensure both updates succeed
COMMIT;

Explanation:

Atomicity: Both UPDATE statements succeed, or both are rolled back.
Consistency: The CHECK (balance >= 0) constraint ensures valid balances.
Isolation: MVCC prevents other transactions from seeing partial updates.
Durability: WAL ensures the committed changes persist after a crash.

Conclusion

PostgreSQL’s robust implementation of ACID properties—through MVCC, WAL, constraint enforcement, and transaction management—makes it a reliable choice for applications requiring high data integrity. Whether managing financial transactions, e-commerce orders, or enterprise data, PostgreSQL ensures atomic, consistent, isolated, and durable operations, providing a solid foundation for mission-critical systems.

References

PostgreSQL Documentation: https://www.postgresql.org/docs/current/mvcc.html
Write-Ahead Logging (WAL): https://www.postgresql.org/docs/current/wal.html
Transaction Management in PostgreSQL: https://www.postgresql.org/docs/current/tutorial-transactions.html
ACID Properties Overview: https://www.geeksforgeeks.org/acid-properties-in-dbms/
PostgreSQL Isolation Levels: https://www.postgresql.org/docs/current/transaction-iso.html

Running PostgreSQL in Docker and Accessing It from Your OS

coder7475 — Tue, 26 Aug 2025 01:36:18 +0000

Running PostgreSQL in Docker and Accessing It from Your OS

PostgreSQL is one of the most popular relational databases, widely used in modern applications for its reliability and powerful features. Running it inside Docker makes local development and testing much easier, as you can quickly spin up and tear down isolated environments.

In this post, we’ll see how to:

Run PostgreSQL inside a Docker container.
Use Docker Compose for easier setup.
Connect to PostgreSQL from your local machine.
Get the connection URI for your applications.

Running PostgreSQL with Docker

You can start PostgreSQL with a single docker run command:

docker run --name postgres-container \
  -e POSTGRES_USER=admin \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_DB=mydb \
  -p 5432:5432 \
  -d postgres:15

--name postgres-container → assigns a name to the container.
POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB → environment variables for setup.
-p 5432:5432 → maps PostgreSQL’s port to your host machine.
postgres:15 → uses the official PostgreSQL image (version 15).

Once started, you can connect with:

psql -h localhost -U admin -d mydb

It will prompt for the password (secret).

Using Docker Compose

Instead of remembering a long docker run command, we can use docker-compose for a cleaner setup.

Create a file named docker-compose.yml:

version: "3.9"
services:
  postgres:
    image: postgres:15
    container_name: postgres-container
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Run it with:

docker-compose up -d

This will:

Start PostgreSQL in a container.
Expose it on port 5432.
Persist data in a Docker volume so it isn’t lost when the container restarts.

Connecting from Your OS

Now you can connect using any PostgreSQL client:

From terminal:

psql -h localhost -U admin -d mydb

From GUI tool (like pgAdmin, DBeaver, or TablePlus):

Host: localhost
Port: 5432
User: admin
Password: secret
Database: mydb

Connection URI

For use in applications, you’ll often need the full PostgreSQL connection URI.

From your host machine:

postgresql://admin:secret@localhost:5432/mydb

From another service inside the same Docker Compose network:

postgresql://admin:secret@postgres:5432/mydb

(where postgres is the service name defined in docker-compose.yml).

Wrapping Up

Running PostgreSQL with Docker makes your development environment consistent, portable, and easy to manage. With Docker Compose, you get reproducible configurations and persistent storage with minimal effort.

You can now connect directly using psql, GUI clients, or application frameworks by providing the connection URI.

Running MongoDB in Docker and Accessing It from Your OS

coder7475 — Sun, 24 Aug 2025 05:58:49 +0000

MongoDB is one of the most popular NoSQL databases, and running it inside a Docker container makes it lightweight, isolated, and portable. In this post, we’ll walk through how to set up MongoDB with Docker, persist your data, and access it both from your application containers and directly from your host machine (OS) using tools like MongoDB Compass.

🔹 Why Use Docker for MongoDB?

Isolation: MongoDB runs in a container, independent of your OS setup.
Portability: Same configuration runs on any machine with Docker.
Persistence: Store data in Docker volumes so it survives container restarts.
Networking: Easy communication between your app and MongoDB using Docker networks.

🛠 Step 1: Run MongoDB in Docker

We’ll start with a simple docker run command:

docker run -d \
  --name mongo \
  -p 27017:27017 \
  -e MONGO_INITDB_ROOT_USERNAME=root \
  -e MONGO_INITDB_ROOT_PASSWORD=example \
  -v mongo-data:/data/db \
  mongo:7

Explanation:

-d → run in detached mode
--name mongo → name the container mongo
-p 27017:27017 → map container port 27017 to host port 27017
-e MONGO_INITDB_ROOT_USERNAME=root → admin username
-e MONGO_INITDB_ROOT_PASSWORD=example → admin password
-v mongo-data:/data/db → persistent storage for MongoDB data
mongo:7 → official MongoDB v7 image

Now you have MongoDB running in Docker 🎉

🛠 Step 2: Verify MongoDB Is Running

Run:

docker ps

You should see your mongo container up and exposing port 27017.

🛠 Step 3: Access MongoDB from Your OS

Since we mapped port 27017, you can connect using localhost from your machine.

Using MongoDB Compass:

Open Compass.

Enter the connection string:

mongodb://root:example@localhost:27017/mydatabase?authSource=admin

- `root:example` → matches the username/password set in `docker run`

- `localhost:27017` → because the port is exposed to your host

- `mydatabase` → any database you want to connect to

- `authSource=admin` → required since root user is created in the `admin` database

Click Connect ✅

🛠 Step 4: Access MongoDB from CLI

You can also connect from your terminal using mongosh (if installed):

mongosh "mongodb://root:example@localhost:27017/mydatabase?authSource=admin"

🛠 Step 5: Access MongoDB from Another Container

If your application container needs to connect to MongoDB:

Use the container name (mongo) as hostname inside the Docker network.
Example .env for your app:

MONGO_URL=mongodb://root:example@mongo:27017/mydatabase?authSource=admin

🔑 Note: mongo works inside Docker network, but from your host OS, you must use localhost.

🎯 Wrapping Up

You’ve just:

Run MongoDB in Docker with persistence.
Connected from your host OS using localhost.
Learned the difference between connecting from inside Docker vs. outside.

This approach is great for local development, prototyping, or even small deployments. For production, you’d likely want to configure authentication, backups, and monitoring.

Want to Learn OOP Principle SOLID in TypeScript. This post is for you!!

coder7475 — Wed, 20 Aug 2025 13:12:08 +0000

Mastering the SOLID Principles — The Foundation of Clean, Scalable Code

coder7475 ・ Aug 18 '25

#oop #typescript #solid #designpatterns

Comprehensive OOP concepts explained with concise and easy-to-understand examples.

coder7475 — Tue, 19 Aug 2025 05:27:08 +0000

coder7475

Aug 18 '25

The Four Pillars of Object-Oriented Programming in TypeScript

#oop #programing #typescript

Comments

3 min read

Mastering the SOLID Principles — The Foundation of Clean, Scalable Code

coder7475 — Mon, 18 Aug 2025 13:38:09 +0000

If you want to write cleaner, more maintainable, and scalable software, mastering the SOLID principles is essential. These five core object-oriented design principles empower you to build systems that are easier to understand, extend, and test — without introducing chaos.

Here's a quick breakdown:

S — Single Responsibility Principle (SRP)

Every class or module should have one clear responsibility.

When a class tries to do too many things, it becomes harder to maintain and more prone to bugs.

O — Open/Closed Principle (OCP)

Software should be open for extension, but closed for modification.

You should be able to add new features without rewriting existing code, minimizing the risk of regressions.

L — Liskov Substitution Principle (LSP)

Subtypes must be replaceable for their base types without altering the program’s behavior.

If a subclass breaks the expectations set by the parent class, it violates this principle.

I — Interface Segregation Principle (ISP)

Don't force a class to implement methods it doesn't need.

Instead of one large interface, create smaller, role-specific interfaces.

D — Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules — both should depend on abstractions.

This decouples your code and makes it easier to modify and test.

The SOLID principles are foundational guidelines for object-oriented design. They help you create clean, maintainable, and scalable software systems. This guide includes detailed explanations and practical TypeScript examples to illustrate each principle.

S — Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change, meaning it should have a single, well-defined responsibility.

Why It Matters: Mixing responsibilities (e.g., validation and persistence) makes a class fragile—changes to one task can break others. SRP improves modularity and testability.

Violation Example:

// SRP Violating Example
interface Order {
    id: number;
    items: string[];
    total: number;
    customerEmail: string;
}

class OrderProcessor {
    processOrder(order: Order): void {
        if (!order) throw new Error("Order cannot be null");

        // 1. Validate order
        if (order.items.length === 0) {
            throw new Error("Order must have at least one item");
        }

        // 2. Process payment
        console.log(`Processing payment of $${order.total} for order ${order.id}`);

        // 3. Save to database
        console.log(`Saving order ${order.id} with ${order.items.length} items to database`);

        // 4. Send confirmation email
        console.log(`Sending confirmation email to ${order.customerEmail}`);
    }
}

This class handles too much, making it hard to maintain.

Refactored (SRP Applied):

interface Order {
    id: number;
    items: string[];
    total: number;
}

class OrderValidator {
    validate(order: Order): void {
        if (!order) throw new Error("Order cannot be null");
    }
}

class PaymentProcessor {
    processPayment(order: Order): void {
        console.log(`Processing payment for order ${order.id}`);
    }
}

class OrderRepository {
    save(order: Order): void {
        console.log(`Saving order ${order.id} to database`);
    }
}

class EmailNotifier {
    sendConfirmation(order: Order): void {
        console.log(`Sending confirmation email for order ${order.id}`);
    }
}

class OrderProcessor {
    private validator: OrderValidator;
    private paymentProcessor: PaymentProcessor;
    private repository: OrderRepository;
    private notifier: EmailNotifier;

    constructor(
        validator: OrderValidator,
        paymentProcessor: PaymentProcessor,
        repository: OrderRepository,
        notifier: EmailNotifier
    ) {
        this.validator = validator;
        this.paymentProcessor = paymentProcessor;
        this.repository = repository;
        this.notifier = notifier;
    }

    process(order: Order): void {
        this.validator.validate(order);
        this.paymentProcessor.processPayment(order);
        this.repository.save(order);
        this.notifier.sendConfirmation(order);
    }
}

Each class now focuses on one task, enhancing clarity and flexibility.

O — Open/Closed Principle (OCP)

Definition: Software entities should be open for extension but closed for modification.

Why It Matters: Modifying existing code risks bugs. OCP allows new functionality via extensions (e.g., interfaces) without altering tested code.

Violation Example:

class InvoicePrinter {
    print(invoice: any, format: string): void {
        if (format === "PDF") {
            // Generate PDF
        } else if (format === "Excel") {
            // Generate Excel
        }
    }
}

Adding a new format requires changing this class.

Refactored (OCP Applied):

interface Invoice {
    id: number;
    amount: number;
}

interface IInvoicePrinter {
    print(invoice: Invoice): void;
}

class PdfInvoicePrinter implements IInvoicePrinter {
    print(invoice: Invoice): void {
        console.log(`Printing PDF invoice for invoice ${invoice.id}`);
    }
}

class ExcelInvoicePrinter implements IInvoicePrinter {
    print(invoice: Invoice): void {
        console.log(`Printing Excel invoice for invoice ${invoice.id}`);
    }
}

class InvoiceService {
    private printer: IInvoicePrinter;

    constructor(printer: IInvoicePrinter) {
        if (!printer) throw new Error("Printer cannot be null");
        this.printer = printer;
    }

    printInvoice(invoice: Invoice): void {
        this.printer.print(invoice);
    }
}

New printers (e.g., HtmlInvoicePrinter) can be added without modifying InvoiceService.

L — Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types without altering expected behavior.

Why It Matters: Violating LSP causes errors when subclasses don’t meet the parent’s contract.

Violation Example:

class Vehicle {
    startEngine(): void {
        // Start engine
    }
}

class ElectricCar extends Vehicle {
    startEngine(): void {
        throw new Error("Electric cars don’t have engines!");
    }
}

ElectricCar breaks code expecting startEngine.

Refactored (LSP Respected):

abstract class Vehicle {
    abstract start(): void;
}

interface ICombustionVehicle {
    startEngine(): void;
}

class GasolineCar extends Vehicle implements ICombustionVehicle {
    start(): void {
        this.startEngine();
    }

    startEngine(): void {
        console.log("Gasoline engine started.");
    }
}

class ElectricCar extends Vehicle {
    start(): void {
        console.log("Electric motor activated.");
    }
}

Both subclasses work as Vehicle without issues.

I — Interface Segregation Principle (ISP)

Definition: Classes shouldn’t be forced to implement unused interfaces.

Why It Matters: Large interfaces create unnecessary dependencies. ISP favors smaller, specific interfaces.

Violation Example:

interface IWorker {
    work(): void;
    takeBreak(): void;
}

class Robot implements IWorker {
    work(): void {
        console.log("Robot working...");
    }

    takeBreak(): void {
        throw new Error("Robots don’t take breaks!");
    }
}

Robot is forced to implement an irrelevant method.

Refactored (ISP Applied):

interface IWorkable {
    work(): void;
}

interface IBreakable {
    takeBreak(): void;
}

class Human implements IWorkable, IBreakable {
    work(): void {
        console.log("Human working...");
    }

    takeBreak(): void {
        console.log("Human taking a break...");
    }
}

class Robot implements IWorkable {
    work(): void {
        console.log("Robot working...");
    }
}

Robot only implements what it needs.

D — Dependency Inversion Principle (DIP)

Definition: High-level modules should depend on abstractions, not low-level details.

Why It Matters: Tight coupling limits flexibility. DIP uses abstractions for loose coupling.

Violation Example:

class Notification {
    private emailService = new EmailService();

    send(message: string): void {
        this.emailService.sendEmail(message);
    }
}

class EmailService {
    sendEmail(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

Notification is tied to EmailService.

Refactored (DIP Applied):

interface IMessageService {
    send(message: string): void;
}

class EmailService implements IMessageService {
    send(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

class SmsService implements IMessageService {
    send(message: string): void {
        console.log(`SMS sent: ${message}`);
    }
}

class Notification {
    private service: IMessageService;

    constructor(service: IMessageService) {
        if (!service) throw new Error("Service cannot be null");
        this.service = service;
    }

    send(message: string): void {
        this.service.send(message);
    }
}

Notification works with any IMessageService implementation.

Final Thoughts

Applying SOLID in TypeScript yields cleaner, more testable, and adaptable code.

The Four Pillars of Object-Oriented Programming in TypeScript

coder7475 — Mon, 18 Aug 2025 04:06:47 +0000

Object-Oriented Programming (OOP) is built on four fundamental principles, often referred to as the "pillars" of OOP. These principles help developers create modular, maintainable, and scalable software systems. The four pillars are:

Encapsulation
Abstraction
Inheritance
Polymorphism

Let’s explore each pillar with practical TypeScript examples.

1. Encapsulation

Encapsulation bundles data and methods into a class while restricting direct access to internal details, using access modifiers and getters/setters. It hides complexity and protects state integrity.

Purpose: Safeguards data from invalid modifications, improves maintainability, and supports modularity.

Example:

class BankAccount {
    private balance: number = 0;

    public deposit(amount: number): void {
        if (amount > 0) this.balance += amount;
    }

    public withdraw(amount: number): void {
        if (amount > 0 && amount <= this.balance) this.balance -= amount;
    }

    public getBalance(): number {
        return this.balance;
    }
}

const account = new BankAccount();
account.deposit(100);
account.withdraw(50);
console.log(account.getBalance());  // Output: 50

Benefits: Enhances security, reduces dependencies on internal implementations.

2. Abstraction

Abstraction conceals intricate details, exposing only essential functionalities. It is realized through abstract classes or interfaces, emphasizing "what" over "how."

Purpose: Simplifies complexity, boosts readability, and facilitates loose coupling.

Example using an abstract class:

abstract class Shape {
    abstract calculateArea(): number;
}

class Circle extends Shape {
    constructor(private radius: number) { super(); }

    calculateArea(): number {
        return Math.PI * this.radius ** 2;
    }
}

class Rectangle extends Shape {
    constructor(private width: number, private height: number) { super(); }

    calculateArea(): number {
        return this.width * this.height;
    }
}

const shapes: Shape[] = [new Circle(5), new Rectangle(4, 6)];
shapes.forEach(shape => console.log(shape.calculateArea()));
// Output: 78.53981633974483 \n 24

Benefits: Promotes reusability and easier updates.

For interfaces (another abstraction tool):

interface Shape {
    calculateArea(): number;
}

class Circle implements Shape {
    // Implementation as above
}

Interfaces define contracts without implementations, supporting multiple inheritance.

Difference Between Abstract Class and Interface: Abstract classes can include implemented methods and are suited for shared behavior in related classes (single inheritance only). Interfaces mandate full implementation and allow multiple implementations for unrelated classes.

3. Inheritance

Inheritance enables a child class to acquire properties and methods from a parent class, fostering code reuse and hierarchical structures.

Purpose: Minimizes duplication, models real-world relationships, and supports extension.

Example:

class Animal {
    constructor(protected name: string) {}

    move(distance: number): void {
        console.log(`${this.name} moved ${distance} meters.`);
    }
}

class Dog extends Animal {
    constructor(name: string) { super(name); }

    bark(): void {
        console.log('Woof! Woof!');
    }
}

const dog = new Dog('Buddy');
dog.move(10);  // Output: Buddy moved 10 meters.
dog.bark();    // Output: Woof! Woof!

Benefits: Enhances extensibility, but caution against overuse to avoid fragile hierarchies; prefer composition where appropriate.

4. Polymorphism

Polymorphism permits objects of varied classes to be handled via a common interface, with behavior varying by type. It includes compile-time (overloading) and runtime (overriding) forms.

Purpose: Increases flexibility and adaptability.

Types:

Compile-time (Static Binding/Method Overloading): Methods with identical names but differing parameters; resolved at compile time.
Runtime (Dynamic Binding/Method Overriding): Child classes redefine parent methods; resolved at runtime using virtual methods.

Overloading example:

class MessageFormatter {
  // Overload signatures
  format(message: string): string;
  format(message: string, userId: number): string;
  format(message: string, userId: number, timestamp: Date): string;

  // Single implementation
  format(message: string, userId?: number, timestamp?: Date): string {
    let formatted = message;

    if (userId !== undefined) {
      formatted = `[User ${userId}] ${formatted}`;
    }
    if (timestamp !== undefined) {
      formatted = `${formatted} (at ${timestamp.toISOString()})`;
    }

    return formatted;
  }
}

const formatter = new MessageFormatter();

console.log(formatter.format("System started"));
// Output: System started

console.log(formatter.format("User logged in", 42));
// Output: [User 42] User logged in

console.log(formatter.format("File uploaded", 42, new Date()));
// Output: [User 42] File uploaded (at 2025-08-20T13:10:15.000Z)

Overriding example (using virtual-like behavior via method overriding):

abstract class Payment {
  abstract process(amount: number): void;
}

class CreditCardPayment extends Payment {
  process(amount: number): void {
    console.log(`Processing credit card payment of $${amount}`);
  }
}

class PayPalPayment extends Payment {
  process(amount: number): void {
    console.log(`Processing PayPal payment of $${amount}`);
  }
}

class CryptoPayment extends Payment {
  process(amount: number): void {
    console.log(`Processing cryptocurrency payment of $${amount}`);
  }
}

const payments: Payment[] = [
  new CreditCardPayment(),
  new PayPalPayment(),
  new CryptoPayment(),
];

payments.forEach((payment) => payment.process(100));

// Output:
// Processing credit card payment of $100
// Processing PayPal payment of $100
// Processing cryptocurrency payment of $100

What is a Virtual Method?: A method in a base class that can be overridden in child classes to enable runtime polymorphism.

Difference Between Overloading and Overriding:

Overloading: Same name, different parameters, same class, compile-time resolution.
Overriding: Same signature, different classes (child overrides parent), runtime resolution.

Benefits: Aligns with the Open/Closed Principle, allowing extension without modification.

Summary

Encapsulation: Protects data with controlled access (e.g., BankAccount).
Abstraction: Hides complexity, exposing only essentials (e.g., Shape).
Inheritance: Reuses and extends code (e.g., Animal and Dog).
Polymorphism: Enables flexible behavior (e.g., makeSound() variations).

These pillars, implemented effectively in TypeScript, empower developers to build robust, scalable systems. Let me know if you’d like further clarification or additional examples!

Database Normalization and Denormalization

coder7475 — Thu, 07 Aug 2025 12:27:49 +0000

Normalization and denormalization are cornerstone techniques in database design, each serving distinct purposes in balancing data integrity and performance. In critical systems like medical databases, where accurate patient records and rapid data access can impact lives, these approaches are vital. Using a medical system as an example, this blog explores normalization and denormalization through a Socratic lens, encouraging you to reason through their principles, applications, and trade-offs.

What Are Database Anomalies and Why Do They Matter?

Imagine a medical database where all patient, doctor, and appointment data is stored in a single table. If a patient updates their phone number, how many records must you change to keep the data consistent? If you delete a canceled appointment, what happens if it also removes the patient’s only record? These issues—update anomalies (inconsistent updates), delete anomalies (unintended data loss), and insert anomalies (inability to add data without related records)—can disrupt a hospital’s operations.

Normalization is designed to prevent these anomalies by organizing data systematically. Let’s explore how it works using a medical system with entities like Patients, Doctors, Appointments, Medical Records, and Medical Facilities.

Normalization: Structuring Data for Integrity

Normalization is like organizing a hospital’s records into a logical system where each piece of information has a unique place, much like a librarian cataloging books to avoid duplicates and ensure easy access. It involves breaking down a large table into smaller, related tables linked by keys, eliminating redundancy and preventing anomalies.

Normalization follows a series of rules called normal forms, each addressing specific data dependencies. Let’s apply these to a medical database.

Functional Dependencies: The Building Blocks

Before diving into normal forms, consider functional dependencies. If a PatientID uniquely determines a patient’s FirstName and LastName, written as PatientID → FirstName, LastName, what does this suggest about how we should store patient data? Functional dependencies ensure attributes are logically related, guiding the normalization process.

First Normal Form (1NF): The Foundation of Organization

A table is in 1NF if:

All attributes are atomic (indivisible).
Each column has a unique name.
All entries in a column are of the same data type.
Each row is unique, typically enforced by a primary key.

Consider a denormalized table in our medical system:

AppointmentID	PatientName	DoctorName	AppointmentDetails
1	John Doe	Alice Smith	2023-01-01, 10:00, Checkup
2	Jane Roe	Bob Johnson	2023-01-02, 11:00, Surgery

The AppointmentDetails column contains multiple values (date, time, type), violating 1NF.To achieve 1NF, we split the data:

AppointmentID	PatientName	DoctorName	AppointmentDate	AppointmentTime	AppointmentType
1	John Doe	Alice Smith	2023-01-01	10:00	Checkup
2	Jane Roe	Bob Johnson	2023-01-02	11:00	Surgery

Now, each cell is atomic, and the table is in 1NF. Next up is 2NF.

Second Normal Form (2NF): Eliminating Partial Dependencies

A table is in 2NF if:

It is in 1NF.
All non-key attributes fully depend on the entire primary key, avoiding partial dependencies.

Suppose the primary key is (AppointmentID, PatientID):

AppointmentID	PatientID	PatientName	DoctorName	AppointmentDate	AppointmentTime	AppointmentType
1	1	John Doe	Alice Smith	2023-01-01	10:00	Checkup
2	2	Jane Roe	Bob Johnson	2023-01-02	11:00	Surgery

Here, PatientName depends only on PatientID, not the full key (AppointmentID, PatientID). To achieve 2NF, we split the table:

Patients Table:

PatientID	FirstName	LastName
1	John	Doe
2	Jane	Roe

Appointments Table:

AppointmentID	PatientID	DoctorName	AppointmentDate	AppointmentTime	AppointmentType
1	1	Alice Smith	2023-01-01	10:00	Checkup
2	2	Bob Johnson	2023-01-02	11:00	Surgery

Now, PatientName depends only on PatientID. Now that we've eliminated partial dependencies with 2NF, the next concern is transitive dependencies—where non-key fields depend on other non-key fields

Third Normal Form (3NF): Removing Transitive Dependencies

A table is in 3NF if:

It is in 2NF.
No non-key attribute depends on another non-key attribute (transitive dependency).

Let’s add doctor specialization to the Appointments table:

AppointmentID	PatientID	DoctorName	DoctorSpecialization	AppointmentDate	AppointmentTime	AppointmentType
1	1	Alice Smith	Cardiology	2023-01-01	10:00	Checkup
2	2	Bob Johnson	Neurology	2023-01-02	11:00	Surgery

Here, DoctorSpecialization depends on DoctorName, not the primary key (AppointmentID, PatientID). This is a transitive dependency.To achieve 3NF, we create a Doctors table:

Doctors Table:

DoctorID	FirstName	LastName	Specialization
1	Alice	Smith	Cardiology
2	Bob	Johnson	Neurology

Appointments Table (Updated):

AppointmentID	PatientID	DoctorID	AppointmentDate	AppointmentTime	AppointmentType
1	1	1	2023-01-01	10:00	Checkup
2	2	2	2023-01-02	11:00	Surgery

Now, Specialization depends on DoctorID, eliminating the transitive dependency.

Boyce-Codd Normal Form (BCNF): The Strictest Form

A table is in BCNF if it is in 3NF and every determinant (an attribute that determines another) is a candidate key. Consider a table for doctor schedules:

DoctorID	FacilityID	FacilityName	ScheduleDay
1	1	City Hospital	Monday
2	2	Clinic North	Tuesday

If FacilityName determines FacilityID, this violates BCNF because FacilityName is not a candidate key. To achieve BCNF, we split the table:

Facilities Table:

FacilityID	FacilityName
1	City Hospital
2	Clinic North

DoctorSchedules Table:

DoctorID	FacilityID	ScheduleDay
1	1	Monday
2	2	Tuesday

Denormalization: Prioritizing Performance

Normalization ensures data integrity but can slow queries requiring multiple joins, such as retrieving a patient’s appointment history with doctor and facility details. In a hospital, why might quick access to such data be essential, like for an emergency room dashboard? Denormalization introduces redundancy to optimize query performance.

When to Denormalize

Denormalization is useful for:

Read-Heavy Operations: Dashboards showing appointment schedules.
Complex Queries: Combining patient, doctor, and medical record data.
Precomputed Results: Storing aggregates, like the number of appointments per doctor.

For example, a normalized query for appointment details might be:

SELECT a.AppointmentID, p.FirstName AS PatientFirst, p.LastName AS PatientLast,
       d.FirstName AS DoctorFirst, d.LastName AS DoctorLast, a.AppointmentDate
FROM Appointments a
JOIN Patients p ON a.PatientID = p.PatientID
JOIN Doctors d ON a.DoctorID = d.DoctorID;

This query is slow for large datasets. A denormalized table might look like:

AppointmentID	PatientFirst	PatientLast	DoctorFirst	DoctorLast	AppointmentDate
1	John	Doe	Alice	Smith	2023-01-01
2	Jane	Roe	Bob	Johnson	2023-01-02

A simple SELECT * FROM AppointmentDetails is faster.

Denormalization Pros and Cons

Aspect	Pros	Cons
Performance	Faster reads due to fewer joins	Slower writes due to redundancy
Query Simplicity	Simpler SELECT statements	Complex updates to maintain consistency
Storage	-	Increased storage needs
Data Integrity	-	Risk of inconsistencies

Applying Normalization and Denormalization to a Medical System

Consider a medical database with:

Patients: PatientID, FirstName, LastName, DateOfBirth, ContactNumber, Email
Doctors: DoctorID, FirstName, LastName, Specialization, ContactNumber
Appointments: AppointmentID, PatientID, DoctorID, AppointmentDate, AppointmentTime, Status
Medical Records: RecordID, AppointmentID, Diagnosis, Prescription, TestResults
Facilities: FacilityID, FacilityName, Location
DoctorFacilities: Junction table for many-to-many relationships between doctors and facilities.

Normalized Design

The database is split into tables linked by foreign keys, ensuring integrity. For example, Appointments references PatientID and DoctorID.

Denormalized Design

For a dashboard showing appointment schedules, a materialized view might combine data:

CREATE MATERIALIZED VIEW AppointmentSummary AS
SELECT a.AppointmentID, p.FirstName AS PatientFirst, p.LastName AS PatientLast,
       d.FirstName AS DoctorFirst, d.LastName AS DoctorLast, d.Specialization,
       a.AppointmentDate, a.AppointmentTime
FROM Appointments a
JOIN Patients p ON a.PatientID = p.PatientID
JOIN Doctors d ON a.DoctorID = d.DoctorID;

This view speeds up queries but requires periodic refreshes to stay consistent.

Enforcing Integrity with Constraints

In a medical system, constraints ensure data reliability:

Primary Key: PatientID ensures unique patient records.
Foreign Key: PatientID in Appointments references Patients.
Unique Constraint: Email in Patients prevents duplicates.
Check Constraint: AppointmentDate ensures future dates.

Conclusion

Normalization and denormalization are complementary strategies in database design. Normalization builds a robust, anomaly-free structure, ideal for transactional medical systems where accuracy is paramount. Denormalization enhances performance for read-heavy tasks, like generating appointment reports. By understanding and balancing these approaches, you can design a medical database that is both reliable and efficient.

How to Install Docker Engine on Ubuntu (Debian)

coder7475 — Tue, 22 Jul 2025 17:45:54 +0000

📌 This is a follow-up to my previous post: How Docker Works Internally

Before you can install Docker Engine on a fresh Ubuntu (or Debian-based) system, you need to set up Docker’s official apt repository. Once configured, you’ll be able to install and update Docker packages directly from Docker’s maintained repositories, ensuring you're always using the latest stable versions.-

1. Set up Docker's `apt` repository

Follow these steps to configure the repository:

# Update package index and install prerequisites:
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg

# Create a directory for Docker's GPG key:
sudo install -m 0755 -d /etc/apt/keyrings

# Download Docker's official GPG key and convert to gpg format:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add Docker's repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update the package index again:
sudo apt-get update

2. Install Docker packages

Install the latest version of Docker Engine and its components:

sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

✅ The docker-buildx-plugin is included here, enabling advanced build features such as multi-platform builds.

3. Check Docker and containerd status

Verify that Docker and containerd services are running:

sudo systemctl status containerd
sudo systemctl status docker

If either service is inactive, start them using:

sudo systemctl start containerd
sudo systemctl start docker

4. Verify the installation

Run the hello-world image to confirm Docker is working correctly:

sudo docker run hello-world

This command downloads a test image, runs it in a container, and prints a confirmation message.

5. Run Docker without `sudo`

To avoid using sudo with every Docker command, add your user to the Docker group:

sudo usermod -aG docker $USER
newgrp docker

6. Final verification

Run the hello-world image again, this time without sudo:

docker run hello-world

7. (Optional) Enable and verify Docker Buildx

If you want to use advanced features like multi-platform builds, remote caching, or custom builders, set up Docker Buildx.

🔍 Check if Buildx is available:

docker buildx version

Expected output:

github.com/docker/buildx v0.11.2-docker ...

If no version is shown or you get an error, restart Docker:

sudo systemctl restart docker

🛠️ Initialize and bootstrap a new builder:

docker buildx create --use --name mybuilder
docker buildx inspect --bootstrap

This ensures you're ready for multi-architecture builds.

✅ Confirm the builder is ready:

docker buildx ls

You should see your builder (mybuilder) marked as current and bootstrapped.

✅ Example Workflow

docker buildx create --use --name mybuilder 
docker buildx inspect --bootstrap 

docker buildx build --platform linux/amd64,linux/arm64 -t myimage:latest .

This builds your image for both amd64 and arm64 architectures.

References

How Docker Works Internally

coder7475 — Fri, 18 Jul 2025 15:36:23 +0000

Docker has changed how we build, ship, and deploy applications by offering lightweight, portable, and fast containers.

But what makes Docker work under the hood?

In this blog, we’ll dive into Docker’s architecture and the Linux technologies that power it.

📖 New to Docker? Check out the Introduction to Docker to understand the basics before diving into internals.

⚙️ The Underlying Technology

Docker is written in Go, a modern systems programming language known for its speed and concurrency support.

At its core, Docker Engine uses several Linux kernel features to deliver containerization:

Linux Containers (LXC)
Control Groups (cgroups)
Union File Systems (UnionFS)
Namespaces

Docker’s architecture is conceptually similar to LXC but adds tooling, APIs, and image management, making containers easier to use for developers.

⚙️ The Underlying Technology

Docker is written in Go, a modern systems programming language known for its speed and concurrency support.

At its core, Docker Engine uses several Linux kernel features to deliver containerization:

Linux Containers (LXC)
Control Groups (cgroups)
Union File Systems (UnionFS)
Namespaces

Docker’s architecture is conceptually similar to LXC but adds tooling, APIs, and image management, making containers easier to use for developers.

🧩 Linux Technologies that Power Docker

📦 LXC (Linux Containers)

LXC allows multiple isolated Linux systems to run on a single host:

Containers share the host’s kernel but operate in isolated user spaces.
They start quickly because they don’t boot an entire OS.
Useful for running applications, testing software, or deploying services in the cloud.
With tools to create, monitor, and manage containers, LXC provides the foundation for lightweight virtualization.

Docker initially used LXC and later built its own runtime (libcontainer) for more flexibility and control.

🛡 Namespaces: Process Isolation

Namespaces ensure containers don’t interfere with the host or each other by providing isolated views of system resources:

Namespace	Isolates
pid	Process IDs
net	Network interfaces and routing tables
mnt	Mount points and filesystems
uts	Hostname and domain name
ipc	Inter-process communication
user	User and group IDs

Example: Processes inside a container only see their own processes because of the pid namespace.

⚙️ Control Groups (cgroups): Resource Control

cgroups is a Linux kernel feature that allows:

Limiting CPU, memory, disk I/O, and network usage per container.
Tracking and monitoring resource consumption.
Preventing a single container from exhausting the host’s resources.

This makes multi-tenant environments predictable and stable.

🗂 Union File Systems (UnionFS): Efficient Storage

Docker images use Union File Systems (like OverlayFS, AUFS, or Btrfs) to implement layers.

Each instruction in a Dockerfile (like RUN, COPY) creates a new layer.
When running a container, Docker adds a thin, writable layer on top.
Changes inside the container only affect the writable layer.
Layers are shared across images, saving disk space and bandwidth.

Example: Multiple containers can share the same Ubuntu base image while having their own unique changes.

🌐 Docker Networking

Docker configures different network drivers to enable communication inside and outside containers:

Network Type	Use Case
bridge	Default for single-host; containers share a virtual bridge
host	Container shares host’s network stack (no isolation)
overlay	Multi-host networks for Docker Swarm / Kubernetes
macvlan	Assigns a MAC address to containers, appearing on LAN

When you run:

docker run -d -p 8080:80 nginx

Docker:

Connects the container to the bridge network.
Configures NAT to forward traffic from port 8080 on the host to port 80 inside the container.

🧪 Putting it All Together

Here’s what happens step by step when you run:

docker run -d -p 8080:80 nginx

✅ Docker:

Reads the image (built from UFS layers)
Creates a new container layer (writable)
Applies namespaces for isolation
Applies cgroups for resource limits
Sets up networking to connect to the host and the world

All this happens in seconds, which explains why containers start so quickly compared to virtual machines.

🛠 Extra: Exploring Docker Internals

Try these commands to peek inside:

# See cgroups hierarchy
ls /sys/fs/cgroup

# List running processes in a container
docker top <container_id>

# Inspect full container metadata
docker inspect <container_id>

# See filesystem changes in a container
docker diff <container_id>

✅ Conclusion

Docker isn’t magic — it stands on the shoulders of decades of Linux innovation:

Namespaces for process isolation
cgroups for resource management
UnionFS for layered, efficient storage
LXC as an inspiration for containerization
Networking drivers to connect containers seamlessly

By combining these with a developer-friendly API, Docker made containers practical, portable, and production-ready.

✨ From the kernel to the cloud, Docker brings it all together for modern apps!

📚 Further Reading

🧰 Next Up: Installing Docker on Ubuntu

In the next post, we’ll walk through how to install Docker on Ubuntu step by step — from setting up the repository to verifying your installation and running your first container.

Stay tuned!

Best Practices for React Applications

coder7475 — Thu, 10 Jul 2025 13:55:22 +0000

React, developed by Meta in 2013, is a powerful JavaScript library for building user interfaces, known for its component-based architecture and efficient rendering capabilities. Its flexibility allows developers to tailor application structures to specific project needs, but this freedom can lead to organizational challenges in large-scale applications. A well-defined architecture ensures code remains maintainable, scalable, and performant. This article explores best practices for architecting React applications, drawing from industry insights and practical examples to guide developers in creating robust and efficient applications.

Organizing the Directory Structure

A well-organized directory structure is critical for maintaining large React projects. One effective approach is to group files by feature, rather than by type (e.g., components, hooks, or styles). This feature-based structure colocates all related files, such as components, styles, tests, and custom hooks, within a single folder, improving modularity and ease of navigation.

For example, a to-do list application might have the following structure:

src/
  features/
    todo/
      TodoList.js
      TodoItem.js
      useTodo.js
      todo.css
      Todo.test.js
    user/
      UserProfile.js
      useUser.js
      user.css
      UserProfile.test.js
  App.js
  index.js
  index.css

This structure contrasts with type-based organization, where files are grouped by their role (e.g., all components in a components folder). Feature-based organization reduces complexity in large projects by keeping related files together, making it easier to manage and scale the codebase. To simplify imports, developers can use absolute imports by configuring a jsconfig.json file with a baseUrl set to src, allowing imports like import { TodoList } from 'features/todo/TodoList'.

Component Design Patterns

Effective component design enhances reusability and testability by separating concerns. The Container-Presentational pattern is a widely adopted approach, where presentational components focus on rendering the UI, and container components handle logic, state, and data fetching. This separation adheres to the single responsibility principle, making components easier to test and reuse.

For example:

// Presentational Component: TodoList.js
function TodoList({ todos, onToggle }) {
  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id} onClick={() => onToggle(todo.id)}>
          {todo.text}
        </li>
      ))}
    </ul>
  );
}

// Container Component: TodoContainer.js
import { useState } from 'react';
function TodoContainer() {
  const [todos, setTodos] = useState([]);
  const toggleTodo = (id) => {
    setTodos(todos.map(todo =>
      todo.id === id ? { ...todo, completed: !todo.completed } : todo
    ));
  };
  return <TodoList todos={todos} onToggle={toggleTodo} />;
}

Other patterns, such as Higher-Order Components (HOCs) and Render Props, can also be used to share logic across components. For instance, a withAuth HOC can wrap components to enforce authentication, while a Fetch component using render props can handle API data fetching. Additionally, custom hooks, introduced with React 16.8, provide a modern way to encapsulate reusable logic, such as a useFetch hook for data fetching:

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchData() {
      const response = await fetch(url);
      const json = await response.json();
      setData(json);
      setLoading(false);
    }
    fetchData();
  }, [url]);

  return { data, loading };
}

State Management Strategies

State management in React depends on the application’s complexity. For small applications, local state managed with useState or useReducer hooks is often sufficient. For example, a form component might use useState to track input values. For sharing state across multiple components without prop drilling, the Context API is a lightweight solution. For instance, a ThemeContext can provide theming data to components:

import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext();

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');
  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

function ThemedComponent() {
  const { theme } = useContext(ThemeContext);
  return <div className={theme}>Themed Content</div>;
}

For large-scale applications with complex state interactions, libraries like Redux or MobX provide centralized state management. Redux, for example, uses a single store and reducers to manage state predictably. However, to avoid overcomplicating smaller projects, developers should assess whether simpler solutions like Context suffice before adopting external libraries.

Styling Approaches

Styling in React has evolved from global CSS to more component-centric approaches. CSS-in-JS libraries, such as Styled Components or Emotion, allow developers to write CSS within JavaScript, scoping styles to components and enabling dynamic theming. For example:

import styled from 'styled-components';

const Button = styled.button`
  background: ${props => props.primary ? 'blue' : 'white'};
  color: ${props => props.primary ? 'white' : 'blue'};
  padding: 8px 16px;
  border: 1px solid blue;
`;

function App() {
  return <Button primary>Click Me</Button>;
}

CSS Modules offer another approach, providing scoped styles without JavaScript overhead. The choice between CSS-in-JS and CSS Modules depends on project requirements, with CSS-in-JS being preferred for its integration with React’s component model and support for dynamic styling.

Performance Optimization

Performance is critical in large React applications. Code splitting, enabled by React.lazy and Suspense, reduces initial bundle sizes by loading components only when needed:

import { lazy, Suspense } from 'react';

const HeavyComponent = lazy(() => import('./HeavyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <HeavyComponent />
    </Suspense>
  );
}

Memoization techniques, such as React.memo for components and useMemo or useCallback for values and functions, prevent unnecessary re-renders. For example:

const MemoizedComponent = React.memo(({ data }) => {
  return <div>{data}</div>;
});

Developers should measure performance bottlenecks using tools like React DevTools before applying optimizations to avoid premature optimization.

Testing

Testing ensures code reliability and maintainability. Jest, Vitest and React Testing Library are standard tools for unit and integration testing. Unit tests verify individual components, while integration tests ensure features work together. For example, testing a TodoList component might involve:

import { render, screen } from '@testing-library/react';
import TodoList from './TodoList';

test('renders todo items', () => {
  const todos = [{ id: 1, text: 'Buy groceries', completed: false }];
  render(<TodoList todos={todos} onToggle={() => {}} />);
  expect(screen.getByText('Buy groceries')).toBeInTheDocument();
});

End-to-end tests with tools like Cypress can simulate user interactions across the entire application, ensuring critical paths function as expected.

Data Fetching

Data fetching is a common requirement in React applications. Custom hooks like useFetch encapsulate fetching logic, making it reusable across components. For example:

import { useState, useEffect } from 'react';

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchData() {
      const response = await fetch(url);
      const json = await response.json();
      setData(json);
      setLoading(false);
    }
    fetchData();
  }, [url]);

  return { data, loading };
}

function DataComponent() {
  const { data, loading } = useFetch('https://api.example.com/data');
  if (loading) return <div>Loading...</div>;
  return <div>{JSON.stringify(data)}</div>;
}

For advanced use cases, libraries like React Query or SWR provide caching, refetching, and optimistic updates, simplifying data management in complex applications.

Conclusion

Architecting a React application requires careful consideration of directory structure, component design, state management, styling, performance, testing, and data fetching. By adopting feature-based organization, separating concerns with patterns like Container-Presentational, choosing appropriate state management tools, using modern styling approaches, optimizing performance, and integrating testing, developers can build scalable and maintainable applications. The flexibility of React allows for tailored architectures, but adhering to these best practices ensures long-term success. Developers should evaluate project requirements and team preferences to select the most suitable approaches, starting simple and scaling complexity as needed.