DEV Community: Otieno Keith

Getting Started with API Automation: Simple Integration with Code

Otieno Keith — Tue, 19 Aug 2025 18:24:16 +0000

Intro – APIs + automation use cases

APIs make it easy for software to talk to software. With a few HTTP calls, you can move data between tools, trigger workflows, and generate reports without manual steps. Common automation use cases:

Lead capture → CRM: Send a form submission into HubSpot or Salesforce.
E‑commerce → accounting: Post new orders to your bookkeeping system.
App events → Slack/Email: Notify teams instantly when important events occur.
User actions → spreadsheets: Log signups or errors into Google Sheets for quick analytics.

You’ll build a small, practical pipeline: when a new user signs up, a Python script sends their data to Google Sheets via a webhook URL. Then you’ll optionally enrich those users with a second API and handle authentication securely.

Example Scenario: Send new user data to Google Sheets

Goal: Every time a new user signs up, append a row to a Google Sheet with fields like timestamp, email, plan, and source.

Approach:

Use a webhook endpoint provided by an automation tool (e.g., Zapier “Catch Hook” or Make/Integromat “Custom Webhook”).
Map the incoming JSON fields to columns in a “Signups” sheet.
POST JSON from Python to the webhook URL; the automation tool handles writing to Google Sheets.

Why a webhook instead of calling the Google Sheets API directly?

Faster to set up: no OAuth dance, scopes, or service accounts.
Easier to maintain: you can tweak the sheet mapping inside the automation UI.
Extensible: add more steps (Slack notice, CRM insert) without touching code.

Code Example: Python script using requests to POST data to a sheet via a webhook

Minimal snippet (the essence):

import requests
data = { "email": "jane@example.com", "plan": "pro" }
requests.post("https://hooks.zapier.com/... ", json=data)

Full example with structure, validation, retry, and idempotency:

import os
import time
import uuid
import requests
from datetime import datetime
from typing import Dict, Any, Optional

WEBHOOK_URL = os.getenv("SHEETS_WEBHOOK_URL")  # e.g., the Zapier/Make webhook
DEFAULT_TIMEOUT_SEC = 5
MAX_RETRIES = 3
INITIAL_BACKOFF_SEC = 0.5

def generate_idempotency_key() -> str:
    return str(uuid.uuid4())

def post_with_retry(url: str, payload: Dict[str, Any], headers: Optional[Dict[str, str]] = None) -> requests.Response:
    attempt = 0
    backoff = INITIAL_BACKOFF_SEC
    last_exc = None

    while attempt < MAX_RETRIES:
        try:
            resp = requests.post(url, json=payload, headers=headers, timeout=DEFAULT_TIMEOUT_SEC)
            # Retry on transient server/network issues or rate limiting
            if resp.status_code in (429, 500, 502, 503, 504):
                time.sleep(backoff)
                backoff *= 2
                attempt += 1
                continue
            return resp
        except requests.RequestException as exc:
            last_exc = exc
            time.sleep(backoff)
            backoff *= 2
            attempt += 1

    if last_exc:
        raise last_exc
    raise RuntimeError("Exhausted retries posting to webhook")

def build_signup_payload(user: Dict[str, Any]) -> Dict[str, Any]:
    # Map your app’s fields to sheet columns
    return {
        "timestamp": datetime.utcnow().isoformat(),
        "email": user.get("email"),
        "name": user.get("name"),
        "plan": user.get("plan", "free"),
        "source": user.get("source", "website"),
        "utm_campaign": user.get("utm_campaign"),
        "metadata": user.get("metadata", {}),
    }

def send_signup_to_sheet(user: Dict[str, Any]) -> None:
    if not WEBHOOK_URL:
        raise EnvironmentError("SHEETS_WEBHOOK_URL not set")
    payload = build_signup_payload(user)
    headers = {
        "Content-Type": "application/json",
        # If your automation tool supports idempotency, pass a stable key to avoid duplicates
        "Idempotency-Key": generate_idempotency_key(),
        "User-Agent": "signup-automation/1.0"
    }
    resp = post_with_retry(WEBHOOK_URL, payload, headers=headers)
    if resp.status_code >= 400:
        raise RuntimeError(f"Webhook failed: {resp.status_code} {resp.text}")

if __name__ == "__main__":
    new_user = {
        "email": "jane@example.com",
        "name": "Jane Doe",
        "plan": "pro",
        "source": "landing-page",
        "utm_campaign": "spring-promo",
        "metadata": {"referrer": "twitter"}
    }
    send_signup_to_sheet(new_user)
    print("Signup posted to Google Sheets webhook.")

How to wire the Google Sheets step:

In your automation tool, create a trigger step that receives a POST at a unique URL.
Add an action: “Create Spreadsheet Row” in Google Sheets.
Map JSON fields like email, plan, timestamp to columns.
Copy the webhook URL into SHEETS_WEBHOOK_URL.

Explanation of JSON, headers, HTTP methods

JSON: A text format for structured data.
- Objects: { "email": "jane@example.com" }
- Arrays: { "tags": ["beta", "newsletter"] }
- Nested: { "user": { "email": "jane@example.com" } }
Headers: Metadata sent with requests.
- Content-Type: application/json tells the server how to parse the body.
- Authorization: Bearer <token> conveys credentials.
- Idempotency-Key: <uuid> lets servers deduplicate repeated requests.
- User-Agent: <string> identifies your client.
HTTP methods:
- GET: retrieve data; should not change state.
- POST: create/trigger actions; used for webhooks and inserts.
- PUT/PATCH: update resources (full vs partial).
- DELETE: remove resources.
Status codes:
- 2xx success, 4xx client errors (bad input or auth), 5xx server errors (retry later).
- 429 means rate limited; back off and retry.

Using a second API (optional chaining) and merging data

Let’s enrich the signup with a lightweight, no-auth API to estimate age from a first name using agify.io, then merge it into the payload before posting to the sheet.

import requests

def enrich_with_agify(user: Dict[str, Any]) -> Dict[str, Any]:
    enriched = dict(user)
    name = user.get("name")
    if not name:
        return enriched

    first_name = name.split()[0]
    try:
        resp = requests.get(
            "https://api.agify.io",
            params={"name": first_name},
            timeout=3
        )
        if resp.ok:
            guess = resp.json().get("age")
            enriched["age_guess"] = guess
    except requests.RequestException:
        # Non-fatal; keep original user data
        pass
    return enriched

def send_signup_to_sheet(user: Dict[str, Any]) -> None:
    if not WEBHOOK_URL:
        raise EnvironmentError("SHEETS_WEBHOOK_URL not set")

    # Optional chaining step:
    user = enrich_with_agify(user)

    payload = build_signup_payload(user)
    headers = {
        "Content-Type": "application/json",
        "Idempotency-Key": generate_idempotency_key(),
        "User-Agent": "signup-automation/1.0"
    }
    resp = post_with_retry(WEBHOOK_URL, payload, headers=headers)
    if resp.status_code >= 400:
        raise RuntimeError(f"Webhook failed: {resp.status_code} {resp.text}")

Notes:

Keep enrichment best-effort. If it fails or times out, proceed without it.
Respect rate limits: add caching if you enrich lots of records with the same input.
If the second API requires auth, add headers per the next section.

Handling Authentication

Most production APIs require credentials. Common patterns:

API key in header: Authorization: Bearer <token> or X-API-Key: <key>.
OAuth2: Acquire an access token, then include it as a Bearer token.
Signed requests: HMAC signatures using a shared secret.

Best practices:

Store secrets in environment variables, not in code or git.
Rotate keys regularly and scope them with least privilege.
Use HTTPS only; never send tokens over plain HTTP.
Handle 401/403 specifically (refresh token or alert).

API key in header code snippet

import os
import requests

API_URL = "https://api.example.com/v1/data"
API_KEY = os.getenv("EXAMPLE_API_KEY")

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

payload = { "record_id": "123", "status": "active" }

resp = requests.post(API_URL, json=payload, headers=headers, timeout=5)
if resp.status_code == 401:
    raise RuntimeError("Unauthorized: check EXAMPLE_API_KEY")
resp.raise_for_status()
print(resp.json())

Alternate header style used by some providers:

headers = {
    "X-API-Key": API_KEY,
    "Content-Type": "application/json"
}

Testing the webhook end-to-end

Local smoke test for your webhook URL:

import requests
data = {
    "email": "jane@testco.com",
    "name": "Jane Doe",
    "plan": "pro",
    "source": "referral"
}
resp = requests.post(os.getenv("SHEETS_WEBHOOK_URL"), json=data, timeout=5)
print(resp.status_code, resp.text)

If your webhook is private to your VPC, expose a controlled test endpoint or run the test in the same environment. In your automation tool’s UI, you can usually inspect recent deliveries, payloads, and errors.

Reliability: retries, idempotency, and validation

Retries: Implement exponential backoff on 429/5xx. Cap retries to avoid storms.
Idempotency: Generate a stable key for a given logical event (e.g., signup UUID). Many platforms deduplicate by Idempotency-Key.
Validation: Check emails are non-empty and sanity‑validate fields. Reject or log malformed events.
Observability: Log request IDs, keep a dead‑letter queue for failures, and add alerts on repeated failures.

Security basics for outbound calls

Never log raw secrets. Scrub headers before logging.
Use timeout on all HTTP calls to avoid hanging processes.
If chaining multiple APIs, be mindful of PII. Only send what’s necessary.
Respect rate limits and provider policies. If bulk jobs are needed, throttle or batch.

Summary of what automation accomplished

Automated data capture: Posted new signups directly to Google Sheets via a webhook no manual copy/paste.
Composable workflow: Inserted an optional enrichment step (second API) before writing to the sheet.
Production-friendly code: Added retries, timeouts, and idempotency to handle real-world failures.
Secure patterns: Demonstrated API key handling via headers and environment variables.

Outcome: You now have a template for API-powered automation collect data, optionally enrich it, and fan it out to destinations like spreadsheets, CRMs, or messaging tools with minimal code and strong reliability practices.

Using Webhooks for Instant Automation Workflows (with Code Example)

Otieno Keith — Tue, 19 Aug 2025 18:16:52 +0000

Intro – webhook vs API polling

APIs let you fetch data on demand; polling is when your system repeatedly asks, “Anything new yet?” at a schedule. Polling is simple but inefficient: you waste requests when there’s nothing to fetch, and you discover changes only after your next poll. Webhooks invert the flow. Instead of you polling, external systems call your endpoint immediately when something happens e.g., Stripe charges succeeded, GitHub push events, or a CRM contact update. The result is:

Faster reactions (near real-time).
Lower infrastructure and API costs (no wasteful polling).
More scalable automation (events drive workflows).

A good webhook receiver must be reliable, secure, and fast: accept the request, verify authenticity, enqueue work, and return 2xx quickly.

Explanation diagram in words

Think of a five-step pipeline:

1) External service (Stripe/GitHub) detects an event (charge succeeded, push committed).

2) The service sends an HTTPS POST to your public URL /webhook with a JSON payload and security headers.

3) Your reverse proxy/load balancer forwards the request to your app.

4) Your Flask route receives raw bytes, verifies the signature, parses the JSON, and enqueues a job (e.g., Celery/queue) for downstream processing.

5) Your worker updates databases, triggers emails/Slack, or fans out to other services. The HTTP handler returns 200 quickly to avoid retries.

Code Example: How to build a webhook receiver using Python Flask

Start from a minimal Flask receiver and then harden it.

Install dependencies:

pip install flask requests

Minimal example (works for local testing):

from flask import Flask, request
app = Flask(__name__)

@app.route('/webhook', methods=['POST'])
def receive():
    data = request.json
    print(data)
    return '', 200

if __name__ == '__main__':
    app.run(port=5000)

Production-ready version with structured logging, raw-body access, and quick returns:

import json
import logging
import os
from datetime import datetime
from flask import Flask, request, abort

app = Flask(__name__)
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("webhook")

@app.route('/health', methods=['GET'])
def health():
    return {'status': 'ok', 'time': datetime.utcnow().isoformat()}, 200

@app.route('/webhook', methods=['POST'])
def webhook():
    # Always read raw bytes first; some signature checks require exact bytes
    raw_body = request.get_data(cache=False, as_text=False)
    headers = {k.lower(): v for k, v in request.headers.items()}

    # Parse JSON safely
    try:
        payload = json.loads(raw_body.decode('utf-8') or '{}')
    except json.JSONDecodeError:
        logger.warning("Invalid JSON payload")
        abort(400, description="Invalid JSON")

    # Optionally route by provider (via path, header, or secret separation)
    provider = headers.get('user-agent', 'unknown')

    # TODO: Verify signature here (see dedicated Security section below)
    # verify_provider_signature_or_abort(raw_body, headers)

    # At this point, return 2xx quickly to prevent retries
    logger.info("Accepted webhook from %s: %s", provider, payload.get('type') or 'unknown')
    # Enqueue or trigger async processing (mocked here)
    process_event_async(payload)

    return '', 200

def process_event_async(payload):
    # Replace with Celery/RQ/ThreadPool this is just a placeholder
    logger.info("Queued processing for event: %s", payload.get('type'))

if __name__ == '__main__':
    # Use host='0.0.0.0' in containers; add SSL termination upstream
    app.run(port=int(os.getenv('PORT', '5000')))

Notes:

Read request.get_data() for exact bytes needed in signature verification.
Return fast; do heavy work asynchronously.
Separate endpoints per provider or verify per-request which provider sent the event.

Test sending a request using Python requests.post(...)

You can simulate a webhook locally to validate your route.

import requests

url = "http://localhost:5000/webhook"
payload = {
    "type": "test.event",
    "data": {"message": "Hello, webhook!"}
}
headers = {
    "Content-Type": "application/json",
    # Simulate provider headers if needed
    "User-Agent": "local-tester/1.0"
}

resp = requests.post(url, json=payload, headers=headers, timeout=5)
print(resp.status_code, resp.text)

Tip: Use ngrok or cloudflared to expose your local server to the public internet for real provider callbacks.

Install and run:

pip install pyngrok
ngrok http 5000

You’ll get a URL like https://abcd1234.ngrok.io. Configure providers to target https://abcd1234.ngrok.io/webhook.

Connect to Stripe or GitHub webhooks

Stripe

In the Stripe Dashboard, create an endpoint pointing to your URL /webhook.
Choose events (e.g., payment_intent.succeeded, customer.subscription.updated).
Copy the “Signing secret” for that endpoint.
For local dev, the Stripe CLI can forward events:

# Install: https://stripe.com/docs/stripe-cli
stripe listen --forward-to localhost:5000/webhook

Handle events in code (after signature verification):

def handle_stripe_event(event):
    event_type = event.get('type')
    obj = event.get('data', {}).get('object', {})

    if event_type == 'payment_intent.succeeded':
        payment_intent_id = obj.get('id')
        amount = obj.get('amount_received')
        # update DB, send emails, etc.
    elif event_type == 'charge.refunded':
        pass
    else:
        pass

GitHub

In your repo’s Settings → Webhooks → Add webhook:
- Payload URL: https://yourdomain.com/webhook
- Content type: application/json
- Secret: set a strong secret and store it as GITHUB_WEBHOOK_SECRET.
- Select events (e.g., push, pull_request).
GitHub retries on non-2xx; ensure you return quickly.

Handle GitHub events in code:

def handle_github_event(event, headers):
    event_name = headers.get('x-github-event', 'unknown')
    delivery_id = headers.get('x-github-delivery', 'unknown')

    if event_name == 'push':
        commits = event.get('commits', [])
        # react to new commits
    elif event_name == 'pull_request':
        action = event.get('action')
        # react to PR opened/synchronize/closed
    else:
        pass

You can route in /webhook by checking headers like Stripe-Signature or X-GitHub-Event.

Security: checking signature in code

Stripe signature verification (recommended: official SDK)

Install:

pip install stripe

Code:

import os
import stripe
from flask import abort, request

stripe.api_key = os.getenv('STRIPE_API_KEY')  # for API calls if needed
STRIPE_SIGNING_SECRET = os.getenv('STRIPE_WEBHOOK_SECRET')  # endpoint secret

@app.route('/webhook/stripe', methods=['POST'])
def stripe_webhook():
    payload = request.get_data(cache=False, as_text=False)
    sig_header = request.headers.get('Stripe-Signature', '')

    try:
        event = stripe.Webhook.construct_event(
            payload=payload, sig_header=sig_header, secret=STRIPE_SIGNING_SECRET
        )
    except stripe.error.SignatureVerificationError:
        abort(400, description="Invalid Stripe signature")
    except ValueError:
        abort(400, description="Invalid Stripe payload")

    # Process event securely
    handle_stripe_event(event)
    return '', 200

Why this works:

Stripe signs each payload with your endpoint secret.
The library validates HMAC and timestamp tolerance to prevent replay attacks.

GitHub signature verification (HMAC SHA-256)

GitHub sends X-Hub-Signature-256: sha256=<hex>.

import os
import hmac
import hashlib
from flask import abort, request

GITHUB_WEBHOOK_SECRET = os.getenv('GITHUB_WEBHOOK_SECRET', '')

def verify_github_signature_or_abort(raw_body: bytes, headers: dict):
    signature_header = headers.get('X-Hub-Signature-256') or headers.get('x-hub-signature-256')
    if not signature_header or not signature_header.startswith('sha256='):
        abort(400, description="Missing GitHub signature")

    expected = hmac.new(
        key=GITHUB_WEBHOOK_SECRET.encode('utf-8'),
        msg=raw_body,
        digestmod=hashlib.sha256
    ).hexdigest()

    provided = signature_header.split('=', 1)[1].strip()
    if not hmac.compare_digest(expected, provided):
        abort(400, description="Invalid GitHub signature")

@app.route('/webhook/github', methods=['POST'])
def github_webhook():
    raw_body = request.get_data(cache=False, as_text=False)
    verify_github_signature_or_abort(raw_body, request.headers)
    event = request.get_json(silent=True) or {}
    handle_github_event(event, request.headers)
    return '', 200

Additional hardening:

Rate-limit by IP or provider ASN if feasible.
Enforce HTTPS only; terminate TLS before Flask or use a proper reverse proxy.
Validate content types and required headers.
Idempotency: store processed id (Stripe event.id, GitHub X-GitHub-Delivery) to prevent duplicate handling.
Respond with 2xx only after enqueuing work; if verification fails, return 4xx immediately.

Putting it together: a single route that detects provider

You can keep separate endpoints (cleanest) or branch on headers:

@app.route('/webhook', methods=['POST'])
def unified_webhook():
    raw_body = request.get_data(cache=False, as_text=False)
    headers = request.headers

    if 'Stripe-Signature' in headers:
        # Verify and handle Stripe
        try:
            event = stripe.Webhook.construct_event(
                payload=raw_body,
                sig_header=headers['Stripe-Signature'],
                secret=STRIPE_SIGNING_SECRET
            )
        except Exception:
            abort(400)
        handle_stripe_event(event)
    elif 'X-GitHub-Event' in headers or 'x-github-event' in {k.lower(): v for k, v in headers.items()}:
        verify_github_signature_or_abort(raw_body, headers)
        event = request.get_json(silent=True) or {}
        handle_github_event(event, headers)
    else:
        abort(400, description="Unknown provider")

    return '', 200

Running locally and end-to-end check

1) Start Flask:

python app.py

2) Expose publicly:

ngrok http 5000

3) Configure a test provider:

Stripe: stripe listen --forward-to localhost:5000/webhook/stripe and trigger events from the Dashboard or CLI.
GitHub: Add a webhook to your test repo pointing to the ngrok URL /webhook/github, choose push, set your secret.

4) Watch logs; confirm 200s and downstream processing.

Conclusion

Webhooks turn external events into instant triggers for your automation: faster than polling, cheaper, and more scalable. A reliable receiver does four things well:

Accepts and returns 2xx quickly.
Verifies authenticity with provider signatures.
Routes and enqueues work for asynchronous processing.
Implements idempotency and observability so you can replay or debug safely.

Use the minimal Flask receiver to get started, then adopt signature verification for Stripe and GitHub, separate endpoints where helpful, and queue heavy tasks. With a simple public tunnel for local testing and production-grade security (HTTPS, secrets, idempotency, and rate limiting), you’ll have a robust webhook backbone for everything from payments to CI to CRM automation.

Keep the handler tiny and fast; push work to workers.
Verify signatures using provider-recommended methods.
Store and deduplicate event IDs.
Prefer separate routes per provider for clarity.

Summary:

Built a Flask webhook receiver with both minimal and hardened versions.
Showed local testing via requests.post(...) and tunneling with ngrok.
Integrated with Stripe and GitHub and verified signatures securely.
Outlined best practices: fast returns, async processing, idempotency, HTTPS, and observability.

Automated Testing for Web Apps with Cypress

Otieno Keith — Tue, 19 Aug 2025 18:09:52 +0000

Why automated tests matter

Automated end-to-end (E2E) tests give you confidence that core user flows like login, signup, checkout, and profile updates work every time. They:

Catch regressions early: Breakages are detected before production.
Speed up releases: CI runs tests on every pull request.
Document expected behavior: Tests double as living documentation.
Reduce manual QA: Engineers focus on higher-value work.

Cypress is a developer-friendly E2E framework that runs in the browser, offers great debuggability, and has first-class tooling for network control, retries, and time-travel debugging. Below, you’ll find a full login test you can drop into a project, plus a parallel Playwright example for comparison.

Install Cypress

npm install --save-dev cypress

Optional but recommended scripts in package.json:

{
  "scripts": {
    "cypress:open": "cypress open",
    "cypress:run": "cypress run",
    "start": "your-app-start-command"
  }
}

Project setup (minimal)

Create a cypress.config.js to set a baseUrl and surface credentials via env. This helps keep tests clean and avoids hardcoding secrets.

// cypress.config.js
const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000', // change to your dev URL
    supportFile: 'cypress/support/e2e.js'
  },
  env: {
    USER_EMAIL: process.env.CYPRESS_USER_EMAIL,
    USER_PASSWORD: process.env.CYPRESS_USER_PASSWORD
  },
  video: true,
  screenshotOnRunFailure: true,
});

You can set environment variables in your shell before running tests:

PowerShell:

$env:CYPRESS_USER_EMAIL="tester@example.com"
$env:CYPRESS_USER_PASSWORD="supersecret"

Bash:

export CYPRESS_USER_EMAIL="tester@example.com"
export CYPRESS_USER_PASSWORD="supersecret"

Create a small support command to log in programmatically if you want to reuse the flow across specs:

// cypress/support/commands.js
Cypress.Commands.add('uiLogin', (email, password) => {
  cy.visit('/login');

  cy.get('input[name="email"]').should('be.visible').clear().type(email, { delay: 10 });
  cy.get('input[name="password"]').clear().type(password, { log: false, delay: 10 });

  cy.intercept('POST', '/api/auth/login').as('loginRequest');
  cy.get('button[type="submit"]').click();
  cy.wait('@loginRequest').its('response.statusCode').should('be.oneOf', [200, 201]);

  cy.location('pathname', { timeout: 10000 }).should('include', '/dashboard');
});

And import it in cypress/support/e2e.js:

// cypress/support/e2e.js
import './commands';

Code Example: full login test (Cypress)

Create cypress/e2e/login.cy.js:

// cypress/e2e/login.cy.js
describe('Login Test', () => {
  beforeEach(() => {
    // Optionally cache sessions to speed up subsequent tests
    // Requires Cypress v12+; remove if not needed
    cy.session('logged-in-user', () => {
      cy.visit('/login');
      cy.get('input[name="email"]').should('be.visible').type(Cypress.env('USER_EMAIL'), { delay: 10 });
      cy.get('input[name="password"]').type(Cypress.env('USER_PASSWORD'), { log: false, delay: 10 });

      cy.intercept('POST', '/api/auth/login').as('loginRequest');
      cy.get('button[type="submit"]').click();

      cy.wait('@loginRequest').then((interception) => {
        expect([200, 201]).to.include(interception.response.statusCode);
      });

      // Wait for the app to finish client-side routing
      cy.location('pathname', { timeout: 10000 }).should('include', '/dashboard');
      // Optional tiny wait for content hydration; prefer network waits when possible
      cy.wait(300); // avoid growing this; see best practices
    });
  });

  it('should login successfully and show user dashboard', () => {
    // With cy.session, this visit lands on the dashboard without repeating form input
    cy.visit('/dashboard');

    // Confirm a logged-in-only element renders
    cy.get('[data-testid="welcome-banner"]').should('contain.text', 'Welcome');

    // Verify a downstream API loads (example: profile)
    cy.intercept('GET', '/api/profile').as('profile');
    cy.reload();
    cy.wait('@profile').its('response.statusCode').should('eq', 200);

    // Basic assertions on the page content
    cy.get('[data-testid="user-email"]').should('have.text', Cypress.env('USER_EMAIL'));
  });

  it('should show an error on invalid credentials', () => {
    cy.visit('/login');

    cy.get('input[name="email"]').type('wrong@example.com', { delay: 10 });
    cy.get('input[name="password"]').type('badpassword', { log: false, delay: 10 });

    cy.intercept('POST', '/api/auth/login').as('loginRequest');
    cy.get('button[type="submit"]').click();

    cy.wait('@loginRequest').its('response.statusCode').should('be.oneOf', [400, 401, 403]);
    cy.get('[data-testid="login-error"]').should('be.visible').and('contain.text', 'Invalid');
  });
});

Notes:

Selectors like input[name="email"] and [data-testid="welcome-banner"] should match your app’s DOM. Prefer stable data-testid attributes over brittle text or class selectors.
The small { delay: 10 } typing delay is purely to emulate human input and can help flaky UI debounce logic; keep it small.
Use cy.wait('@alias') over arbitrary cy.wait(1000) wherever possible.

Headless run via command line

Run your dev server, then run Cypress in headless mode:

# In one terminal
npm start

# In another terminal
npx cypress run --browser chrome --headless

Target a single spec:

npx cypress run --spec "cypress/e2e/login.cy.js" --headless

Record and parallelize (with Cypress Cloud, optional):

npx cypress run --record --key <your-project-key> --parallel

Run tests in CI (YAML)

Here’s a minimal GitHub Actions workflow that installs dependencies, starts the app, waits for it to be ready, and runs Cypress headlessly.

# .github/workflows/e2e.yml
name: E2E Tests

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  cypress-run:
    runs-on: ubuntu-latest
    env:
      CYPRESS_USER_EMAIL: ${{ secrets.CYPRESS_USER_EMAIL }}
      CYPRESS_USER_PASSWORD: ${{ secrets.CYPRESS_USER_PASSWORD }}
      # Set your app's port/URL if different
      APP_URL: http://localhost:3000
    steps:
      - name: Checkout
        uses: actions/checkout@v4

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

      - name: Install dependencies
        run: npm ci

      - name: Build app
        run: npm run build --if-present

      - name: Start app
        run: npm start &

      - name: Wait for app
        run: npx wait-on $APP_URL --timeout 60000

      - name: Run Cypress
        run: npx cypress run --browser chrome --headless

If your app needs a database or services, add them as services or spin them up via Docker Compose. Never commit credentials; use CI secrets.

Parallel example: same test in Playwright (optional comparison)

Install Playwright:

npm i -D @playwright/test
npx playwright install --with-deps

Create tests/login.spec.ts:

// tests/login.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Login Test', () => {
  test('should login successfully', async ({ page }) => {
    const email = process.env.PLAYWRIGHT_USER_EMAIL || 'tester@example.com';
    const password = process.env.PLAYWRIGHT_USER_PASSWORD || 'supersecret';

    await page.goto('http://localhost:3000/login');

    // Optional small delay to mimic human typing; keep it small
    await page.locator('input[name="email"]').fill(email, { timeout: 10000 });
    await page.locator('input[name="password"]').fill(password);

    const [response] = await Promise.all([
      page.waitForResponse((res) => res.url().endsWith('/api/auth/login') && res.status() < 400),
      page.locator('button[type="submit"]').click(),
    ]);

    expect(response.ok()).toBeTruthy();

    await expect(page).toHaveURL(/\/dashboard/);
    await expect(page.getByTestId('welcome-banner')).toContainText('Welcome');
  });
});

Run headless:

npx playwright test --project=chromium --reporter=line

Both tools are excellent. Cypress offers time-travel UI, automatic retrying of commands, and is very popular for front-end teams. Playwright is powerful for multi-browser/device coverage and broader automation APIs. Use whichever fits your stack and team preferences.

Best practices in test code

Use stable selectors: Prefer data-testid attributes over text, CSS classes, or ARIA labels that frequently change.
Avoid fixed sleeps: Prefer cy.intercept + cy.wait('@alias') and assert on network responses or DOM readiness. Use small, bounded waits only when strictly necessary.
Control the network: Intercept external calls; stub responses for deterministic tests. Let one or two “happy-path” tests hit real backends in a staging environment if you truly need it.
Keep tests atomic: Each test should set up its own state. Use cy.session or API calls to seed data quickly.
Scope to critical paths: Cover login, key CRUD flows, and payments first. Push edge-case permutations into unit/integration layers where faster.
Make failures actionable: Assert specific, user-visible outcomes. Keep logs, screenshots, and videos on failure.
Separate config/secrets: Use env vars and CI secrets (never hardcode credentials or API keys in the repo).
Run locally and in CI: Keep parity. If it passes locally but not in CI, ensure resource timing and baseUrl are consistent and use wait-on for server readiness.
Keep execution fast: Parallelize in CI, cache dependencies, and reuse sessions to cut run time.
Accessibility checks (nice-to-have): Incorporate quick a11y smoke checks to prevent regressions.

Avoid spam, add delays carefully, handle API limits

Avoid spamming real services: When your app calls third-party APIs (payments, auth, messaging), mock them in tests using cy.intercept. Only a minimal set of tests should call real services in an isolated staging environment.
Use bounded delays sparingly: Prefer event-driven waits. If a delay is unavoidable (e.g., animation or debounce), keep it small (≤300ms) and document why. Example:

// Use network waits first; resort to a small, bounded delay only if needed
cy.wait('@loginRequest');
cy.location('pathname').should('include', '/dashboard');
cy.wait(200); // bounded; do not grow this

Handle rate limits: If a test must call a rate-limited API, centralize calls (e.g., seed via backend API once per run), throttle tests, and retry on 429s with exponential backoff in your app code (not the test). In tests, assert the app’s backoff behavior instead of looping aggressive retries.

Drawbacks and cautions

Flakiness risk: E2E tests touch the full stack; network and timing can introduce flakes. Mitigate with deterministic data, network stubbing, and event-based waits.
Slower than unit tests: Keep E2E coverage focused on business-critical journeys; push logic to faster layers where possible.
Environment drift: CI and local can diverge. Lock Node versions, use wait-on, and ensure the same build flags.
Data management: Seed test data and clean up; use disposable accounts or a resettable test DB.
Security and keys: Never commit secrets. Use separate test credentials and scopes; rotate keys regularly.
Policy violations and blocking: Respect Terms of Service for any third-party API. Excessive test traffic can cause temporary blocking or permanent bans for abuse. Use stubs/mocks by default and isolate real calls in a controlled staging environment with quotas.

Conclusion

Automated E2E tests with Cypress give you high confidence that user-critical journeys keep working through rapid change. With a clean config, stable selectors, disciplined network control, and CI integration, you’ll ship faster with fewer regressions. Use minimal, carefully placed delays and prefer event-driven waits to avoid flakiness. When you must interact with external APIs, respect rate limits and policies, store credentials as secrets, and isolate any real traffic to staging. If you prefer a different runtime model or broader automation APIs, the Playwright example shows how similar the test can be choose the tool that best fits your team’s workflow.

Headless: npx cypress run --browser chrome --headless
CI: Use the provided GitHub Actions YAML with secrets and wait-on
Full login test: See cypress/e2e/login.cy.js above
Optional comparison: See tests/login.spec.ts for Playwright

PostgreSQL vs MongoDB in the Age of AI Apps

Otieno Keith — Sun, 20 Jul 2025 19:37:00 +0000

1. Introduction

AI applications in 2025 demand robust, scalable, and efficient databases to power everything from chatbots to recommendation engines. The explosion of generative AI, vector search, and real-time analytics has pushed database technology to evolve rapidly. Two of the most popular choices for modern AI pipelines and backends are PostgreSQL and MongoDB. Each brings unique strengths to the table, and both are widely adopted in production AI systems.

At the core, this is a comparison of SQL versus NoSQL, structured versus unstructured data, and how each database has adapted to support AI and machine learning workloads. PostgreSQL is a mature, relational database with strong consistency and advanced extensions. MongoDB is a flexible, document-oriented database built for scale and rapid iteration. This article breaks down their strengths, weaknesses, and when to use each for AI-powered applications in 2025.

2. PostgreSQL Overview

PostgreSQL is a powerful, open-source relational database that has been in active development for decades. It is known for its reliability, strong support for schemas, ACID-compliant transactions, and advanced query capabilities. PostgreSQL excels at handling structured, relational, and transactional data, making it a top choice for applications that require data integrity and complex analytics.

Recent years have seen PostgreSQL evolve with extensions like PostGIS for geospatial data and pgvector for AI workloads. These extensions allow PostgreSQL to store and search high-dimensional vectors, making it suitable for AI tasks such as semantic search, recommendation, and retrieval-augmented generation (RAG).

Example: Table for storing user embeddings with pgvector

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE user_embeddings (
  id SERIAL PRIMARY KEY,
  name TEXT,
  embedding VECTOR(1536) -- For OpenAI-style embeddings
);

Example: Vector similarity query

SELECT name
FROM user_embeddings
ORDER BY embedding <-> '[0.1, 0.2, 0.3, ...]'
LIMIT 5;

This query finds the top 5 users with embeddings most similar to a given vector, enabling fast semantic search.

3. MongoDB Overview

MongoDB is a NoSQL document database that stores data as JSON-like BSON documents. It is schema-less by default, horizontally scalable, and designed for developer productivity. MongoDB is a great fit for unstructured or semi-structured data, which is common in AI pipelines—think logs, events, user profiles, and chat histories.

MongoDB's flexible schema allows rapid iteration as data models evolve, which is especially useful in fast-moving AI projects. Its aggregation framework and Atlas Search features make it a strong choice for analytics and vector search at scale.

Example: Sample AI log entry in MongoDB

{
  "userId": "abc123",
  "query": "best books on ai",
  "timestamp": ISODate("2025-07-20T12:00:00Z"),
  "embedding": [0.1, 0.2, 0.3, ...],
  "responseTokens": 143
}

Example: Inserting into MongoDB with Node.js

await db.collection("logs").insertOne({
  userId: "abc123",
  query: "best books on ai",
  timestamp: new Date(),
  embedding: embeddingArray,
  responseTokens: 143
});

This approach is ideal for storing diverse, rapidly changing AI data.

4. Performance & Querying for AI Workloads

PostgreSQL Advantages

Supports complex joins, filtering, and analytics with SQL
Ideal for structured vector storage and ranked retrieval
Native vector search with pgvector extension
Strong transactional guarantees for data integrity

MongoDB Advantages

Flexible document structure for varied AI inputs
Fast read/write at scale for loosely structured data
Indexing and Atlas Search for vector search with $vectorSearch
Built-in sharding for horizontal scaling

Example: MongoDB vector search using Atlas

const result = await db.collection("logs").aggregate([
  {
    $search: {
      index: "vector_index",
      knnBeta: {
        vector: queryVector,
        path: "embedding",
        k: 5
      }
    }
  }
])

This query finds the top 5 most similar embeddings to queryVector using MongoDB Atlas Search.

Conclusion:

PostgreSQL excels in structured ML pipelines where data relationships and precision matter.
MongoDB shines for flexible, high-volume ingest and retrieval of diverse AI data.

5. Schema Design & Flexibility

PostgreSQL

Requires a defined schema for tables and columns
Good for consistency, validation, and modeling relationships
Newer support for JSONB allows hybrid modeling of structured and semi-structured data

Example: JSONB for chat metadata

CREATE TABLE ai_chats (
  id SERIAL PRIMARY KEY,
  user_id INT,
  metadata JSONB
);

This allows storing flexible metadata alongside structured columns.

MongoDB

Schema-less by default, but schema validation is optional
Better for evolving datasets, logs, and event streams
No need to predefine fields documents can vary in structure

Example: No schema required for chat metadata

{
  "user_id": 1245,
  "chat_id": "xyz789",
  "metadata": {
    "model": "gpt-4",
    "prompt_length": 456,
    "feedback": "Great"
  }
}

This flexibility is valuable for AI apps where data formats change frequently.

6. Vector Search & AI Extensions

PostgreSQL

pgvector enables native vector search and similarity queries
Can integrate with open-source LLM inference layers for advanced AI
Supports hybrid search: combine filters, vector similarity, and full-text search
Self-hosted or managed options available

MongoDB

Vector search via Atlas Search, with approximate nearest neighbor (ANN) indexing
Easy integration with embeddings from OpenAI, Cohere, and other providers
Hosted solution via Atlas is fast to deploy and scale
Partial support for hybrid search (vector + filter)

Comparison Table:

Feature	PostgreSQL (pgvector)	MongoDB (Atlas)
Native vector support	Yes	Yes (Atlas only)
Indexing	ivfflat	Approximate NN
Hybrid search	Yes	Partial
Self-hosted	Yes	Limited
SaaS performance	Good	Excellent

7. Tooling & Ecosystem

PostgreSQL

Compatible with Python (psycopg2, SQLAlchemy), R, Go, and more
Integrates well with Airflow, Jupyter, and data warehousing tools
Rich ecosystem of extensions and plugins (PostGIS, TimescaleDB, Citus)
Strong support for analytics and reporting

MongoDB

SDKs and drivers for every major language
Real-time change streams for event-driven AI
Built-in horizontal scaling and sharding
Atlas platform provides metrics, dashboards, and managed backups
Good integration with cloud-native AI pipelines

8. Use Cases in AI Apps

Use PostgreSQL when:

You need structured, normalized data with relationships
You want full-text plus vector search in one database
You require consistency and relational integrity
Your AI pipeline needs precise, reproducible embedding lookups

Use MongoDB when:

You ingest large volumes of user queries, logs, or events
You need flexible schemas for evolving data
You prioritize fast iteration with changing AI outputs
Your app stores unstructured conversation history or diverse user data

Real Example:

PostgreSQL: Used in RAG pipelines where embedding lookup must be precise and reproducible
MongoDB: Used in GenAI chat apps to store unstructured conversation history and user events

10. Impact of PostgreSQL and MongoDB on AI Applications

Real-World Adoption and Industry Trends

Both PostgreSQL and MongoDB have seen massive adoption in the AI and data science communities. Major tech companies, startups, and research labs rely on these databases to power everything from recommendation engines to conversational AI. PostgreSQL’s maturity and reliability make it a go-to choice for enterprises that need strong consistency, compliance, and advanced analytics. MongoDB’s flexibility and ease of scaling have made it popular for fast-moving AI startups and teams building products with rapidly evolving data models.

Examples of adoption:

Leading AI platforms use PostgreSQL for storing embeddings, user profiles, and transactional data that require relational integrity.
MongoDB is widely used in chatbots, event logging, and real-time analytics for GenAI apps, where the data structure is fluid and high ingest rates are common.
Hybrid architectures are increasingly common, with PostgreSQL handling structured, high-value data and MongoDB managing unstructured logs, events, and user interactions.

Shaping AI Architectures

The choice between PostgreSQL and MongoDB directly influences how AI systems are designed:

PostgreSQL-centric architectures often feature well-defined schemas, strong data validation, and support for complex analytics. This is ideal for ML pipelines that require reproducibility, auditability, and integration with BI tools.
MongoDB-centric architectures enable rapid prototyping, easy ingestion of diverse data, and seamless scaling. This is especially useful for applications that must adapt to new data types or user behaviors on the fly.
Hybrid patterns are emerging, where vector search and transactional data live in PostgreSQL, while MongoDB handles chat logs, feedback, and telemetry. Data pipelines may synchronize between the two for analytics and model training.

Influence on Developer Workflows

PostgreSQL’s strong typing, SQL support, and ecosystem of extensions encourage best practices in data modeling and validation. Developers can leverage familiar tools like SQLAlchemy, dbt, and Jupyter for analytics and experimentation.
MongoDB’s document model and flexible schema allow developers to iterate quickly, especially in the early stages of AI product development. The aggregation framework and Atlas Search make it easy to build analytics and search features without complex migrations.
Both databases offer robust cloud-managed options (e.g., AWS RDS for PostgreSQL, MongoDB Atlas) that reduce operational overhead and let teams focus on building AI features rather than managing infrastructure.

Hybrid and Polyglot Persistence Patterns

As AI applications become more complex, teams are increasingly adopting polyglot persistence using multiple databases for different workloads. For example:

Store user embeddings and vector indexes in PostgreSQL for fast, precise similarity search.
Log user interactions, chat histories, and feedback in MongoDB for flexible querying and analytics.
Use ETL pipelines to move data between systems for model retraining, monitoring, and reporting.

This approach allows teams to leverage the strengths of each database, optimize for performance and cost, and future-proof their architectures as AI requirements evolve.

The Future of Database-Driven AI

Looking ahead, the lines between SQL and NoSQL are blurring. PostgreSQL continues to add features for unstructured data (JSONB, full-text search, vector support), while MongoDB is investing in transactional guarantees and advanced indexing. Both are integrating more deeply with AI/ML tooling, making it easier to build, deploy, and monitor intelligent applications.

Expect tighter integration with LLMs, vector databases, and real-time analytics platforms.
Database vendors are adding native support for AI workloads, such as built-in vector search, hybrid queries, and model inference.
The rise of serverless and edge computing will push both PostgreSQL and MongoDB to offer more flexible, distributed deployment options.

In summary:

PostgreSQL and MongoDB are foundational to the next generation of AI apps.
Their impact is seen in faster development cycles, more powerful search and analytics, and the ability to handle both structured and unstructured data at scale.
The best AI architectures in 2025 will be those that combine the strengths of both, enabling teams to innovate rapidly while maintaining data quality and performance.

9. Conclusion

PostgreSQL and MongoDB both play vital roles in powering AI applications in 2025. PostgreSQL provides structured strength, relational integrity, and vector precision for ML pipelines that demand accuracy and consistency. MongoDB enables flexible, scalable handling of dynamic AI data, making it ideal for fast-moving, high-volume applications.

The best choice depends on your data’s structure, performance needs, and tooling preferences. In many real-world AI systems, teams use both PostgreSQL for embeddings and analytics, MongoDB for conversations, logs, and events. Understanding the strengths and trade-offs of each will help you architect robust, future-proof AI solutions.

Why React Server Components Are a Game-Changer for Performance in 2025

Otieno Keith — Sun, 20 Jul 2025 19:28:29 +0000

1. Introduction

Modern web applications demand high performance, fast load times, and seamless interactivity. Traditional React apps, while powerful, often struggle with performance bottlenecks due to hydration costs, large JavaScript bundles, and heavy client-side logic. As applications grow, these issues become more pronounced, leading to slower time-to-interactive and increased resource usage on users' devices.

Frameworks like Next.js have evolved to address these challenges, introducing server-side rendering (SSR), static site generation (SSG), and incremental static regeneration (ISR). However, these solutions still require shipping significant JavaScript to the client and hydrating components after the initial HTML is loaded.

React Server Components (RSC) represent the next logical step in optimizing performance. By allowing components to render on the server and only sending interactivity to the client when necessary, RSCs dramatically reduce bundle sizes and improve user experience. This article explores what React Server Components are, how they work, and why they are essential for building high-performance apps in 2025.

2. Traditional React: Performance Bottlenecks

In a typical React application, most rendering happens on the client. The server sends a minimal HTML shell, and the browser downloads a large JavaScript bundle. Once loaded, React hydrates the app, attaching event listeners and making the UI interactive. This process is resource-intensive and can delay the time-to-interactive, especially on slower devices or networks.

Key bottlenecks:

Hydration cost: The browser must parse, execute, and hydrate the entire React tree, even for static content.
Large bundles: All components, logic, and dependencies are shipped to the client, increasing download and parse times.
Client-side data fetching: Fetching data in the browser means users wait longer for content to appear.

Example: Traditional client component

// client component
'use client'
import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  )
}

In this model, even simple components like counters require JavaScript to be shipped and hydrated on the client.

3. What Are React Server Components?

React Server Components (RSC) are a new type of React component that renders entirely on the server. Unlike traditional client components, RSCs do not send any unnecessary JavaScript to the browser. They are never hydrated or re-rendered on the client unless explicitly needed.

Key characteristics:

No hydration: Server components are rendered to HTML and sent to the client as static markup. No client-side JavaScript is needed for these components.
Direct server access: RSCs can access server-side resources like databases, file systems, and API keys without exposing them to the client.
Zero bundle size: Since server components never run in the browser, they do not contribute to the client-side JavaScript bundle.
Composable with client components: You can mix server and client components in the same tree, opting into interactivity only where needed.

Example: Simple server component in Next.js App Router

// app/dashboard/page.tsx (Server Component by default)

async function getData() {
  const res = await fetch('https://api.example.com/data', { cache: 'no-store' })
  return res.json()
}

export default async function Dashboard() {
  const data = await getData()

  return (
    <div>
      <h1>Dashboard</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  )
}

In this example, the Dashboard component fetches data on the server and sends only the rendered HTML to the client. No JavaScript is shipped for this component.

4. How RSCs Improve Performance

React Server Components offer several performance benefits over traditional client-side rendering:

Zero JavaScript for server-only components: If a component does not require interactivity, it is never sent to the client as JavaScript.
Smaller bundles: Only interactive components are bundled and shipped, reducing download and parse times.
Reduced hydration time: Server components do not need to be hydrated, freeing up CPU and memory on the client.
Direct data access: Server components can fetch data directly from databases or APIs, eliminating the need for client-side API calls or proxies.
Streaming and partial rendering: RSCs can be streamed to the client as they are rendered, improving perceived performance and enabling faster first paint.

Example: Mixing server and client components

// Server Component
import Counter from './Counter'

export default function Page() {
  return (
    <div>
      <h1>Server Component</h1>
      <Counter />
    </div>
  )
}

// Client Component
'use client'

import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>
}

Here, the Page component is rendered on the server, while the Counter component is interactive and runs on the client. Only the Counter's code is shipped to the browser.

5. RSC in Next.js 14+ App Router

Next.js 14 and later fully support React Server Components using the App Router and the app/ directory. By default, all files in the app/ directory are server components unless marked with 'use client'.

Key features:

Server components by default: No need to opt in. Only add 'use client' when interactivity is required.
Built-in loading and error UI: Use <Suspense> and error boundaries for streaming and graceful error handling.
Automatic code splitting: Only the code needed for each route is loaded, reducing bundle size.
Streaming: Server components can be streamed to the client as they are rendered, improving time-to-first-byte.

Example: Layout with server-rendered sidebar

// app/layout.tsx
export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <Sidebar /> {/* Server component */}
        {children}
      </body>
    </html>
  )
}

Example: Route-based data fetching in server components

// app/products/page.tsx
export default async function Products() {
  const res = await fetch('https://dummyjson.com/products')
  const data = await res.json()

  return (
    <ul>
      {data.products.map(product => (
        <li key={product.id}>{product.title}</li>
      ))}
    </ul>
  )
}

In both examples, data fetching and rendering happen on the server, and only the final HTML is sent to the client.

6. When to Use Server vs Client Components

Use server components when:

You need to fetch data from a database or API
No interactivity is required
You want to keep server secrets hidden from the client
You want to minimize bundle size and maximize performance

Use client components when:

You need interactivity (forms, modals, counters)
You use React state or effects
You rely on browser APIs (localStorage, window, etc.)
You need to handle user input or real-time updates

Tip: Default to server components. Only opt into client components when interactivity is necessary.

7. Drawbacks and Limitations

While React Server Components offer significant performance benefits, they also introduce new challenges:

Learning curve: Developers must understand the distinction between server and client components, and how to compose them effectively.
Debugging complexity: Debugging can be more difficult when logic is split between server and client.
Framework support: RSCs are currently only supported in certain frameworks, such as Next.js with the App Router.
Ecosystem maturity: Not all third-party libraries are compatible with RSCs yet. Some libraries assume client-side execution and may not work as expected.
Tooling: Development tools and error messages are still catching up to the new paradigm.

Despite these limitations, the benefits for performance-focused applications are substantial.

8. Future of React Performance

Looking ahead to 2025, React Server Components are poised to become the default for performance-first applications. Combined with streaming, edge rendering, and modern deployment platforms, RSCs enable apps to be faster and more scalable by default.

Streaming and edge rendering: RSCs can be streamed from the server or edge locations, reducing latency and improving user experience globally.
Optimized delivery: Tools like Vercel and Turbopack are designed to optimize the delivery of server components, further reducing load times.
Ecosystem adoption: Expect more first-party support from React and Next.js, as well as growing compatibility with third-party libraries.
Developer experience: As tooling matures, building with RSCs will become easier and more intuitive.

In 2025, high-performance web apps will be built with a server-first mindset, leveraging RSCs for the best possible user experience.

9. Conclusion

React Server Components fundamentally change how developers approach performance in web applications. By keeping logic and data fetching on the server, and only shipping interactivity to the client when needed, bundle sizes shrink and speed improves.

RSCs are not a silver bullet, but they represent a major leap forward in modern web performance. As the ecosystem matures and adoption grows, embracing server-first design will be key to building fast, scalable, and maintainable apps in 2025 and beyond.

The Evolution of CSS: From Float Hacks to Tailwind & Utility-First Design

Otieno Keith — Sun, 20 Jul 2025 19:22:10 +0000

1. Introduction

Cascading Style Sheets (CSS) is the language that brings the web to life visually. Since its introduction in the late 1990s, CSS has been foundational for web design, enabling developers to separate content from presentation and create visually engaging, responsive experiences. Over the decades, CSS has evolved dramatically, from simple color and font changes to complex layouts and utility-first paradigms.

This article traces the journey of CSS: from the early days of float-based hacks, through the rise of frameworks like Bootstrap, to the modern era of Tailwind and utility-first design. Along the way, we’ll see real code examples from each era, understand the motivations behind each shift, and learn when to use (or avoid) the latest tools. By the end, you’ll have a deep appreciation for how far CSS has come and where it’s heading next.

2. The Early Days of CSS

Before CSS matured, web layouts were often built with HTML tables, making maintenance and accessibility a nightmare. Early CSS usage in the 2000s was basic: inline styles, <font> tags, and simple external stylesheets. Developers used CSS mainly for fonts, colors, and spacing, with little support for layout.

Example: Early CSS for fonts and colors

body {
  background-color: #ffffff;
  font-family: Arial, sans-serif;
  color: #000000;
}
h1 {
  color: #3366cc;
  font-size: 2em;
}

This era was about basic visual tweaks, not layout. Most sites still relied on table-based structures for positioning.

2.1. The Rise of CSS Preprocessors

As CSS projects grew, developers needed variables, mixins, and logic—features missing from vanilla CSS. Preprocessors like Sass, LESS, and Stylus emerged, compiling enhanced syntax into standard CSS. They enabled DRY (Don’t Repeat Yourself) principles and large-scale maintainability.

Example: Sass variables and nesting

$primary: #3490dc;
body {
  background: $primary;
  h1 {
    color: darken($primary, 20%);
  }
}

Impact:

Variables, functions, and mixins for reusable code
Nested selectors for better structure
Widespread adoption in large codebases and frameworks

3. The Float Hack Era

As CSS matured, developers sought ways to move beyond tables for layout. The float property, originally intended for wrapping text around images, was repurposed to create multi-column layouts. This led to the infamous "float hack" era.

How it worked:

Elements were floated left or right to create columns.
Containers would collapse unless "cleared"—leading to clearfix hacks.
Responsive design was difficult and required lots of manual work.

Example: Float-based two-column layout with clearfix

<div class="container">
  <div class="left">Sidebar</div>
  <div class="right">Content</div>
</div>

<style>
.container::after {
  content: "";
  display: table;
  clear: both;
}
.left {
  float: left;
  width: 30%;
}
.right {
  float: right;
  width: 70%;
}
</style>

Pros:

Enabled multi-column layouts without tables.
Widely supported.

Cons:

Required clearfix hacks to prevent container collapse.
Not truly responsive or flexible.
Source order mattered for layout.

4. Positioning & Display Tricks

To overcome float limitations, developers turned to position: absolute, relative, and inline-block for more control. These techniques enabled overlays, tooltips, and some early responsive tricks, but came with their own quirks.

Example: Overlay element using absolute positioning

<div class="relative">
  <img src="banner.jpg">
  <div class="overlay">Text on top</div>
</div>

<style>
.relative {
  position: relative;
}
.overlay {
  position: absolute;
  top: 10px;
  left: 20px;
  color: white;
}
</style>

Other tricks:

display: inline-block for horizontal layouts.
Negative margins for overlapping elements.
Early media queries for basic responsiveness.

Limitations:

Absolute positioning removed elements from normal flow.
Inline-block had whitespace issues.
Layouts were still fragile and hard to maintain.

5. Flexbox & CSS Grid Revolution

Flexbox: One-Dimensional Layout

Flexbox, introduced in 2012, was a game-changer for layout. It enabled easy alignment, spacing, and reordering of items in a single dimension (row or column).

Example: Flexbox horizontal layout

<div class="flex-container">
  <div>Item 1</div>
  <div>Item 2</div>
</div>

<style>
.flex-container {
  display: flex;
  gap: 10px;
}
</style>

Key features:

Align items vertically and horizontally with align-items and justify-content.
Automatic equal heights.
Responsive by default.
flex-wrap for multi-line layouts
order property for reordering items visually
flex-grow, flex-shrink, and flex-basis for flexible sizing

Example: Responsive navbar with Flexbox

<nav class="navbar">
  <a href="#">Home</a>
  <a href="#">About</a>
  <a href="#">Contact</a>
</nav>

<style>
.navbar {
  display: flex;
  justify-content: space-between;
  background: #222;
  color: #fff;
  padding: 1em;
}
.navbar a {
  color: #fff;
  text-decoration: none;
  margin: 0 1em;
}
</style>

CSS Grid: Two-Dimensional Layout

CSS Grid, standardized in 2017, brought true two-dimensional layout to the web. Developers could now define rows and columns, place items anywhere, and create complex, responsive grids with minimal code.

Example: Grid-based layout with two rows, two columns

<div class="grid-container">
  <div>Header</div>
  <div>Sidebar</div>
  <div>Main</div>
  <div>Footer</div>
</div>

<style>
.grid-container {
  display: grid;
  grid-template-columns: 1fr 3fr;
  grid-template-rows: auto auto;
  gap: 10px;
}
</style>

Advanced Grid Features:

Named grid areas for semantic layouts
Implicit vs. explicit grid tracks
minmax() and auto-fit for responsive grids
Grid item spanning and alignment

Comparison:

Flexbox: Best for one-dimensional layouts (navbars, toolbars, lists).
Grid: Best for two-dimensional layouts (dashboards, page layouts).
Both can be combined for powerful, responsive designs.

6. The Rise of CSS Frameworks

As web apps grew, so did the need for consistency and speed. Frameworks like Bootstrap (2011), Foundation, and Bulma emerged, offering pre-built grids, buttons, and UI components.

How frameworks helped:

Rapid prototyping with ready-made classes.
Consistent design language across teams.
Responsive grids and utilities out of the box.

Example: Bootstrap grid layout

<div class="container">
  <div class="row">
    <div class="col-md-4">Sidebar</div>
    <div class="col-md-8">Content</div>
  </div>
</div>

Drawbacks:

Large CSS files (bloat).
Overriding styles could be painful.
Sites started to look the same.
Customization required deep knowledge of framework internals.

6.1. CSS-in-JS: Styling in the Component Era

With the rise of React, Vue, and component-driven architectures, CSS-in-JS libraries like styled-components, Emotion, and JSS emerged. These tools allow developers to write CSS directly in JavaScript, scoping styles to components and enabling dynamic theming.

Example: styled-components in React

import styled from 'styled-components';

const Button = styled.button`
  background: #3490dc;
  color: white;
  padding: 0.5em 1em;
  border-radius: 4px;
  &:hover {
    background: #2779bd;
  }
`;

export default function App() {
  return <Button>Click me</Button>;
}

Benefits:

Automatic scoping, no global class collisions
Dynamic styles based on props/state
Co-located styles and logic

Drawbacks:

Larger bundle sizes if not optimized
Tooling and SSR (server-side rendering) complexity
Not always ideal for static sites or non-JS projects

7. Utility-First CSS & Tailwind

The next evolution was utility-first CSS, popularized by Tailwind CSS. Instead of writing custom CSS or using semantic class names, developers compose UIs from small, single-purpose utility classes.

What is Utility-First?

Each class does one thing (e.g., p-4 for padding, text-blue-500 for color).
No need to write custom CSS for most use cases.
Encourages consistency and rapid iteration.

Example: Tailwind utility-based layout

<div class="flex items-center justify-between bg-blue-500 text-white p-4 rounded">
  <span class="text-xl font-semibold">Hello</span>
  <button class="bg-white text-blue-500 px-4 py-2 rounded">Click</button>
</div>

Pros:

No context switching between HTML and CSS files.
Consistent, design-system-driven UIs.
Just-In-Time (JIT) compilation for fast builds and small CSS bundles.
Easy to integrate with React, Vue, Alpine.js, and other frameworks.

Cons:

HTML can become cluttered with classes.
Readability may suffer for non-developers.
Semantic meaning can be lost if not careful.

Tailwind Plugins & Ecosystem:

Plugins for forms, typography, aspect ratios, and more.
Integrates with PostCSS, PurgeCSS, and modern build tools.
Growing ecosystem for themes, UI kits, and component libraries.

8. When (and When Not) to Use Tailwind

Tailwind is great for:

Component-based apps (React, Vue, Svelte)
Design systems and rapid prototyping
Teams that value consistency and speed
Projects where designers and developers collaborate closely

Tailwind may not be ideal when:

Semantic HTML and accessibility are top priorities
Content teams or non-technical editors work directly in HTML
Highly unique, brand-driven designs are required
You need to support legacy browsers without PostCSS/polyfills

Evaluate based on your project’s needs and team workflow.

9. The Future of CSS

CSS continues to evolve rapidly. New features are making their way into browsers, often inspired by frameworks like Tailwind:

:has() pseudo-class for parent selectors
Native CSS nesting
Container queries for truly responsive components
The @scope rule for local scoping

Frameworks and native CSS are converging. The future may see hybrid approaches, with utility classes, semantic CSS, and component-based styles all working together.

10. Conclusion

From float hacks to utility-first design, CSS has come a long way. Each era solved real developer pain points and paved the way for the next innovation. Understanding this history helps you appreciate the power and flexibility of today’s tools, and prepares you for what’s next.

Tailwind isn’t the end of the story. It’s a reflection of evolving developer needs and the ongoing quest for maintainable, scalable, and expressive styling. Keep exploring, stay curious, and embrace the future of CSS.

Understanding Serverless Architecture: AWS Lambda, Edge Functions & When to Use What

Otieno Keith — Sun, 20 Jul 2025 19:12:37 +0000

1. Introduction

Cloud computing has rapidly evolved from physical servers to virtual machines, then to containers, and now to serverless computing. Each step has abstracted more infrastructure away from developers, letting them focus on code and business logic rather than server management. Serverless is a paradigm shift: you write functions, deploy them, and the cloud provider handles everything else provisioning, scaling, patching, and billing.

Serverless is event-driven and cost-efficient, charging you only for actual usage, not idle time. Two of the most popular serverless approaches are AWS Lambda and Edge Functions. AWS Lambda pioneered the Function-as-a-Service (FaaS) model, while Edge Functions push serverless even closer to the user, running code at the edge of the network.

This article compares AWS Lambda and Edge Functions in terms of architecture, use cases, and best practices, helping you decide when to use each for your workloads.

1.1. The Evolution of Serverless (Expanded)

The journey to serverless began with physical servers, which required manual provisioning, maintenance, and scaling. Virtual machines (VMs) improved resource utilization but still required OS management. Containers, popularized by Docker, made it easier to package and deploy applications, but developers still had to manage orchestration (e.g., Kubernetes).

Serverless abstracts away all infrastructure concerns. Developers deploy code as functions, and the cloud provider handles everything else. This shift enables:

Faster time to market
Reduced operational overhead
Automatic scaling to zero when not in use

2. What is Serverless Architecture?

Serverless computing is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Developers deploy code as functions, which are triggered by events (HTTP requests, file uploads, queue messages, etc.).

Key traits:

Event-driven: Functions run in response to triggers.
Auto-scaling: Instantly scales to handle any number of events.
No infrastructure management: No servers to patch, scale, or monitor.
Fine-grained billing: Pay only for actual compute time (down to milliseconds).

Compared to traditional servers and containers:

No need to manage OS, runtime, or scaling logic.
No paying for idle resources.
Faster to deploy and iterate.

Popular serverless platforms:

AWS Lambda
Netlify Functions
Cloudflare Workers
Azure Functions
Google Cloud Functions

3. AWS Lambda: The Core of Serverless

AWS Lambda, launched in 2014, is Amazon’s Function-as-a-Service (FaaS) platform. It lets you run code in response to events without provisioning or managing servers. Lambda is deeply integrated with the AWS ecosystem, making it a core building block for modern cloud-native applications.

Architecture:

Event Triggers: Lambda functions are invoked by AWS services (S3, API Gateway, DynamoDB, etc.) or external events (HTTP, schedules).
Container Execution: Each function runs in a lightweight, isolated container managed by AWS. Since 2018, Lambda uses Firecracker microVMs for fast, secure, and efficient execution. Firecracker is a purpose-built VMM (Virtual Machine Monitor) that launches microVMs in as little as 125ms, providing strong isolation and security.
VPC Integration: Functions can run inside your Virtual Private Cloud for secure access to databases and internal services. Lambda can attach to VPC subnets and security groups, allowing fine-grained network control.

Supported Languages:

Node.js, Python, Java, Go, Ruby, .NET, and custom runtimes via Lambda Layers. Lambda Layers allow you to share code and dependencies across multiple functions, improving maintainability.

Integration:

Tight integration with AWS services: S3, DynamoDB, Kinesis, SNS, SQS, API Gateway, EventBridge, and more. Lambda can be the glue for event-driven architectures, connecting disparate AWS services with minimal code.

Duration & Limits:

Max execution time: 15 minutes per invocation
Memory: 128 MB to 10 GB
Ephemeral disk: 512 MB (recently up to 10 GB with /tmp)
Environment variables and IAM roles for secure configuration and access control

Example Use Case:
Image processing on S3 upload:

// S3 triggers Lambda on image upload
exports.handler = async (event) => {
  // Process image, generate thumbnail, store result
};

Other Real-World Examples:

Real-time log processing and alerting
Automated backups and data transformation
Chatbot backends and webhook handlers

Cold vs. Warm Starts:

Cold start: First invocation spins up a new container, adding latency (100ms–1s typical). Cold starts are more noticeable in VPC-attached Lambdas.
Warm start: Recently used containers are reused, reducing latency. AWS keeps containers alive for a short period after use.
Concurrency model: Lambda automatically scales by running multiple containers in parallel. You can set reserved concurrency to guarantee capacity or limit costs.

Pricing:

Charged per request and compute time (GB-seconds)
Example: $0.20 per 1M requests, $0.00001667 per GB-second (as of 2024)
Free tier: 1M requests and 400,000 GB-seconds per month

4. Edge Functions: Serverless at the Edge

Edge Functions are serverless functions deployed at the edge of the network close to users, in CDN Points of Presence (PoPs). This enables ultra-low latency, personalized, and globally distributed logic.

Popular platforms:

Cloudflare Workers
Vercel Edge Functions
Netlify Edge Functions
AWS Lambda@Edge

Architecture:

Deployed at CDN PoPs: Code runs in data centers around the world, near end-users. This reduces latency and improves user experience for global audiences.
Isolation Model: Most use V8 isolates (like Chrome’s JS engine) for lightweight, fast, and secure execution. Unlike containers or VMs, isolates share the same process but are strongly sandboxed, allowing thousands of functions to run concurrently with minimal overhead.
Runtime Limits: Typically shorter than Lambda (e.g., 1–5ms CPU time, 50ms wall time for Cloudflare Workers). Edge functions are designed for fast, lightweight tasks.

Latency Benefits:

Requests are processed close to the user, reducing round-trip time.
Ideal for personalization, A/B testing, and geo-based logic.
Can be used for security headers, bot mitigation, and real-time redirects.

Example Use Case:
Geo-personalized content delivery:

export default async (request) => {
  const country = request.headers.get('cf-ipcountry');
  return new Response(`Hello from ${country}!`);
};

Other Real-World Examples:

Injecting custom headers for security or analytics
Dynamic image resizing and optimization at the edge
Blocking malicious traffic before it reaches your origin servers

Limitations:

No file system access
Limited language support (mostly JavaScript/TypeScript, some WASM)
Shorter execution and memory limits
No direct VPC/database access (must use HTTP APIs)
Limited support for long-running or stateful operations

Pricing:

Usually request-based, with generous free tiers
Example: Cloudflare Workers—first 100,000 requests/day free, then $0.30 per million
Vercel and Netlify offer free and paid plans with varying limits

4.1. Security and Compliance in Serverless

Security is a shared responsibility in serverless. While providers secure the infrastructure, developers must secure their code and configurations.

Key considerations:

Least privilege: Use IAM roles and policies to restrict Lambda permissions.
Environment variables: Store secrets securely (use AWS Secrets Manager or Parameter Store).
Input validation: Always validate and sanitize event data.
Audit logging: Enable CloudTrail and monitor function invocations.
Edge Functions: Avoid storing sensitive data at the edge; use HTTPS and secure headers.
Compliance: Check provider certifications (SOC2, GDPR, HIPAA) and ensure your architecture meets regulatory requirements.

5. Lambda vs. Edge Functions: When to Use What

Feature	AWS Lambda	Edge Functions
Location	AWS regions (data centers)	CDN PoPs (edge locations)
Latency	50–200ms typical	1–20ms typical
Runtimes	Node.js, Python, etc.	JS/TS, WASM
Integration	Deep AWS integration	CDN, HTTP, limited cloud APIs
Use Cases	Backend, data processing	Personalization, routing
Language	Many	Few (JS/TS, WASM)
Limits	15 min, 10GB RAM	~50ms, 128MB RAM

Decision Framework:

Choose Edge Functions when:
- Latency is critical (e.g., geo-routing, A/B testing)
- Logic is lightweight and stateless
- You need to run code close to users globally
Choose AWS Lambda when:
- You need deep AWS integration (S3, DynamoDB, VPC)
- Workloads are backend-heavy or require longer execution
- You need broader language/runtime support
Hybrid Approach:
- Use Edge Functions for request routing, authentication, or personalization
- Forward complex processing to AWS Lambda or other backend services

6. Common Use Cases

AWS Lambda:

Real-time image/video processing (e.g., on S3 upload)
API backends (REST, GraphQL)
Event-driven pipelines (DynamoDB streams, Kinesis analytics)
Scheduled jobs (cron-like tasks)
Data enrichment and ETL (Extract, Transform, Load) pipelines
Automated security remediation (e.g., responding to GuardDuty alerts)

Edge Functions:

Geo-routing and localization
A/B testing and feature flagging
Injecting authentication headers
URL redirects and rewrites
Real-time personalization (e.g., language or currency selection)
Edge caching strategies for dynamic content

7. Challenges & Limitations

AWS Lambda:
- Cold starts can add latency
- Vendor lock-in (AWS-specific APIs)
- Debugging and observability, especially in VPC
- Limited support for long-running or stateful workflows
Edge Functions:
- Strict runtime and memory limits
- Restricted environment (no file system, limited language support)
- Limited integration with backend databases
General:
- Observability and debugging can be harder than with traditional servers
- State management (stateless by design)
- Complexity in chaining multiple functions/services
- Testing and local development can be more challenging

8. Conclusion & Best Practices

Choosing between AWS Lambda and Edge Functions depends on your needs:

Use Edge Functions for ultra-low latency, lightweight, and globally distributed logic.
Use Lambda for backend-heavy, AWS-integrated, or long-running workloads.
Hybrid architectures can leverage both for best results.

Best Practices:

Use Infrastructure as Code (IaC) tools (Serverless Framework, SST, AWS CDK)
Add observability and logging early
Monitor costs and optimize for usage patterns
Prototype and test before scaling to production
Keep functions small and single-purpose for easier maintenance
Regularly review and update permissions and dependencies
Stay up to date with provider improvements and new features

Serverless is a powerful paradigm choose the right tool for the job, and you’ll build scalable, cost-effective, and maintainable cloud applications.

How to Make Your First Chrome Extension with Manifest V3

Otieno Keith — Sun, 20 Jul 2025 18:54:48 +0000

Have you ever wanted to build your own Chrome extension? Maybe something small that adds a cool feature to your browser or automates a task? You’re in the right place.

In this guide, you’ll build a simple Chrome extension using Manifest V3 that changes the background color of a webpage. This tutorial assumes no prior experience with Chrome Extensions, so we’ll walk through everything step-by-step.

By the end of this tutorial, you’ll learn:

What a Chrome Extension is
How Manifest V3 works
How to use JavaScript to interact with web pages
How to install and test your extension locally

1. What is a Chrome Extension?

A Chrome extension is a small software program that customizes the browsing experience. Extensions can add new features to Chrome, modify web pages, automate repetitive tasks, or integrate with other services. They’re built using web technologies like HTML, CSS, and JavaScript, and are distributed through the Chrome Web Store or loaded locally for development.

Extensions are made up of several files:

manifest.json: The configuration file that tells Chrome about your extension.
HTML/CSS/JS files: For the popup UI and logic.
Background scripts: For persistent logic or event handling.
Icons: For branding in the toolbar and Chrome Web Store.

2. Understanding Manifest V3

The manifest is the heart of every Chrome extension. Manifest V3 (MV3) is the latest version, designed to improve security, privacy, and performance. MV3 introduces a new way to handle background logic (service workers), stricter permissions, and a more declarative approach to extension capabilities.

A basic manifest.json for our extension looks like this:

{
  "manifest_version": 3,
  "name": "ColorSwap",
  "version": "1.0",
  "description": "Change the background color of the current tab to light blue.",
  "permissions": ["scripting", "activeTab"],
  "host_permissions": ["<all_urls>"],
  "background": {
    "service_worker": "background.js"
  },
  "action": {
    "default_popup": "popup.html",
    "default_title": "ColorSwap"
  }
}

Key fields explained:

manifest_version: Must be 3 for new extensions.
name, version, description: Basic metadata.
permissions: What the extension can access. scripting lets us inject code, activeTab allows access to the current tab.
host_permissions: Specifies which sites the extension can interact with. "<all_urls>" means all sites.
background: Points to a service worker script (background.js). For this extension, it can be empty.
action: Defines the popup UI and its title.

3. Setting Up Your Project Folder

Create a new folder for your extension, e.g., ColorSwap. Inside, create these files:

ColorSwap/
├── manifest.json
├── popup.html
├── popup.js
├── background.js

The icons/ folder and icon files are optional for development.

4. Building the Popup UI (popup.html)

The popup is the small window that appears when you click your extension’s icon. Here’s a simple example:

<!DOCTYPE html>
<html>
  <head>
    <title>ColorSwap</title>
    <style>
      body { min-width: 200px; font-family: Arial, sans-serif; }
      button { margin-top: 10px; padding: 8px 16px; font-size: 16px; }
    </style>
  </head>
  <body>
    <h2>ColorSwap</h2>
    <button id="change-bg">Change Background</button>
    <script src="popup.js"></script>
  </body>
</html>

This creates a simple UI with a title and a button.

5. Adding JavaScript Logic (popup.js)

The JavaScript file handles the button click and changes the background color of the current tab. Here’s the code:

// Wait for the DOM to load
window.addEventListener('DOMContentLoaded', function () {
  const btn = document.getElementById('change-bg');
  btn.addEventListener('click', async function () {
    // Get the active tab
    let [tab] = await chrome.tabs.query({ active: true, currentWindow: true });
    // Inject code to change background color
    chrome.scripting.executeScript({
      target: { tabId: tab.id },
      func: () => {
        document.body.style.backgroundColor = '#ADD8E6';
        document.documentElement.style.backgroundColor = '#ADD8E6';
        document.body.style.backgroundImage = 'none';
        document.documentElement.style.backgroundImage = 'none';
      }
    });
  });
});

How it works:

Waits for the popup to load.
Adds a click event to the button.
Uses chrome.tabs.query to get the current tab.
Uses chrome.scripting.executeScript to inject a function that changes the background color and removes background images for better compatibility.

6. The Background Script (background.js)

For Manifest V3, background scripts are now service workers. In this extension, background.js can be empty or just a placeholder comment:

// background.js - Service worker placeholder for ColorSwap extension

7. Permissions and Security

Chrome extensions require explicit permissions for everything they do. This is for user safety. Our extension uses:

scripting: To inject JavaScript into web pages.
activeTab: To access the currently active tab when the popup is used.
host_permissions: To specify which sites the extension can interact with. Using "<all_urls>" allows it to work everywhere, but you can restrict this for more privacy.

Always use the minimum permissions needed for your extension’s functionality.

8. Loading and Testing Your Extension

Open Chrome and go to chrome://extensions
Enable “Developer mode” (toggle in the top right)
Click “Load unpacked” and select your extension folder
The extension should appear in your toolbar
Go to any site (e.g., https://www.google.com/)
Click the ColorSwap extension icon to open the popup
Click “Change Background” — the page background should turn light blue (#ADD8E6)

Troubleshooting:

If nothing happens, check the permissions in your manifest.
Some sites (like the Chrome Web Store) block script injection for security reasons.
Check for errors in the Chrome extension page (click “Errors” under your extension).

9. How It Works: Under the Hood

When you click the extension icon, Chrome opens the popup.html file. The popup.js script waits for you to click the button, then:

Finds the active tab
Injects a script into that tab
The injected script sets the background color and removes background images on both <body> and <html> elements

This approach works on most sites, but some with strict Content Security Policies (CSP) or special layouts may require more advanced techniques.

10. Next Steps and Ideas for Improvement

Now that you have a working extension, here are some ideas to take it further:

Let users pick their own color: Add a color input to the popup and use that value in the injected script.
Save user preferences: Use chrome.storage to remember the user’s chosen color.
Add a keyboard shortcut: Use the commands API to let users trigger the extension with a key combo.
Add an icon: Create an icons/ folder and add a 128x128 PNG for branding.
Publish to the Chrome Web Store: Follow the official publishing guide to share your extension with the world.

11. Resources

12. Conclusion

You’ve just built and tested your first Chrome extension using Manifest V3! You learned how to structure an extension, use the manifest, interact with web pages, and test your work. With these basics, you can now explore more advanced features and build powerful tools for your browser.

Happy coding!