Forem: Agbo, Daniel Onuoha

Browser-Based LLMs in Healthcare

Agbo, Daniel Onuoha — Wed, 15 Apr 2026 11:30:23 +0000

The most persistent tension in healthcare AI isn't about model capability — it's about data. Sending a patient's protected health information (PHI) to a remote cloud server, even for a fraction of a second, can trigger HIPAA violations, erode patient trust, and expose organizations to million-dollar penalties. Browser-based Large Language Models (LLMs) dissolve this tension by moving the inference engine off the server and directly into the user's browser, keeping sensitive medical data entirely on-device.

This isn't speculative technology. In April 2026, toolchains like WebLLM, Transformers.js, and the WebGPU API make it practical to run quantized versions of Llama 3, Mistral, and Phi-3 entirely within a Chrome or Firefox tab — with GPU-accelerated performance.

The Core Architecture: Edge AI in the Browser

Traditional healthcare AI follows a client-server model: the frontend collects data, ships it to a cloud API, and receives a response. Browser-based LLMs invert this entirely.

Patient Input (Symptoms / Record)
        ↓
  PII Scrubber (Transformers.js — Local NER)
        ↓
  Anonymized Text
        ↓
  LLM Inference (WebLLM + WebGPU)
        ↓
  Private Summary / Clinical Output
        ↑
  All processing stays inside the browser sandbox

The key enabling technologies are:

WebGPU: A modern browser API that exposes the device's GPU to web applications, enabling tensor operations at near-native speed
WebLLM (MLC AI): An in-browser inference engine that compiles quantized models (e.g., INT4) to WebGPU-optimized WASM bytecode github
Transformers.js: A JavaScript port of HuggingFace Transformers that supports NER, classification, and embedding tasks on-device
WebAssembly (WASM): Provides a portable, sandboxed execution runtime for compiled model weights in the browser

Why Healthcare Is a Perfect Fit

LLMs in general clinical settings have demonstrated strong capabilities across diagnostics, documentation, and patient communication. The browser-native variant extends these advantages with properties uniquely suited to healthcare's compliance requirements.

Privacy by Architecture

When an LLM runs in-browser, PHI never leaves the device. There is no API call, no server log, no third-party data processor to sign a Business Associate Agreement (BAA) with. HIPAA's Security Rule requires that organizations implement administrative, physical, and technical safeguards for electronic PHI (ePHI) — a requirement that is structurally satisfied when data never traverses a network. This is "privacy by architecture," not privacy by policy.

Zero-Latency Clinical Interactions

Cloud LLMs introduce round-trip latency that ranges from hundreds of milliseconds to several seconds, depending on server load and geographic distance. A browser-based model processes the query locally, delivering results at GPU speed with zero network round-trips. In acute clinical scenarios — triage support, real-time documentation during a consultation, intraoperative decision support — even a two-second delay is clinically meaningful.

Offline Capability and Rural Access

Once a model is cached in the browser (via a Service Worker or IndexedDB), it can operate without any internet connection. This is transformative for rural clinics, field hospitals, and under-resourced health systems in developing regions like Sub-Saharan Africa that have intermittent connectivity but still possess modern consumer hardware with capable GPUs.

Real-World Healthcare Use Cases

1. EMR De-identification and Anonymization

Electronic Medical Records (EMRs) are rich in PHI — names, dates, diagnoses, prescription details. Before sharing records for research or inter-departmental review, they must be de-identified. A browser-based pipeline using Transformers.js for Named Entity Recognition (NER) can strip PII from clinical notes locally, then pass the anonymized text to a WebLLM instance for summarization — all without the raw record ever leaving the browser.

2. Private Symptom Screening

A browser-based symptom screener allows patients to describe their symptoms in natural language and receive triage-level guidance — without their health disclosures being logged on any external server. This is especially significant for stigmatized conditions (mental health, HIV, substance use) where patients may withhold information if they suspect surveillance.

3. Clinical Note Generation

LLMs have shown strong performance in generating structured SOAP notes from free-form physician dictation. Running this process in-browser means a physician can dictate, receive a structured draft, review it, and commit only the final note to the EHR — with the intermediate AI processing completely local. pmc.ncbi.nlm.nih

4. Patient-Facing EHR Interpretation

Projects like LLMonFHIR demonstrate how LLMs can translate complex FHIR-formatted EHR data into patient-friendly natural language. A browser-based version of this would allow patients to query their own records conversationally, with full confidence that their medical history never passes through a third-party AI service. pmc.ncbi.nlm.nih

5. Medical Record Summarization

Clinicians reviewing a patient's longitudinal history across multiple encounters can use a local LLM to generate a concise clinical summary from hundreds of pages of records. The model processes everything in the user's GPU memory — a secure and auditable operation by default.

Implementation: Getting Started with WebLLM

Here is a minimal TypeScript implementation of a browser-based medical assistant using WebLLM:

import * as webllm from "@mlc-ai/web-llm";

const engine = await webllm.CreateMLCEngine(
  "Llama-3-8B-Instruct-q4f16_1-MLC",
  {
    initProgressCallback: (report) => console.log(report.text),
  }
);

async function getMedicalSummary(anonymizedNote: string): Promise<string> {
  const messages = [
    {
      role: "system",
      content:
        "You are a clinical documentation assistant. " +
        "Summarize the following anonymized patient note in structured SOAP format. " +
        "Do not fabricate clinical details. Flag ambiguous sections for physician review.",
    },
    { role: "user", content: anonymizedNote },
  ];

  const response = await engine.chat.completions.create({ messages });
  return response.choices[0].message.content ?? "";
}

Key architectural decisions when building for healthcare:

Use quantized models (INT4/INT8) — Full-precision models like Llama 3 70B require 140GB+ VRAM; INT4 quantized 8B models run in 4–6GB, within range of modern consumer GPUs
Run a local NER PII scrubber before the LLM — Use Transformers.js to detect and mask PHI before it enters the generative model's context window
Implement output guardrails — Parse LLM output for clinical red flags (e.g., drug dosage suggestions, differential diagnosis lists) and route them through a validation layer before rendering
Use Web Workers — Offload model inference to a separate thread to keep the UI responsive during long-running inference

Limitations and Engineering Challenges

Browser-based LLMs are powerful, but healthcare engineers must design around several hard constraints: arxiv

Challenge	Detail	Mitigation
Model size	Large models (>13B params) exceed browser memory limits	Use INT4 quantized 7–8B models; evaluate Phi-3 Mini for resource-constrained devices
First-load latency	Models range from 2–8GB; cold-start download is slow	Cache via Service Workers; use progressive loading with user feedback
GPU availability	WebGPU requires a compatible GPU and recent browser	Detect capability; fall back to a WASM CPU path via llama.cpp.wasm
No fine-tuning in-browser	You cannot update model weights at runtime	Use prompt engineering and in-context learning for domain adaptation pmc.ncbi.nlm.nih
Audit logging	HIPAA requires audit trails for ePHI interactions	Log model I/O locally (IndexedDB) or to a HIPAA-compliant log endpoint without transmitting PHI
Hallucination risk	LLMs can confabulate clinical details	Always include a human-in-the-loop review step; never present output as authoritative diagnosis

The Regulatory Landscape

Running an LLM in-browser eliminates many HIPAA data-flow risks, but it does not eliminate regulatory responsibility. Developers building healthcare applications must still address:

FDA SaMD classification: If the application supports diagnostic or treatment decisions, it may qualify as Software as a Medical Device under FDA guidelines
Output disclaimers: All patient-facing AI outputs must clearly communicate that they are not a substitute for professional clinical judgment
Model versioning and audit trails: Regulators expect reproducibility; document which model version and quantization level was used for any given interaction
GDPR (for EU deployments): Even local processing may require a Data Protection Impact Assessment (DPIA) if the data is later synchronized to a server

The Road Ahead

The convergence of WebGPU maturity, aggressive model quantization research, and rising healthcare data breach incidents is accelerating browser-based LLM adoption. Near-term developments to watch include:

LoRA adapter hot-swapping: Fine-tune a small adapter for medical specialties (oncology, radiology, cardiology) that loads on top of a base model at runtime without downloading a new full model
Local RAG (Retrieval-Augmented Generation): Libraries like Voy and Orama enable fully local vector databases in the browser, allowing the model to retrieve from a patient's local record store before generating a response
Multimodal browser inference: Emerging models like LLaVA-Med process images alongside text; running these on-device would enable local radiology image triage.

Use Google Gemini to Illustrate an Entire Book in Minutes

Agbo, Daniel Onuoha — Thu, 02 Apr 2026 17:16:45 +0000

From raw manuscript to fully illustrated book—powered by an AI pipeline.

Introduction

What used to take a full creative team—writers, art directors, illustrators, and editors—can now be executed in minutes with the right AI workflow.

Recent advancements in multimodal AI have made it possible to automatically illustrate an entire book, cover to cover, with remarkable stylistic consistency and visual quality.

This article breaks down a practical, reproducible 5-step pipeline for turning any story into a fully illustrated experience using Gemini.

The Big Idea: AI as a Creative Pipeline

Instead of treating AI as a single tool, this workflow treats it as a collaborative system:

🧠 Text Model → Thinks, analyzes, directs
🎨 Image Model → Executes, renders, visualizes

This separation is the key to achieving coherence at scale.

Step 1: Ingest the Entire Story

Start by feeding the full source material into Gemini:

📘 Full book (PDF / text)
🎧 Or even an audiobook (MP3)

Unlike traditional pipelines, Gemini can process the entire narrative context at once:

Characters
Tone
Themes
World-building details

This holistic understanding becomes the foundation for all downstream outputs.

Step 2: Establish a Cohesive Art Direction

Before generating any images, pause.

Use Gemini’s text model in chat mode to define a global art style:

"Define a consistent visual art style for this story."

Examples:

Futuristic neon cyberpunk
Classic watercolor storybook
Dark gothic realism

Why this matters

Without this step, image generation becomes:

Inconsistent
Fragmented
Visually incoherent

With it, you get:

Unified tone
Strong visual identity
Professional-grade output

Rule: Consistency before creativity.

Step 3: Build a Character Bible

Next, extract and formalize character data.

Prompt Gemini to:

Identify all major characters
Generate detailed physical descriptions
Structure outputs in a reusable format

Example output:

{
  "name": "Amina",
  "age": "mid-20s",
  "appearance": "slim, dark-skinned, braided hair, sharp eyes",
  "clothing": "minimalist desert robes with metallic accents",
  "traits": "resilient, observant"
}

Why this is critical

This becomes your single source of truth for:

Visual consistency
Prompt reuse
Scene accuracy

Every generated image will reference this “character bible.”

Step 4: Generate High-Fidelity Artwork

Now, feed structured prompts into Gemini’s image model.

Because your prompts include:

Defined art style
Structured character descriptions
Context-aware scene details

…the outputs are:

🎯 Highly accurate
🎨 Stylistically consistent
🧩 Narratively aligned

No more:

Random styles
Character inconsistencies
Visual drift

Just clean, production-quality illustrations.

Step 5: Automate Chapter-by-Chapter Illustration

Now scale the process.

For each chapter:

Extract the most important scene
Generate a scene-specific prompt
Reference:

Character bible
Art direction
1. Render the image

This loop transforms your entire book into a fully illustrated experience.

Result

Every chapter gets a custom illustration
All visuals match stylistically
Entire process is automated

The Real Breakthrough: Agentic Workflows

This pipeline demonstrates a broader shift in AI usage:

From tools → to systems

Instead of asking:

“Can AI generate images?”

We now ask:

“Can AI coordinate itself to produce complex creative outputs?”

Architecture

Role	AI Component
Thinking	Text model
Planning	Prompt engineering layer
Execution	Image model

This is what people mean by agentic workflows:

Multi-step
Context-aware
Goal-driven

Practical Considerations

⚠️ Cost

Image generation APIs are not free at scale.

Avoid:

Running massive books blindly
Generating unnecessary variations

Start small:

Test with short stories
Optimize prompts first

⚡ Performance Tips

Cache character descriptions
Reuse prompts aggressively
Batch chapter processing
Validate style early

Getting Started

You can experiment with this workflow using Google’s official Colab notebook:

👉 https://colab.research.google.com/github/google-gemini/cookbook

Final Thoughts

This isn’t just about illustration.

It’s about a new way of building creative systems:

Modular
Automated
Scalable

The real skill isn’t drawing anymore.

It’s designing the pipeline that draws for you.

If you’re building in AI, this is the shift to pay attention to.

Not just what AI can do — but how you chain it together.

Building a CI/CD Pipeline

Agbo, Daniel Onuoha — Sat, 07 Mar 2026 06:00:00 +0000

A Practical Comparison of Jenkins, GitHub Actions, and CircleCI

Continuous Integration and Continuous Deployment (CI/CD) pipelines are now a baseline expectation in professional software development. They automate the repetitive work of building, testing, and deploying code — eliminating the "works on my machine" problem, tightening feedback loops, and reducing the blast radius of any single change.

But the tooling landscape is crowded, and the right choice depends heavily on your team's size, infrastructure preferences, and existing workflow. This guide walks through three of the most widely used options — Jenkins, GitHub Actions, and CircleCI — covering practical setup, real configuration examples, and honest trade-offs for each.

Jenkins: Maximum Flexibility, Maximum Ownership

What It Is

Jenkins has been the workhorse of CI/CD since 2011. It's a self-hosted, open-source automation server with a plugin ecosystem of over 1,800 integrations. Nearly anything you can imagine doing in a pipeline — deploying to Kubernetes, sending Slack alerts, parsing test reports, triggering other jobs — has a Jenkins plugin for it.

The trade-off is that Jenkins requires you to own the infrastructure. You provision the server, manage upgrades, configure agents, and monitor it. For teams with dedicated DevOps capacity or strict data residency requirements, that's acceptable. For smaller teams, it can be a tax.

Installation

Jenkins requires a JDK (Java 11 or 17 recommended) and runs on any major operating system. The quickest way to get started on a Debian/Ubuntu server:

# Install Java
sudo apt update && sudo apt install -y openjdk-17-jdk

# Add the Jenkins package repository and install
curl -fsSL https://pkg.jenkins.io/debian/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian binary/" | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt update && sudo apt install -y jenkins

# Start and enable the service
sudo systemctl start jenkins && sudo systemctl enable jenkins

Jenkins will be available at http://your-server:8080. Retrieve the initial admin password from /var/lib/jenkins/secrets/initialAdminPassword to complete setup.

Defining a Pipeline

Jenkins supports two pipeline syntaxes: Declarative (structured, recommended for most teams) and Scripted (Groovy-based, more powerful but harder to read). Below is a production-style Declarative pipeline for a Maven Java project, including environment variables, parallel test execution, and conditional deployment:

pipeline {
    agent any

    environment {
        DOCKER_IMAGE = "myorg/myapp:${BUILD_NUMBER}"
    }

    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package -DskipTests'
                archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
            }
        }

        stage('Test') {
            parallel {
                stage('Unit Tests') {
                    steps { sh 'mvn test' }
                }
                stage('Integration Tests') {
                    steps { sh 'mvn verify -Pintegration' }
                }
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }

        stage('Build Docker Image') {
            steps {
                sh "docker build -t ${DOCKER_IMAGE} ."
                sh "docker push ${DOCKER_IMAGE}"
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh "./deploy.sh ${DOCKER_IMAGE}"
            }
        }
    }

    post {
        failure {
            slackSend channel: '#deployments',
                      message: "Build FAILED: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
        }
        success {
            slackSend channel: '#deployments',
                      message: "Build succeeded: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
        }
    }
}

A few things worth noting here. The parallel block in the Test stage runs both test suites simultaneously, cutting total pipeline time. The when { branch 'main' } condition means the Deploy stage only fires on merges to main — feature branches build and test without triggering a deployment. The post block handles notifications regardless of how the pipeline ends.

Connecting to Source Control

Rather than configuring Jenkins to poll your repository (inefficient), set up a webhook so GitHub or GitLab pushes events directly to Jenkins:

Install the GitHub plugin in Jenkins (Manage Jenkins → Plugins).
In your GitHub repository, go to Settings → Webhooks → Add webhook.
Set the Payload URL to http://your-jenkins-server/github-webhook/ and choose "Just the push event."
In your Jenkins job, enable "GitHub hook trigger for GITScm polling" under Build Triggers.

Jenkins will now kick off a build within seconds of every push.

When Jenkins Makes Sense

Jenkins is the right call when you need deep customization, have existing infrastructure and DevOps expertise, operate in an air-gapped environment where SaaS tools aren't an option, or are running complex multi-project pipelines where the Scripted DSL's full Groovy power genuinely matters. It's overkill for a small team shipping a web app.

GitHub Actions: Zero-Infrastructure CI/CD for GitHub Teams

What It Is

GitHub Actions is GitHub's native CI/CD platform, launched in 2019. Pipelines are defined as YAML workflow files that live directly in your repository under .github/workflows/. Because GitHub hosts the runner infrastructure, there's nothing to provision or maintain — you commit a file, and your pipeline exists.

The GitHub Marketplace offers thousands of prebuilt Actions for common tasks: checking out code, setting up language runtimes, publishing packages, deploying to cloud providers, sending notifications. Most pipelines are assembled from these building blocks rather than written from scratch.

Workflow Structure

Every workflow file has three core sections: a trigger (on:), one or more jobs, and steps within each job. Here's a complete Node.js workflow with caching, test reporting, and deployment gating:

name: CI/CD

on:
  push:
    branches: [main, "release/**"]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18, 20]   # Test against multiple Node versions

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"               # Cache node_modules between runs

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Run tests
        run: npm test -- --coverage

      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-node-${{ matrix.node-version }}
          path: coverage/

  deploy:
    runs-on: ubuntu-latest
    needs: test                      # Only run if test job passes
    if: github.ref == 'refs/heads/main'   # Only deploy from main

    environment: production          # Requires manual approval if configured

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to production
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: npm run deploy

The matrix strategy runs the test job twice in parallel — once for Node 18 and once for Node 20 — with a single job definition. The needs: test dependency on the deploy job ensures that deployment never happens unless all matrix variants pass. Secrets are stored in your repository's Settings → Secrets and accessed via ${{ secrets.SECRET_NAME }}, never exposed in logs.

Reusable Workflows

For larger organizations maintaining multiple repositories, duplicating workflow files quickly becomes a maintenance burden. GitHub Actions supports reusable workflows — a way to define a workflow once and call it from other repositories:

# .github/workflows/reusable-deploy.yml (in a central "platform" repo)
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      deploy-token:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to ${{ inputs.environment }}"
      # ... deployment steps

# In any other repository's workflow
jobs:
  call-deploy:
    uses: myorg/platform/.github/workflows/reusable-deploy.yml@main
    with:
      environment: production
    secrets:
      deploy-token: ${{ secrets.DEPLOY_TOKEN }}

When GitHub Actions Makes Sense

If your codebase already lives on GitHub, GitHub Actions is the most natural choice for most teams. Setup is minimal, the YAML syntax is readable, and tight integration with pull requests (surfacing test status directly on PRs, requiring checks to pass before merging) is genuinely useful. Its main constraints are that it's GitHub-only and the free tier's monthly minutes can run out on active projects.

CircleCI: Speed-Optimized Cloud-Native Pipelines

What It Is

CircleCI is a dedicated CI/CD platform with a reputation for fast build times and sophisticated caching. Unlike Jenkins (which you host) or GitHub Actions (which is tied to GitHub), CircleCI connects to GitHub, GitLab, or Bitbucket and can be run either on CircleCI's cloud infrastructure or on self-hosted runners. It occupies a middle ground: managed infrastructure with more portability than GitHub Actions.

CircleCI's configuration lives in .circleci/config.yml at the root of your repository. Its key differentiators are granular caching, an Orbs system (reusable configuration packages), and first-class support for complex job dependency graphs.

Defining a Pipeline

Here's a production-style CircleCI config for a Node.js application, demonstrating Docker executor selection, layer caching, workspace sharing between jobs, and conditional deployment:

version: 2.1

orbs:
  node: circleci/node@5.1.0   # Use the official Node.js orb

jobs:
  build-and-test:
    docker:
      - image: cimg/node:20.10
      - image: cimg/postgres:15.2    # Spin up a test database alongside the app
        environment:
          POSTGRES_USER: testuser
          POSTGRES_DB: testdb

    steps:
      - checkout

      - node/install-packages:       # Orb step with built-in caching
          pkg-manager: npm

      - run:
          name: Run linter
          command: npm run lint

      - run:
          name: Run tests
          command: npm test
          environment:
            DATABASE_URL: postgresql://testuser@localhost/testdb

      - store_test_results:
          path: test-results/        # Enables test insights in CircleCI dashboard

      - store_artifacts:
          path: coverage/

      - persist_to_workspace:        # Share build artifacts with the deploy job
          root: .
          paths: [dist/]

  deploy:
    docker:
      - image: cimg/node:20.10
    steps:
      - attach_workspace:            # Retrieve artifacts from build-and-test
          at: .

      - run:
          name: Deploy to production
          command: npm run deploy

workflows:
  ci-cd:
    jobs:
      - build-and-test
      - deploy:
          requires:
            - build-and-test
          filters:
            branches:
              only: main             # Only deploy from main branch

A few things to highlight here. Spinning up a Postgres service container alongside the application container is a clean pattern for integration testing — CircleCI handles the networking automatically. The persist_to_workspace and attach_workspace steps pass build artifacts (the compiled dist/ folder) from the build job to the deploy job without redundant recompilation. store_test_results parses JUnit XML output and surfaces test trends in the CircleCI dashboard.

Advanced Caching

CircleCI's caching system is more explicit than GitHub Actions' built-in caching, which gives you finer control. You define cache keys based on file hashes, falling back to progressively less-specific keys:

- restore_cache:
    keys:
      - node-deps-v1-{{ checksum "package-lock.json" }}  # Exact match
      - node-deps-v1-                                     # Fallback: any recent cache

- run: npm ci

- save_cache:
    key: node-deps-v1-{{ checksum "package-lock.json" }}
    paths:
      - ~/.npm

If your package-lock.json hasn't changed, the exact-match key hits and npm ci completes in seconds. If it has changed, CircleCI falls back to the most recent partial match, and only the changed packages need to be downloaded.

When CircleCI Makes Sense

CircleCI is a strong choice when you need cross-platform VCS support (GitHub + GitLab + Bitbucket from one tool), want more granular caching control than GitHub Actions provides, or need self-hosted runners without the operational overhead of Jenkins. It's particularly well-suited to data-intensive or compute-heavy pipelines where build time is a genuine bottleneck.

Side-by-Side Comparison

	Jenkins	GitHub Actions	CircleCI
Hosting	Self-managed	GitHub-managed	Cloud or self-hosted
VCS Support	Any	GitHub only	GitHub, GitLab, Bitbucket
Config format	Groovy DSL	YAML	YAML
Setup effort	High	Minimal	Low
Customization	Unlimited	Medium	High
Plugin/Orb ecosystem	1,800+ plugins	Thousands of Actions	Orbs library
Parallelism	Yes (with agents)	Matrix + parallel jobs	Built-in
Caching	Plugin-dependent	Built-in	First-class, explicit
Cost	Free (infrastructure not included)	Free tier with limits	Free tier; paid plans
Best for	Enterprises, complex pipelines, air-gapped environments	GitHub-hosted projects, small to mid-size teams	Speed-sensitive workloads, multi-VCS organizations

Choosing the Right Tool

All three tools can build, test, and deploy virtually any application stack. The decision comes down to context.

If your team lives in GitHub and values low operational overhead, GitHub Actions is the obvious default. You get solid CI/CD for nearly any project with nothing to configure beyond a YAML file.

If your organization has complex infrastructure requirements, heterogeneous tooling, strict compliance constraints, or genuinely complicated pipeline logic, Jenkins remains the most powerful and customizable option — as long as someone is willing to own it.

If you want managed infrastructure with more flexibility than GitHub Actions and you need to support multiple Git hosting providers, CircleCI is worth a close look. Its caching and Orbs system produce reliably fast builds with relatively little configuration.

The pipelines you build with any of these tools are living infrastructure. They'll need to evolve as your system grows. Pick the tool your team will actually maintain — and start simple.

Firestore's New Query Engine

Agbo, Daniel Onuoha — Wed, 04 Mar 2026 06:00:00 +0000

Firestore's new query engine, introduced in January 2026, brings a powerful and expressive way to query and transform data server-side. This guide walks through setup, core concepts, and real-world implementation patterns.

Prerequisites and Setup

Pipeline operations are available exclusively on Firestore Enterprise edition. If your project currently uses a Standard edition database, you'll need to create a new database — in-place upgrades are not supported.

Step 1: Create a Firestore Enterprise Database

From the Google Cloud console or Firebase console:

Navigate to Firestore → Databases → Create Database
Select Enterprise edition and choose Native mode
Pick a region and click Create

Your new Enterprise database will have its own database ID (e.g., (enterprise-default) or a custom name).

Step 2: Update Your SDKs

Pipeline operations require the latest versions of the Firestore SDKs. Update your dependencies:

# Web / Node.js
npm install firebase@latest

# Admin SDK (Node.js)
npm install firebase-admin@latest

# Python
pip install google-cloud-firestore --upgrade

Pipeline operations are currently available on Android, iOS, Web, and Admin SDKs. Flutter, Unity, and C++ support is forthcoming.

Step 3: Connect to the Enterprise Database

When initializing your client, specify the Enterprise database ID explicitly:

// Web SDK
import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

const app = initializeApp(firebaseConfig);
const db = getFirestore(app, "your-enterprise-db-id");

// Admin SDK (Node.js)
import { initializeApp, cert } from "firebase-admin/app";
import { getFirestore } from "firebase-admin/firestore";

const app = initializeApp({ credential: cert(serviceAccount) });
const db = getFirestore(app, "your-enterprise-db-id");

# Python (Admin SDK)
import firebase_admin
from firebase_admin import firestore

app = firebase_admin.initialize_app()
db = firestore.client(database_id="your-enterprise-db-id")

Important: Calling .pipeline() against a Standard edition database throws a server error. Always ensure you're connected to an Enterprise database before using pipeline APIs.

Core Concepts: Stages, Expressions, and Functions

Before writing pipeline queries, it helps to understand the three building blocks:

Stages are the sequential steps of a pipeline. Each stage receives a stream of documents, transforms it in some way, and passes the result to the next stage. Common stages include collection(), where(), select(), aggregate(), group(), unnest(), sort(), limit(), and sample().

Expressions are used within stages to reference fields or constants. Because pipelines distinguish between a field reference and a literal value, you must be explicit:

import { field, constant } from "firebase/firestore";

// "name" refers to the document field named "name"
field("name").equal(constant("Toronto"))

// Without constant(), a bare string would be ambiguous

Functions are higher-level operations built on expressions — things like countAll(), sum(), avg(), min(), max(), substring(), regex_match(), and array_contains_all().

Your First Pipeline Query

The simplest pipeline mirrors a standard Firestore query. Here is how a traditional query translates to a pipeline:

// Traditional query
const query = db.collection("cities")
  .where("population", ">", 100000)
  .orderBy("name")
  .limit(10);

// Equivalent pipeline
import { field, constant } from "firebase/firestore";

const pipeline = db.pipeline()
  .collection("cities")
  .where(field("population").greaterThan(constant(100000)))
  .sort(field("name").ascending())
  .limit(10);

const snapshot = await pipeline.execute();
snapshot.forEach(doc => console.log(doc.id, doc.data()));

You can also convert an existing query object directly into a pipeline, which is useful when incrementally migrating:

// Start from an existing query, then extend it with pipeline stages
const existingQuery = db.collection("recipes").where("authorId", "==", userId);
const pipeline = existingQuery.pipeline()
  .sort(field("createdAt").descending())
  .limit(20);

Filtering and Projection

Filtering with `where()`

The where() stage in pipelines supports a much richer set of operators than the Standard edition, including regex_match, array_contains_all, and comparisons across computed values.

// Find cities with populations between 500,000 and 5,000,000
const pipeline = db.pipeline()
  .collection("cities")
  .where(
    field("population").greaterThan(constant(500000))
      .and(field("population").lessThan(constant(5000000)))
  );

# Python equivalent
from google.cloud.firestore_v1.pipeline_expressions import Field, Constant

pipeline = (
    db.pipeline()
    .collection("cities")
    .where(
        Field.of("population").greater_than(Constant.of(500000))
        .and_(Field.of("population").less_than(Constant.of(5000000)))
    )
)

Projecting Fields with `select()`

By default, Firestore returns all fields in a document. Using select() restricts the response to only the fields your application needs, reducing network egress and latency:

const pipeline = db.pipeline()
  .collection("users")
  .where(field("active").equal(constant(true)))
  .select("displayName", "email", "lastLogin");

You can also add computed fields to the projection:

import { field, add } from "firebase/firestore";

const pipeline = db.pipeline()
  .collection("orders")
  .select(
    "orderId",
    "subtotal",
    add(field("subtotal"), field("shippingFee")).as("totalDue")
  );

Aggregations and Grouping

This is where pipelines become genuinely powerful. Standard edition queries can count documents, but pipelines can compute arbitrary aggregations — sums, averages, min/max — across the entire collection or within groups.

Global Aggregation

import { countAll, sum, avg } from "firebase/firestore";

// Total orders, total revenue, and average order value
const pipeline = db.pipeline()
  .collection("orders")
  .where(field("status").equal(constant("completed")))
  .aggregate(
    countAll().as("totalOrders"),
    sum(field("amount")).as("totalRevenue"),
    avg(field("amount")).as("avgOrderValue")
  );

const snapshot = await pipeline.execute();
const stats = snapshot.docs[0].data();
console.log(`${stats.totalOrders} orders, $${stats.totalRevenue} revenue`);

Grouped Aggregation

The group() stage lets you aggregate within buckets. Think GROUP BY in SQL:

// Revenue and order count broken down by product category
const pipeline = db.pipeline()
  .collection("orders")
  .group(
    { category: field("category") },
    {
      orderCount: countAll(),
      revenue: sum(field("amount"))
    }
  )
  .sort(field("revenue").descending());

# Python equivalent
from google.cloud.firestore_v1.pipeline_expressions import Field
from google.cloud.firestore_v1.pipeline_stages import Accumulator

pipeline = (
    db.pipeline()
    .collection("orders")
    .group(
        groups=["category"],
        accumulators=[
            Accumulator.count_all().alias("orderCount"),
            Accumulator.sum(Field.of("amount")).alias("revenue"),
        ]
    )
    .sort(Field.of("revenue").descending())
)

Unnesting Arrays

One of the most-requested capabilities missing from Standard edition was the ability to work with array fields inside a query. The unnest() stage explodes an array field into individual rows, one per element, allowing per-element filtering and aggregation.

Finding Trending Hashtags

Consider a recipe app where each document has a tags array. To find the most-used tags across all recipes, you'd previously have had to maintain a separate aggregation collection. With pipelines:

import { countAll, field } from "firebase/firestore";

const pipeline = db.pipeline()
  .collection("recipes")
  .unnest(field("tags").as("tag"))           // Explode the tags array
  .aggregate({
    accumulators: [countAll().as("tagCount")],
    groups: ["tag"]
  })
  .sort(field("tagCount").descending())
  .limit(10)
  .execute();

const snapshot = await pipeline;
snapshot.forEach(doc => {
  const { tag, tagCount } = doc.data();
  console.log(`#${tag}: ${tagCount} recipes`);
});

Filtering on Array Element Values

After unnesting, you can filter on the unnested values just like any other field:

// Find all recipes that have been tagged with vegetarian-friendly tags
const pipeline = db.pipeline()
  .collection("recipes")
  .unnest(field("ingredients").as("ingredient"))
  .where(field("ingredient.allergen").equal(constant(true)))
  .group(
    { recipeId: field("__name__"), title: field("title") },
    { allergenCount: countAll() }
  )
  .where(field("allergenCount").greaterThan(constant(0)));

String Operations

Pipelines expose full string matching capabilities, including substring search and regular expressions — both previously impossible without application-layer processing.

Substring Search

import { field, substring } from "firebase/firestore";

// Find products whose names contain "wireless" (case-insensitive)
const pipeline = db.pipeline()
  .collection("products")
  .where(
    field("name").lower().contains(constant("wireless"))
  );

Regex Matching

import { regexMatch } from "firebase/firestore";

// Find users whose emails are from a corporate domain
const pipeline = db.pipeline()
  .collection("users")
  .where(
    regexMatch(field("email"), constant("^[^@]+@(acme|globex)\\.com$"))
  );

# Python equivalent
from google.cloud.firestore_v1.pipeline_expressions import Field, Function

pipeline = (
    db.pipeline()
    .collection("users")
    .where(
        Function.regex_match(Field.of("email"), "^[^@]+@(acme|globex)\\.com$")
    )
)

Chaining Stages: A Real-World Example

The real power of pipelines comes from chaining stages together. Here is a complete example: a leaderboard query for a game app that computes player stats, filters by tier, and returns a ranked top-ten.

import { field, constant, sum, avg, countAll } from "firebase/firestore";

const pipeline = db.pipeline()
  .collection("gameEvents")
  .where(field("eventType").equal(constant("match_completed")))
  .group(
    { playerId: field("playerId"), username: field("username") },
    {
      totalWins:   sum(field("won")),        // won is 0 or 1
      totalGames:  countAll(),
      avgScore:    avg(field("score"))
    }
  )
  // Compute win rate as a projected field
  .select(
    "playerId",
    "username",
    "totalWins",
    "totalGames",
    "avgScore",
    field("totalWins").divide(field("totalGames")).as("winRate")
  )
  // Only include players who've played at least 10 games
  .where(field("totalGames").greaterThanOrEqual(constant(10)))
  .sort(field("winRate").descending(), field("avgScore").descending())
  .limit(10);

const snapshot = await pipeline.execute();

Notice the filter on totalGames coming after the aggregation. This kind of post-aggregation filtering — equivalent to HAVING in SQL — was completely impossible in Standard edition.

Sampling Documents

Enterprise edition also adds a sample() stage, useful for analytics, ML training data preparation, or testing on a subset of production data:

// Return 100 random documents from the collection
const pipeline = db.pipeline()
  .collection("events")
  .sample(100);

// Or sample by percentage (each document has a 10% chance of being returned)
const pipeline = db.pipeline()
  .database()
  .sample({ percent: 0.1 });

Query Explain: Diagnosing Performance

Because the Enterprise edition uses optional indexing, understanding whether your query is hitting an index or falling back to a full table scan is critical. The explain() API surfaces this information.

Analyzing a Query Without Executing It

// Get the query plan only (dry run)
const explainResult = await pipeline.explain({ analyze: false });
console.log(explainResult.stats);
// → { resultsReturned: 0, executionDuration: null, indexesUsed: [...] }

Running with Full Profiling

// Execute the query and capture execution metrics
const snapshot = await pipeline.explain({ analyze: true });
console.log(snapshot.explainMetrics);
// → {
//     planSummary: { indexesUsed: [{ properties: "category ASC, revenue ASC" }] },
//     executionStats: { resultsReturned: 42, executionDuration: "0.05s", readOperations: 42 }
//   }

If indexesUsed is empty, your query is doing a collection scan. That's fine for small collections or development, but for production workloads you'll want to create a supporting index.

Creating an Index

Once Query Explain tells you which fields a query is filtering and sorting on, create the supporting index via the Firebase console, the CLI, or the Firestore API. For Pipeline operations, the recommended index field order is:

Equality filter fields (in any order)
Sort fields (in the same order as your sort() stage)
Range/inequality filter fields

# Using Firebase CLI
firebase firestore:indexes
# Add index definition to firestore.indexes.json and deploy
firebase deploy --only firestore:indexes

Input Stages: More Than Just Collections

Most queries start with .collection(), but pipelines also support two additional input modes:

// Query all documents in the entire database
const pipeline = db.pipeline()
  .database()
  .where(field("status").equal(constant("flagged")));

// Query a specific set of document references
const pipeline = db.pipeline()
  .documents([
    db.collection("users").doc("user_1"),
    db.collection("users").doc("user_2"),
    db.collection("users").doc("user_3")
  ])
  .select("displayName", "email");

The database() input is powerful for cross-collection analytics but will be slow without appropriate indexing. Use it carefully in production.

Known Limitations in Preview

As of early 2026, Pipeline operations are in Preview status. A few constraints to be aware of:

No real-time listeners. The onSnapshot() API is not yet supported for pipeline queries. If you need live updates, you must use Standard edition Core operations for those use cases. Mixing pipelines (for complex one-time reads) and Core operations (for real-time sync) in the same application is a valid architecture.

No local emulator support. The Firestore emulator does not yet execute pipeline queries, which complicates local testing. One workaround is to maintain a separate test Enterprise database in the cloud and run integration tests against it.

Array-contains and vector search indexes are not yet supported. If your pipeline uses array_contains or find_nearest expressions, Firestore will fall back to ascending/descending indexes as a substitute. Performance may lag for these specific operations compared to Standard edition equivalents. Google has flagged this as an area being actively improved.

Migration Notes

If you're moving data from an existing Standard edition database:

Export your Standard database to Cloud Storage using Firestore's managed export feature.
Import the exported data into your new Enterprise database.
Recreate security rules and indexes manually — they do not transfer automatically.
Update client code to point at the new database ID.
Use pipelines for new query patterns; Core operations remain available for real-time sync.

Summary

Firestore Pipeline operations give developers a genuinely expressive server-side query language — one that handles aggregations, array unnesting, string matching, computed fields, and post-aggregation filtering without pushing data into application code first. The key steps to get started are: create an Enterprise edition database, update your SDKs, connect using the Enterprise database ID, and begin chaining .pipeline() stages. Use Query Explain early to understand your index needs, and keep an eye on the preview limitations, particularly around real-time listeners, before committing to a full migration.

Testing React Server Components in Next.js

Agbo, Daniel Onuoha — Sat, 28 Feb 2026 06:00:00 +0000

React Server Components (RSC) represent a meaningful shift in how React applications are structured. By moving rendering to the server, they eliminate unnecessary client-side JavaScript, enable direct data access without an API layer, and improve both performance and SEO. Next.js embraces this model fully — in the app directory, every component is a server component by default.

The tradeoff is that testing becomes more involved. The same server-side nature that makes RSCs powerful also makes them incompatible with the client-side testing tools most React developers reach for first. This article walks through what you need to know: the unique challenges RSCs pose for testing, how to configure your environment, and how to write tests that actually reflect how your components behave in production.

Understanding React Server Components

Before writing tests, it helps to understand what distinguishes RSCs from client components:

No client-side state or lifecycle methods. RSCs cannot use useState, useEffect, or any other hook that depends on the browser environment.
Direct server-side data access. They can await database queries, file reads, or fetch calls at the top level — no useEffect-based data fetching required.
Zero client-side JavaScript output. The component's logic stays on the server; only the resulting HTML is sent to the browser.

In Next.js's app directory, a component is a server component unless it explicitly includes the 'use client' directive. This means the majority of your component tree — layouts, pages, and most data-fetching components — will be RSCs.

Why Testing RSCs Is Different

Standard React testing tools like @testing-library/react work by mounting components in a jsdom environment that simulates the browser. RSCs don't run in the browser, so jsdom isn't the right environment. Trying to render an RSC with the standard render function will either fail outright or produce misleading results.

The specific challenges to plan for:

Server context. RSCs may depend on server-only APIs — cookies(), headers(), or direct database access — that don't exist in a test environment without explicit mocking.

Async rendering. Unlike class components or hooks-based components, RSCs are async functions that return JSX. This affects how you render and assert in tests.

Next.js-specific APIs. Functions like next/navigation's redirect() or notFound(), and the next/headers module, need to be mocked to avoid errors in tests.

Tools and Setup

Dependencies

npm install --save-dev jest @testing-library/react @testing-library/jest-dom msw

For TypeScript projects, also install ts-jest and @types/jest.

Jest Configuration

Use the node test environment, not jsdom, since RSCs run on the server:

// jest.config.js
module.exports = {
  testEnvironment: 'node',
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1',
  },
  setupFilesAfterFramework: ['<rootDir>/jest.setup.js'],
};

// jest.setup.js
import '@testing-library/jest-dom';

Mocking Next.js Server APIs

Several Next.js modules need to be mocked to prevent test failures. Create a __mocks__ directory at the project root:

// __mocks__/next/headers.js
export const cookies = jest.fn(() => ({
  get: jest.fn(),
  set: jest.fn(),
}));

export const headers = jest.fn(() => new Headers());

// __mocks__/next/navigation.js
export const redirect = jest.fn();
export const notFound = jest.fn();
export const useRouter = jest.fn(() => ({
  push: jest.fn(),
  replace: jest.fn(),
}));

Writing Tests for RSCs

The Component Under Test

Here's a straightforward RSC that fetches and displays a list of users:

// app/components/UserList.js
export default async function UserList() {
  const res = await fetch('https://jsonplaceholder.typicode.com/users');
  const users = await res.json();

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

Rendering RSCs in Tests

Because RSCs are async functions, you need to await them before passing the result to a renderer. Use renderToString from react-dom/server to produce the HTML output:

import React from 'react';
import { renderToString } from 'react-dom/server';
import UserList from '@/components/UserList';

// Mock the global fetch
global.fetch = jest.fn(() =>
  Promise.resolve({
    json: () =>
      Promise.resolve([
        { id: 1, name: 'John Doe' },
        { id: 2, name: 'Jane Smith' },
      ]),
  })
);

describe('UserList', () => {
  beforeEach(() => {
    jest.clearAllMocks();
  });

  it('renders a list of users', async () => {
    const component = await UserList();
    const html = renderToString(component);

    expect(html).toContain('John Doe');
    expect(html).toContain('Jane Smith');
  });

  it('fetches data from the correct endpoint', async () => {
    await UserList();
    expect(fetch).toHaveBeenCalledWith(
      'https://jsonplaceholder.typicode.com/users'
    );
  });

  it('renders the correct number of items', async () => {
    const component = await UserList();
    const html = renderToString(component);
    const listItems = (html.match(/<li/g) || []).length;

    expect(listItems).toBe(2);
  });
});

Why await UserList() instead of render(<UserList />)? Calling the component as an async function gives you its resolved output before rendering, which is necessary because React's current test renderer doesn't handle top-level async components. This pattern will become simpler as tooling catches up with the RSC spec.

Using MSW for Complex API Scenarios

For more realistic API mocking — multiple endpoints, error states, network delays — MSW is more maintainable than manually stubbing fetch:

// tests/mocks/handlers.js
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.get('https://jsonplaceholder.typicode.com/users', () => {
    return HttpResponse.json([
      { id: 1, name: 'John Doe' },
      { id: 2, name: 'Jane Smith' },
    ]);
  }),
];

// tests/mocks/server.js
import { setupServer } from 'msw/node';
import { handlers } from './handlers';

export const server = setupServer(...handlers);

// jest.setup.js (updated)
import { server } from './tests/mocks/server';

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

With this setup, your tests interact with realistic mock responses, and you can override handlers per-test to simulate errors or edge cases:

it('handles API errors gracefully', async () => {
  server.use(
    http.get('https://jsonplaceholder.typicode.com/users', () => {
      return new HttpResponse(null, { status: 500 });
    })
  );

  await expect(UserList()).rejects.toThrow();
});

Testing Components That Use Next.js Server APIs

When a component reads from cookies or headers, use the mocks you created earlier:

// app/components/AuthenticatedGreeting.js
import { cookies } from 'next/headers';

export default async function AuthenticatedGreeting() {
  const cookieStore = cookies();
  const session = cookieStore.get('session-token');

  if (!session) return <p>Please log in.</p>;
  return <p>Welcome back!</p>;
}

import { cookies } from 'next/headers';
import AuthenticatedGreeting from '@/components/AuthenticatedGreeting';
import { renderToString } from 'react-dom/server';

jest.mock('next/headers');

describe('AuthenticatedGreeting', () => {
  it('shows login prompt when no session exists', async () => {
    cookies.mockReturnValue({ get: jest.fn(() => null) });

    const component = await AuthenticatedGreeting();
    const html = renderToString(component);

    expect(html).toContain('Please log in.');
  });

  it('shows welcome message when session exists', async () => {
    cookies.mockReturnValue({
      get: jest.fn(() => ({ value: 'valid-token' })),
    });

    const component = await AuthenticatedGreeting();
    const html = renderToString(component);

    expect(html).toContain('Welcome back!');
  });
});

Debugging Common Issues

window is not defined
Your test environment is set to jsdom instead of node. Update jest.config.js to use testEnvironment: 'node'.

Cannot read properties of undefined on Next.js imports
A Next.js module (most commonly next/headers or next/navigation) isn't mocked. Add it to your __mocks__ directory or use jest.mock() at the top of the test file.

Async component not rendering correctly
Make sure you're awaiting the component call before passing it to renderToString. The pattern is const component = await MyComponent(props) followed by renderToString(component).

Fetch mock not being called
Check that global.fetch is assigned before the component runs. Define it in beforeEach or at the top of the describe block rather than outside all tests.

Tests passing locally but failing in CI
Server-side tests can be sensitive to environment variables. Ensure any .env.local values your components depend on are also available in the CI environment, or mock them explicitly.

What to Test (and What to Skip)

Not everything in an RSC needs a dedicated unit test. A practical breakdown:

Worth testing: Data transformation logic, conditional rendering based on fetched data or server state, error and loading states, correct API calls being made.

Better handled by integration or E2E tests: The full rendering pipeline, layout composition, routing behavior, and anything that requires a real Next.js server to be running.

Tools like Playwright or Cypress are better suited for end-to-end scenarios. Keep your Jest unit tests focused on the component's logic in isolation.

Conclusion

Testing React Server Components isn't dramatically harder than testing client components — it just requires different tools and a different mental model. The key shifts are using a node test environment instead of jsdom, calling async components directly rather than using render(), and mocking Next.js's server APIs explicitly.

As the ecosystem matures, expect this process to get smoother. The Next.js team and the React core team are actively working on better testing primitives for RSCs. For now, the patterns in this article give you a reliable foundation that covers the most common scenarios without requiring complex infrastructure.

For further reading, see the Next.js testing documentation and the MSW documentation.

Exploring Next.js advanced routing and beyond

Agbo, Daniel Onuoha — Wed, 25 Feb 2026 17:49:47 +0000

Routing is the backbone of any modern web application. Get it right, and users navigate fluidly through your content. Get it wrong, and you're fighting sluggish transitions, tangled layouts, and brittle URL structures. Next.js offers one of the most flexible routing systems in the React ecosystem — but taking full advantage of it requires understanding the patterns that go beyond a basic pages/index.js.

This article covers the techniques that matter most: dynamic routing, nested layouts, advanced navigation patterns, and the middleware layer that ties them together.

1. Dynamic Routing and Route Matching

Dynamic routing lets you create a single file that handles an entire class of URLs. A blog where each post has a unique slug is the classic example — rather than creating a separate file for every post, you define one route using square brackets.

Note on router versions: The examples below use the pages directory and next/router. If you're using the app directory (Next.js 13+), replace useRouter from next/router with useParams from next/navigation.

Creating Dynamic Routes

// pages/blog/[slug].js
import { useRouter } from 'next/router';

const BlogPost = () => {
  const { slug } = useRouter().query;
  return <h1>Blog Post: {slug}</h1>;
};

export default BlogPost;

This maps any URL matching /blog/* — such as /blog/my-first-post — to the BlogPost component, passing the matched segment as slug via the query object.

Handling Multiple Dynamic Segments

For more structured content hierarchies, nest dynamic segments:

// pages/blog/[category]/[slug].js
const BlogCategoryPost = () => {
  const { category, slug } = useRouter().query;
  return (
    <div>
      <h1>Category: {category}</h1>
      <h2>Post: {slug}</h2>
    </div>
  );
};

export default BlogCategoryPost;

This supports URLs like /blog/tech/nextjs-advanced-routing.

Catch-All Routes

When you need to match an arbitrary number of path segments — for example, a documentation site with deeply nested pages — use the spread syntax inside brackets:

// pages/docs/[...slug].js
const DocsPage = () => {
  const { slug } = useRouter().query;
  // slug is an array: ['guide', 'installation', 'windows']
  return <h1>Docs: {slug?.join(' / ')}</h1>;
};

Use [[...slug]].js (double brackets) to also match the root path /docs.

Optimizing Route Transitions

next/link handles client-side navigation and automatically prefetches linked pages in the background, so subsequent loads feel instant:

import Link from 'next/link';

const BlogList = ({ posts }) => (
  <ul>
    {posts.map((post) => (
      <li key={post.slug}>
        <Link href={`/blog/${post.slug}`}>{post.title}</Link>
      </li>
    ))}
  </ul>
);

For cases like filtering or pagination — where you want to update the URL without triggering a full navigation — use shallow routing:

router.push('/blog?page=2', undefined, { shallow: true });

Dynamic API Routes

Dynamic segments work identically in API routes:

// pages/api/blog/[slug].js
export default function handler(req, res) {
  const { slug } = req.query;
  res.status(200).json({ message: `Data for blog post: ${slug}` });
}

This endpoint is accessible at /api/blog/my-first-post and follows the same file-based convention as page routes.

2. Nested Layouts and Shared Components

The app directory, introduced in Next.js 13, makes layout composition a first-class feature. Instead of manually wrapping pages in providers and shell components, you colocate layout files with the routes they govern.

Defining Nested Layouts

Layout files wrap their subtree automatically. A root layout provides the outer shell; a section-specific layout adds structure for that section only:

// app/layout.js
export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <header>My App Header</header>
        {children}
        <footer>My App Footer</footer>
      </body>
    </html>
  );
}

// app/blog/layout.js
export default function BlogLayout({ children }) {
  return (
    <div className="blog-container">
      <aside>Blog Sidebar</aside>
      <main>{children}</main>
    </div>
  );
}

When a user visits /blog/my-post, Next.js renders the root header and footer around the blog sidebar and the post content — with no manual wrapping required. Only the content that changes between navigations re-renders, which reduces unnecessary layout re-renders and improves performance.

Managing Shared State

For state that needs to cross layout boundaries, React context is a clean solution for small to medium applications:

// components/ThemeProvider.js
'use client';
import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext();

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

export const useTheme = () => useContext(ThemeContext);

Note the 'use client' directive — any component using hooks or browser APIs must opt into client-side rendering within the app directory.

As your app scales, frequent context updates can trigger re-renders across deeply nested components. When that becomes a problem, libraries like Zustand or Redux offer more granular control.

Metadata

The app directory also provides a clean API for defining page metadata without a separate <Head> component:

// app/blog/layout.js
export const metadata = {
  title: 'Blog — My App',
  description: 'Read the latest posts on our blog.',
};

Next.js merges metadata from nested layouts and pages automatically, with child values overriding parents.

3. Advanced Navigation Patterns

Programmatic Navigation

The useRouter hook (or useRouter from next/navigation in the app directory) enables navigation triggered by user interactions or application logic:

import { useRouter } from 'next/router';

const NavigateButton = () => {
  const router = useRouter();
  return (
    <button onClick={() => router.push('/dashboard')}>
      Go to Dashboard
    </button>
  );
};

Use router.replace instead of router.push when you don't want the navigation to add an entry to the browser history — useful for redirects after form submission.

Scroll Restoration

By default, Next.js scrolls to the top on each navigation. To restore a user's previous scroll position when they navigate back, enable scroll restoration in next.config.js:

module.exports = {
  experimental: {
    scrollRestoration: true,
  },
};

This is especially valuable in content-heavy applications — news feeds, search results, long-form article lists — where losing scroll position forces users to re-find their place.

Optimized Preloading

next/link prefetches in-viewport links automatically. For routes the user is very likely to visit next but that aren't yet on screen, you can trigger prefetching programmatically:

import { useEffect } from 'react';
import Router from 'next/router';

const HomePage = () => {
  useEffect(() => {
    Router.prefetch('/dashboard');
  }, []);

  return <h1>Welcome</h1>;
};

Be selective here. Prefetching every possible route increases memory usage and can degrade overall performance. Focus on routes that appear immediately after the user's current step — the next page in an onboarding flow, for instance, or the most commonly clicked item in a navigation menu.

Middleware for Access Control

Middleware runs before a request reaches its route handler, making it the right place to enforce authentication, role-based access, or feature flags without touching individual page components:

// middleware.js
export function middleware(req) {
  const token = req.cookies.get('auth-token');
  if (!token) {
    return Response.redirect(new URL('/login', req.url));
  }
}

export const config = {
  matcher: ['/dashboard/:path*'],
};

The matcher config limits the middleware to specific paths, so it doesn't run on every request. For more complex scenarios, you can inspect the token to check roles and redirect to different destinations based on permissions.

Recommended Folder Structure

As your routing logic grows, keeping the project organized becomes critical. Here's a structure that accommodates all the patterns above:

/nextjs-advanced-routing
├── /app
│   ├── layout.js               # Root layout
│   └── /blog
│       ├── layout.js           # Blog-specific layout
│       └── page.js
├── /pages
│   ├── /blog
│   │   ├── [slug].js           # Dynamic route
│   │   └── /[category]
│   │       └── [slug].js       # Nested dynamic route
│   └── /api
│       └── /blog
│           └── [slug].js       # Dynamic API route
├── /components
│   ├── BlogList.js
│   └── ThemeProvider.js
├── middleware.js
├── next.config.js
└── package.json

Conclusion

Next.js routing is powerful precisely because it scales with your application. You can start with a handful of static pages and gradually introduce dynamic segments, nested layouts, and middleware as complexity demands — without restructuring what you've already built.

The patterns covered here — dynamic and catch-all routes, layout composition, scroll restoration, selective prefetching, and middleware-based access control — address the most common challenges you'll encounter as a Next.js application matures. Master these, and you'll have a routing layer that's both flexible enough to handle edge cases and structured enough to stay maintainable as your team and codebase grow.

What Kubernetes Is Really Costing Your Team

Agbo, Daniel Onuoha — Mon, 23 Feb 2026 19:40:56 +0000

The hidden cost of managing your own infrastructure stack is no longer just time — it's competitive velocity.

Introduction

For much of the past decade, the rise of cloud computing promised to free engineering teams from the burden of managing physical hardware. And it delivered — to a point. What replaced on-premise server racks was a new layer of complexity: virtual machines, container orchestration, CI/CD pipelines, identity and access management, networking policies, secrets management, and observability stacks. The tools became more powerful, but they also became harder to master.

Today, many product engineering teams find themselves spending a disproportionate share of their time not shipping features, but maintaining the infrastructure that features run on. This article examines the core challenges teams face managing modern infrastructure — particularly around CI/CD and Kubernetes — and explores how a new generation of internal developer platforms (IDPs) and managed platforms are helping organizations reclaim their focus on building software.

The Infrastructure Complexity Trap

Kubernetes: Power at a Price

Kubernetes has become the de facto standard for container orchestration, and for good reason. It offers powerful primitives for scaling workloads, managing deployments, handling service discovery, and ensuring resilience. But Kubernetes is not a product — it is a platform for building platforms. That distinction matters enormously.

A production-grade Kubernetes environment is rarely "just Kubernetes." It requires teams to make dozens of architectural decisions and manage just as many operational concerns:

Cluster provisioning and lifecycle management involves choosing between managed Kubernetes services (EKS, GKE, AKS) or self-hosted distributions, handling node pool configurations, and managing cluster upgrades — which themselves carry risk and require careful planning.

Networking demands understanding of CNI plugins, ingress controllers, service meshes (Istio, Linkerd, Cilium), network policies, and how traffic is routed both inside and outside the cluster. A misconfigured network policy can silently break inter-service communication or expose services unintentionally.

Storage requires decisions about storage classes, persistent volume provisioning, dynamic vs. static allocation, and data backup strategies — all of which vary across cloud providers.

Security involves RBAC policies, pod security standards, admission controllers, secrets management (Vault, Sealed Secrets, External Secrets Operator), image scanning, and runtime threat detection. Security in Kubernetes is not a checkbox — it is a continuous practice.

Observability means deploying and maintaining a stack of tools: Prometheus for metrics, Grafana for dashboards, Loki or Elasticsearch for logs, Jaeger or Tempo for distributed tracing, and alerting pipelines that route the right signals to the right people.

The result is that a small platform team supporting a handful of product squads can easily find themselves maintaining hundreds of Helm charts, dozens of Kubernetes operators, and a labyrinthine set of custom resource definitions — all before a single product feature is written.

CI/CD: The Pipeline That Ate the Backlog

Continuous integration and continuous delivery pipelines have become foundational to modern software delivery. However, the operational overhead of CI/CD systems is frequently underestimated.

Pipeline maintenance is not a one-time cost. As codebases grow and teams scale, pipelines accrue complexity organically. Test flakiness, long build times, inconsistent environments between local development and CI, and brittle deployment scripts are among the most common complaints from engineering teams. Studies from DORA (DevOps Research and Assessment) consistently show that elite-performing organizations deploy frequently and recover from incidents quickly — but achieving that performance requires significant investment in pipeline reliability and developer experience.

Beyond maintenance, there is the problem of cognitive overhead. Developers must context-switch from product thinking to infrastructure thinking when a pipeline breaks, a deployment rolls back unexpectedly, or a new environment needs to be provisioned. Each context switch carries a cost that compounds over time and across teams.

Security in CI/CD is another growing concern. Supply chain attacks have made pipeline integrity a critical issue. Managing secrets in pipelines, ensuring build reproducibility, and auditing third-party actions or plugins is non-trivial work that typically falls to platform engineers — or, more dangerously, falls through the cracks entirely.

The Cognitive Load Problem

Perhaps the most insidious challenge is not any single technical problem but the cumulative cognitive load placed on engineering teams. Modern infrastructure tooling — Terraform, Helm, Argo CD, Flux, Kustomize, Crossplane, Backstage — requires deep expertise to operate well. Each tool has its own configuration model, failure modes, and community ecosystem. Organizations often end up with a "tool sprawl" problem: many tools solving overlapping problems, none of them integrated cohesively, and institutional knowledge locked in the heads of a few senior engineers.

When those engineers leave or get pulled onto other priorities, the risk surface increases. Runbooks grow stale. Tribal knowledge evaporates. New engineers face steep learning curves before they can contribute meaningfully to infrastructure work — let alone product work.

The Platform Engineering Response

Reclaiming Developer Experience

The industry's response to infrastructure complexity has been the emergence of platform engineering as a discipline. Platform engineering focuses on building internal developer platforms — curated, opinionated toolchains that abstract underlying infrastructure complexity and expose self-service capabilities to product teams.

The goal is to shift the cognitive model. Instead of every developer needing to understand Kubernetes YAML, network policies, and Helm templating, they interact with a higher-level abstraction: "deploy this service to staging" or "provision a Postgres database for this application." The platform team owns the implementation details; the product team owns the workload.

This model, sometimes called the "platform as a product" approach, treats internal developers as customers and the platform as a product serving their needs. It prioritizes developer experience metrics like time-to-first-deployment, onboarding time for new engineers, and self-service success rates.

Internal Developer Platforms

Platforms like Backstage (originally developed by Spotify and now a CNCF project) provide a software catalog, templating system, and plugin ecosystem that teams use to build cohesive internal portals. Engineers can browse service documentation, trigger deployments, view observability dashboards, and provision resources — all from a single interface.

Backstage has seen broad adoption, but it comes with its own cost: it requires significant investment to build, customize, and maintain. For many organizations, particularly those below a certain engineering headcount, building a full internal developer platform is not economically viable.

Managed Platforms and PaaS Renaissance

A different approach has been taken by managed platforms that provide opinionated, batteries-included environments for running workloads. These platforms — which include offerings like Render, Railway, Fly.io, and cloud-provider services like Google Cloud Run and AWS App Runner — take a sharp stance: developers should not need to think about Kubernetes at all.

These platforms abstract compute, networking, TLS termination, scaling, and deployments behind simple interfaces. A developer pushes code; the platform handles the rest. This model trades flexibility for velocity, and for many workloads, that is the right trade.

More sophisticated examples include Humanitec, which provides a platform orchestration layer that connects to existing Kubernetes infrastructure but exposes a higher-level API to developers, and Platforms-as-a-Service offerings built on top of Kubernetes like Porter or Gimlet.

GitOps and the Declarative Infrastructure Shift

GitOps has emerged as a paradigm that brings software engineering practices to infrastructure management. By treating infrastructure configuration as code stored in Git and using tools like Argo CD or Flux to reconcile cluster state with the desired state in a repository, teams gain auditability, rollback capabilities, and a single source of truth for their environments.

GitOps does not eliminate infrastructure complexity, but it does make that complexity more manageable. Changes are reviewed like code, deployments are reproducible, and drift between what is declared and what is running is continuously detected and corrected. For teams already fluent in Git-based workflows, GitOps is a natural extension that reduces operational risk without requiring a wholesale platform change.

AI-Assisted Infrastructure Management

Emerging tooling is beginning to bring AI assistance into infrastructure workflows. AI-powered features in tools like GitHub Copilot, Codeium, and specialized DevOps platforms are helping engineers write Terraform configurations, debug failing pipelines, and interpret Kubernetes events. While still maturing, these capabilities represent a meaningful reduction in the expertise barrier for infrastructure work.

More significantly, AI-assisted incident response and runbook automation are showing early promise. Systems that can correlate metrics, logs, and traces to surface root causes — and suggest remediation steps — reduce the time engineers spend context-switching into firefighting mode.

Practical Principles for Reducing Infrastructure Burden

For teams navigating these challenges, a few principles have emerged from organizations that have successfully shifted their engineers back toward product work.

Build a golden path, not a golden cage. Opinionated defaults reduce decision fatigue and enforce best practices, but they should not prevent teams from deviating when they have legitimate reasons. The goal is to make the right thing the easy thing, not the only thing.

Measure developer experience directly. Concepts like DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) and SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) provide frameworks for measuring the health of the developer experience. Teams that don't measure it can't improve it.

Shift left on platform concerns. Security scanning, policy enforcement, and observability instrumentation should be built into the delivery pipeline, not bolted on after deployment. This moves feedback earlier in the development cycle, where it is cheaper and faster to address.

Favor managed services for undifferentiated infrastructure. Databases, message queues, caches, and similar infrastructure components are not differentiating capabilities for most organizations. Using managed cloud services for these components frees engineering teams to focus on the unique problems their products solve.

Invest in documentation and runbooks as a team habit. The organizational risk of knowledge concentration is as significant as any technical risk. Teams should treat documentation as a first-class engineering artifact and hold it to similar standards of quality and currency.

The Emerging Landscape

The infrastructure tooling ecosystem continues to evolve rapidly. Platform engineering is now a recognized discipline with dedicated conferences (PlatformCon), working groups within the CNCF, and a growing body of practitioner knowledge. The CNCF Platforms Working Group has published a maturity model for platform engineering that organizations can use to benchmark their own investments.

Meanwhile, Kubernetes itself is maturing. Upstream improvements in default security posture, the graduation of key APIs from beta to stable, and the growing ecosystem of battle-tested operators have reduced some of the sharp edges. The tooling ecosystem is consolidating: fewer teams are writing bespoke deployment scripts and more are adopting standard GitOps toolchains backed by active communities.

What is most significant is the cultural shift underway. The best engineering organizations are increasingly explicit about the distinction between platform work and product work, and intentional about investing in the former to unlock velocity in the latter. Infrastructure is not going away — but the goal is to make it boring, reliable, and invisible to the engineers who don't need to think about it.

Conclusion

The challenges of managing modern infrastructure — sprawling Kubernetes configurations, fragile CI/CD pipelines, security and compliance overhead, and crushing cognitive load — are real and well-documented. But they are not intractable. A generation of platforms, practices, and cultural shifts is actively addressing them.

The common thread across the most effective approaches is not a specific tool or vendor, but a design philosophy: infrastructure should serve developers, not the other way around. When platform teams internalize that philosophy and product teams are freed from infrastructure concerns, organizations tend to find that shipping software becomes faster, more reliable, and more satisfying for everyone involved.

The future of infrastructure management is not less infrastructure — it is infrastructure that knows its place.

Session Management in React

Agbo, Daniel Onuoha — Fri, 06 Feb 2026 06:00:00 +0000

Sessions in React are about how you persist and validate user state (usually authentication) across page navigations and reloads in a single‑page application. In practice, this means combining a storage mechanism (cookies, storage, memory) with an auth/session strategy (stateful server sessions or stateless tokens) and wiring it into your React tree.

What “session” means in a React app

In a browser‑based React app, a “session” usually means:

The period during which the app considers a user authenticated.
The user- and auth-related state you keep while that’s true (user id, roles, permissions, preferences, CSRF tokens, etc.).
The rules for when that state starts (login), ends (logout, expiry), and is refreshed (token rotation, silent re‑auth).

Because React runs in the browser, session management is always a combination of client behavior and backend behavior; React only controls how you store and use data on the client, not whether a token is actually valid on the server.

Common session storage options

Mechanism	Scope / lifetime	Typical use cases	Pros	Cons
Cookies	Sent automatically with matching requests, configurable TTL	Traditional server sessions, HttpOnly auth cookies	HttpOnly, Secure, SameSite flags; good for security	CSRF care needed; limited size; must design cookie scope carefully
Local Storage	Persistent until cleared by app or user	Non‑sensitive preferences, feature flags	Simple API; survives tab close and browser restart	Accessible to JS (XSS risk); no built‑in expiry
Session Storage	Lives as long as the tab/window is open	Short‑lived, non‑sensitive session state	Isolated per tab; clears on tab close	Also JS‑accessible; no automatic server‑side awareness
JWT (JSON Web Token)	Depends on where/how you store it	Stateless auth with APIs and SPAs	No server store needed; easy to share across services	Easy to misuse; you still need secure storage and rotation
Server‑side session	Server keeps session state keyed by id (often in a cookie)	Classic web auth, many enterprise setups	Server controls revocation and expiry centrally	Requires scalable session store; more backend complexity

A key design decision is whether you use stateful sessions (server stores the session) or stateless tokens (JWT or similar) that the server validates on each request.

Implementing sessions in React

1. Cookie-based sessions (recommended for most apps)

Typical flow:

User logs in with credentials via a React form.
Backend:
- Authenticates the user.
- Creates a session record in a session store (DB, Redis, etc.).
- Sets a HttpOnly, Secure, SameSite cookie with a session id or opaque token.
React:
- Does not need direct cookie access; it just calls APIs with credentials: 'include' on fetch or appropriate config in Axios.
- Uses an auth context or state to reflect “logged in” vs “logged out” based on API responses.

Example (simplified):

// login.tsx
async function login(username: string, password: string) {
  const res = await fetch('/api/login', {
    method: 'POST',
    credentials: 'include',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  });

  if (!res.ok) throw new Error('Login failed');
}

This approach keeps sensitive data in HttpOnly cookies (not accessible to JS), which significantly reduces XSS impact.

2. JWT-based sessions in React

With JWTs, the server issues a signed token that encodes claims like user id and expiry. The client then sends this token with each API call.

Safer patterns:

Prefer short‑lived access tokens plus refresh tokens.
Prefer storing:
- Access token in memory (React state) or in a non‑persistent store,
- Refresh token in an HttpOnly cookie, and
- Using a refresh endpoint to get new access tokens when they expire.

Very simplified pattern:

// authClient.ts
let accessToken: string | null = null;

export function setAccessToken(token: string | null) {
  accessToken = token;
}

export async function apiFetch(input: RequestInfo, init: RequestInit = {}) {
  const headers = new Headers(init.headers);
  if (accessToken) {
    headers.set('Authorization', `Bearer ${accessToken}`);
  }

  const res = await fetch(input, { ...init, headers, credentials: 'include' });

  if (res.status === 401) {
    // try refresh
    const refreshed = await fetch('/api/refresh-token', {
      method: 'POST',
      credentials: 'include',
    });
    if (refreshed.ok) {
      const { token } = await refreshed.json();
      setAccessToken(token);
      headers.set('Authorization', `Bearer ${token}`);
      return fetch(input, { ...init, headers, credentials: 'include' });
    }
  }

  return res;
}

Avoid long‑lived JWTs in localStorage/sessionStorage for highly sensitive applications, as they’re vulnerable to XSS.

3. Using localStorage and sessionStorage

These should mostly be used for non‑sensitive or low‑risk data:

Feature toggles.
UI preferences (theme, layout).
Last visited page or onboarding flags.

If you must store auth‑adjacent information (e.g., a non‑critical flag), consider:

// storage.ts
const THEME_KEY = 'app_theme';

export function getTheme() {
  return localStorage.getItem(THEME_KEY) ?? 'light';
}

export function setTheme(theme: string) {
  localStorage.setItem(THEME_KEY, theme);
}

Always assume anything in these stores can be read by malicious scripts if XSS occurs.

Managing session state in React (Context pattern)

React needs a way to expose session state (user info, loading, error, login/logout methods) to the component tree. A common approach uses Context + a provider.

// AuthContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';

type User = { id: string; email: string } | null;

type AuthContextValue = {
  user: User;
  loading: boolean;
  login: (email: string, password: string) => Promise<void>;
  logout: () => Promise<void>;
};

const AuthContext = createContext<AuthContextValue | undefined>(undefined);

export const AuthProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const [user, setUser] = useState<User>(null);
  const [loading, setLoading] = useState(true);

  // On mount, ask backend: "Am I logged in?"
  useEffect(() => {
    (async () => {
      try {
        const res = await fetch('/api/me', { credentials: 'include' });
        if (res.ok) {
          const data = await res.json();
          setUser(data);
        }
      } finally {
        setLoading(false);
      }
    })();
  }, []);

  const login = async (email: string, password: string) => {
    const res = await fetch('/api/login', {
      method: 'POST',
      credentials: 'include',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ email, password }),
    });

    if (!res.ok) throw new Error('Login failed');
    const data = await res.json();
    setUser(data);
  };

  const logout = async () => {
    await fetch('/api/logout', { method: 'POST', credentials: 'include' });
    setUser(null);
  };

  return (
    <AuthContext.Provider value={{ user, loading, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
};

export function useAuth() {
  const ctx = useContext(AuthContext);
  if (!ctx) throw new Error('useAuth must be used within AuthProvider');
  return ctx;
}

Components can then call useAuth() to read session state and perform login/logout.

Best practices for session management in React

Prefer HttpOnly cookies for storing truly sensitive tokens so that JavaScript cannot directly read them, reducing XSS impact.
Implement explicit session expiry on the backend and handle it gracefully in React (e.g., redirect to login or show a “session expired” banner).
Use token rotation for JWTs (short‑lived access tokens + rotating refresh tokens) to limit the impact of theft.
Protect against CSRF when using cookies:
- Use SameSite=Lax or Strict for most cookies.
- Use CSRF tokens for unsafe methods (POST, PUT, DELETE) if cookies are sent cross‑site.
Harden against XSS:
- Avoid putting long‑lived tokens in localStorage/sessionStorage.
- Sanitize user input and use frameworks’ XSS protections correctly.
Centralize auth logic:
- Keep storage and token/ cookie handling in one module or provider.
- Avoid scattering direct storage calls throughout components.
Log out correctly:
- Clear client state (React state, storage).
- Invalidate the session or refresh token on the server.

Wrapping up

In React, “sessions” are less about a specific browser API and more about a coordinated design across:

How the backend authenticates and stores session or token state.
Where and how the frontend stores any required identifiers or tokens.
How React exposes and reacts to that state across the component tree.

Choosing between cookies, JWTs, and storage should follow your security requirements, threat model, and infrastructure, not just convenience.

Monitoring Frontend Applications

Agbo, Daniel Onuoha — Mon, 02 Feb 2026 18:49:28 +0000

Frontend telemetry is the practice of collecting, analyzing, and acting on data related to user interactions and application performance in web applications. It provides real-world visibility into how applications perform across diverse devices, networks, and user contexts, enabling teams to optimize user experience and debug production issues effectively.

Understanding Frontend vs Backend Telemetry

Frontend telemetry differs fundamentally from backend observability in several ways. While backend services operate in controlled environments with predictable resources, frontend applications run on unpredictable hardware with varying network conditions, browser versions, and user behaviors. Frontend telemetry captures Real User Monitoring (RUM) data from actual user sessions, reflecting performance in the wild rather than synthetic test environments.

Core Components of Frontend Telemetry

Telemetry Signals

Traces track the complete flow of user requests through your application, capturing navigation events, API calls, and user interactions while maintaining context across frontend and backend boundaries. Metrics measure quantitative performance indicators, including Core Web Vitals, loading times, Time to First Byte (TTFB), and error rates that directly impact user experience. Logs record discrete events, errors, and state changes during user sessions, providing essential debugging context when issues occur.

OpenTelemetry for Frontend

OpenTelemetry has become the industry standard for frontend observability in 2026, offering vendor-neutral instrumentation and automatic context propagation. The framework provides JavaScript SDK packages specifically designed for browser environments, with built-in support for automatic instrumentation of common libraries and frameworks.

Implementing Production-Ready Frontend Telemetry

Initial Setup and Configuration

import { WebTracerProvider } from '@opentelemetry/sdk-trace-web';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { getWebAutoInstrumentations } from '@opentelemetry/auto-instrumentations-web';
import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

// Initialize provider with resource attributes
const provider = new WebTracerProvider({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'my-frontend-app',
    [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
  }),
});

// Configure exporter to send data to collector
const exporter = new OTLPTraceExporter({
  url: 'https://your-collector-endpoint/v1/traces',
});

// Use BatchSpanProcessor for better performance
provider.addSpanProcessor(new BatchSpanProcessor(exporter));

// Register auto-instrumentations for fetch, XMLHttpRequest, etc.
registerInstrumentations({
  instrumentations: [
    getWebAutoInstrumentations({
      '@opentelemetry/instrumentation-fetch': {
        propagateTraceHeaderCorsUrls: [/https:\/\/api\.yourdomain\.com/],
      },
    }),
  ],
});

provider.register();

Context Propagation and Distributed Tracing

The traceparent header enables distributed tracing by connecting frontend spans with backend services. OpenTelemetry automatically injects this header into outbound fetch and XMLHttpRequest calls, allowing backend services to continue the trace and visualize the complete request flow across your stack. This end-to-end visibility is crucial for debugging issues that span multiple services and identifying performance bottlenecks.

Custom Instrumentation for User Actions

const tracer = provider.getTracer('my-frontend-app');

function trackUserInteraction(action) {
  const span = tracer.startSpan(`user.${action}`, {
    attributes: {
      'user.action': action,
      'page.url': window.location.href,
    },
  });

  // Your business logic here

  span.end();
}

// Track specific user flows
trackUserInteraction('checkout-initiated');

Handling Page Lifecycle Events

Production applications must handle browser lifecycle events properly to avoid data loss:

// Flush telemetry before page unload
window.addEventListener('beforeunload', () => {
  provider.forceFlush();
});

// Handle mobile tab backgrounding
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    provider.forceFlush();
  }
});

Privacy and Compliance Considerations

GDPR and Data Privacy

Frontend telemetry must comply with privacy regulations, including GDPR and CCPA. Implement explicit user consent mechanisms before collecting telemetry data, and respect the DO_NOT_TRACK environment variable. Apply data minimization principles by collecting only necessary information and setting retention periods of 90 days or less.

PII Sanitization

Automatically sanitize personally identifiable information from telemetry data, including email addresses, user paths, and sensitive form inputs. OpenTelemetry supports custom processors that can redact sensitive data before it is transmitted to your observability backend.

Performance Overhead and Optimization

Minimizing Impact

Frontend telemetry introduces minimal performance overhead when properly configured. Use batch span processors instead of simple processors to reduce network calls, and configure appropriate sampling rates for high-traffic applications. Session replay features should use wireframe rendering rather than pixel-perfect recording to balance fidelity with performance and privacy.

Collector Proxy Architecture

Route telemetry through a collector proxy to handle CORS headers, implement access control, and add additional security layers before data reaches your backend. This architecture also enables data transformation and filtering at the edge, reducing costs and improving privacy.

Production Benefits

Full-Stack Debugging: Link frontend user actions directly to backend API responses and database queries, dramatically reducing mean time to resolution for production incidents. Real User Performance Metrics: Measure actual user experience across diverse devices, networks, and geographies rather than relying on synthetic tests that may not reflect real-world conditions. Business Context: Correlate performance metrics with business outcomes such as conversion rates and user retention to prioritize optimization efforts.

Tooling Ecosystem

Modern observaMonitoring Frontend Applications: A Complete Production Guidebility platforms, including Elastic, Grafana, and specialized Open Telemetry backends, provide visualization and analysis capabilities for frontend telemetry. These tools support trace visualization, performance dashboards, and alerting based on real user metrics.

Implementing comprehensive frontend telemetry has become essential for production web applications, providing the visibility needed to deliver exceptional user experiences while maintaining system reliability.

useTransition vs useOptimistic

Agbo, Daniel Onuoha — Mon, 08 Dec 2025 11:00:00 +0000

I've distinguished between managing the loading state (useTransition) and faking the result (useOptimistic).

The Dynamic Duo: Managing Process vs. Managing Perception

To achieve the "illusion" of speed mentioned in your image, you need two distinct tools:

useTransition: Handles the background work. It stops the browser from freezing and tells you if work is happening (isPending).
useOptimistic: Handles the immediate visual feedback. It updates the UI instantly, assuming the background work will succeed.

The Scenario: A "Like" Button

Imagine a user clicks a "Like" button on a post.

Without Optimistic UI: The user clicks -> waits 1 second -> the number goes up. (Feels sluggish).
With Optimistic UI: The user clicks -> the number goes up instantly -> the server catches up in the background. (Feels snappy).

1. The "Standard" Approach (useTransition only)

Here, we rely on the server to tell us the new like count. We use useTransition only to show a loading spinner, so the user knows something is happening.

The Experience: User clicks → Spinner appears → Spinner vanishes & Number updates.

'use client';
import { useTransition } from 'react';
import { incrementLike } from './actions'; // Server Action

export default function StandardLikeButton({ likeCount }) {
  const [isPending, startTransition] = useTransition();

  const handleClick = () => {
    startTransition(async () => {
      // 1. We wait for the server to finish,
      await incrementLike(); 
      // 2. The UI will update only after the server responds and re-renders the page
    });
  };

  return (
    <button onClick={handleClick} disabled={isPending}>
      {/* We show a loading state because we don't have the new data yet */}
      {isPending ? "Updating..." : `♥ ${likeCount} Likes`}
    </button>
  );
}

2. The "Illusion" Approach (useTransition + useOptimistic)

Here, we predict the future. We know the user wants to add a like, so we visually add it immediately. We still use startTransition to keep the app responsive, but we don't wait for the server to update the number.

The Experience: User clicks → Number updates instantly. (No spinner needed).

'use client';
import { useOptimistic, useTransition } from 'react';
import { incrementLike } from './actions';

export default function OptimisticLikeButton({ likeCount }) {
  // Setup the Optimistic State
  // arg1: The real current data (from server)
  // arg2: A reducer function to calculate the "fake" new state
  const [optimisticLikes, addOptimisticLike] = useOptimistic(
    likeCount,
    (currentState, optimisticValue) => currentState + optimisticValue
  );

  const [isPending, startTransition] = useTransition();

  const handleClick = () => {
    startTransition(async () => {
      // 1. THE ILLUSION: Update the UI immediately
      addOptimisticLike(1); 

      // 2. THE REALITY: Perform the actual server request in the background
      // If this fails, React automatically rolls back the optimistic state!
      await incrementLike(); 
    });
  };

  return (
    <button onClick={handleClick}>
      {/* We display the optimistic (predicted) value immediately */}
      ♥ {optimisticLikes} Likes
    </button>
  );
}

Key Differences Summary

Feature	`useTransition`	`useOptimistic`
Primary Goal	Prevents UI freezing; tracks "loading" status.	shows the result instantly (before server confirms).
User Experience	"Please wait..." (Honest delay)	"Done!" (Instant gratification)
Data Source	Waiting for Server Data.	Uses Client-side prediction.
If Server Fails?	App usually stays in the previous state or shows an error.	Automatically reverts the UI to the correct server state.

Why use them together?

You rarely use useOptimistic without useTransition (or Server Actions which wrap transitions).

useOptimistic handles the data (showing 101 likes instead of 100).
useTransition handles the execution (making sure the button click doesn't freeze the page while the request travels to the server).

This combination creates the "speed and clean user experience".

useTransition hook in React/Next.js

Agbo, Daniel Onuoha — Sat, 06 Dec 2025 12:37:47 +0000

Mastering React's `useTransition`: The Secret to Non-Blocking UIs

In the past, we focused on making code run faster. Today, with React 18+ and Next.js, we focus on keeping the interface responsive, even when the computer is working hard. If you aren't using useTransition, you risk freezing your user's browser while data processes—a sure way to kill user experience.

Here is a deep dive into useTransition, how it creates that "illusion" of speed, and how to implement it.

The Problem: The "Frozen" UI

To understand the solution, we must first understand the problem. In standard React rendering (pre-18), all updates were treated equally.

Imagine a user types into a search bar that filters a list of 10,000 items.

User types "A".
React updates the input value.
React calculates the filtered list.
React renders the list.

If step #3 takes 500ms, the screen effectively freezes for that half-second. The user tries to type "B", but the input box won't reflect it until the list finishes rendering. This is Blocking Rendering.

The Solution: Concurrent Rendering

React 18 introduced the concept of Concurrency. It allows React to interrupt a heavy render to handle something more important (like a keystroke) and then go back to the heavy work.

useTransition is the API that lets you tell React: "This update is heavy and non-urgent. Do it in the background, but keep the UI responsive for the user."

Urgent vs. Non-Urgent Updates

React classifies state updates into two categories:

Urgent: Direct interaction (typing, clicking, pressing). These need immediate feedback.
Transition (Non-Urgent): UI transitions (switching views, filtering lists, saving data). These can wait a few milliseconds without the user noticing.

How to Implement `useTransition`

The hook returns an array with two values:

isPending: A boolean telling you if the transition is currently active (useful for loading spinners).
startTransition: A function that wraps your state update.

Scenario 1: The Client-Side Filter (React)

Instead of blocking the user's typing, we mark the list filtering as a "transition."

import { useState, useTransition } from 'react';

export default function SearchList({ items }) {
  const [query, setQuery] = useState("");
  const [list, setList] = useState(items);

  // Initialize the hook
  const [isPending, startTransition] = useTransition();

  const handleChange = (e) => {
    const value = e.target.value;

    // 1. Urgent Update: Update the input field immediately
    setQuery(value);

    // 2. Transition Update: Filter the list in the "background"
    startTransition(() => {
      const filtered = items.filter(item => item.includes(value));
      setList(filtered);
    });
  };

  return (
    <div>
      <input value={query} onChange={handleChange} />

      {/* Optional: Show a subtle loading state while the list processes */}
      {isPending && <p>Updating list...</p>}

      <ul>
        {list.map(item => <li key={item}>{item}</li>)}
      </ul>
    </div>
  );
}

Scenario 2: Server Actions (Next.js)

This is the specific use case mentioned in your image ("upload silently behind the scenes"). In Next.js, useTransition is essential for invoking Server Actions without blocking the client.

It prevents the UI from freezing while the server processes the database request, and it allows you to display a loading state specifically for that action.

'use client';
import { useTransition } from 'react';
import { updateProfile } from './actions'; // A Server Action

export default function ProfileForm() {
  const [isPending, startTransition] = useTransition();

  const handleSubmit = (formData) => {
    // The UI remains interactive while this runs!
    startTransition(async () => {
      const result = await updateProfile(formData);
      if (result.error) {
        alert("Failed to save");
      }
    });
  };

  return (
    <form action={handleSubmit}>
      <input name="username" type="text" />

      <button type="submit" disabled={isPending}>
        {isPending ? "Saving..." : "Update Profile"}
      </button>
    </form>
  );
}

The "Illusion" of Immediate Updates

The image mentions giving users the "illusion that the data was updated immediately."

While useTransition handles the pending state, to truly achieve the illusion of instant data updates (before the server even responds), you often pair useTransition with useOptimistic.

User clicks "Like".
useOptimistic immediately switches the heart icon to red (The Illusion).
useTransition manages the background request to the server.
Server responds: If successful, the real data syncs. If it fails, the UI reverts.

This combination creates the "speed and clean user experience" described in the post.

When NOT to use `useTransition`

Do not use useTransition for controlled inputs.

If you wrap setInputValue(e.target.value) inside a startTransition, the input field will feel laggy. The user will type, but the letters will appear with a slight delay because you told React that updating the text box is "non-urgent."

Rule of Thumb:

Input/Typing: Urgent (Do NOT use startTransition).
Resulting Data/Fetching: Non-Urgent (Use startTransition).

Summary

Performance: useTransition stops heavy rendering or network requests from freezing your app.
UX: It allows the user to keep interacting with the page while work happens in the background.
Next.js: It is the standard way to handle loading states for Server Actions.

If you aren't using it yet, you aren't utilizing the full power of the React engine.

Privacy Risks of Autonomous AI Agents

Agbo, Daniel Onuoha — Sun, 28 Sep 2025 23:00:00 +0000

The Hidden Dangers of Digital Independence

Introduction: The Dawn of Digital Autonomy

Imagine an AI assistant that doesn't just respond to your commands but anticipates your needs, makes decisions on your behalf, and operates independently across your digital ecosystem. This isn't science fiction—it's the emerging reality of autonomous AI agents. These sophisticated systems represent a fundamental shift from reactive tools to proactive, decision-making entities that can plan, reason, and act with minimal human oversight.

While these agents promise unprecedented convenience and efficiency—managing our calendars, optimizing our workflows, and controlling our smart homes—they also introduce a new category of privacy risks that challenge our traditional understanding of data protection and accountability.

Understanding Autonomous AI Agents: Beyond Simple Chatbots

Autonomous AI agents are far more sophisticated than the chatbots and voice assistants we're familiar with. They possess three defining characteristics that set them apart:

Autonomous Decision-Making: After receiving a high-level instruction like "Plan my trip to New York," these agents can independently break down complex tasks, access external data sources, and make real-time decisions without requiring approval for each step.

Persistent Memory: Unlike traditional AI tools that forget previous interactions, autonomous agents maintain continuous memory of past activities, creating dynamic profiles that inform future actions and decisions.

Tool Utilization: These agents can seamlessly coordinate resources and employ various tools—from APIs and databases to smart home devices—integrating deeply into users' digital ecosystems.

This shift from reactive to proactive AI fundamentally changes the privacy landscape. When you ask a traditional AI to "play music," it simply executes that command. An autonomous agent tasked with "organizing my evening" might access your calendar, check traffic conditions, adjust your home temperature, order dinner, and reschedule conflicts—all without explicit permission for each action.

The Privacy Paradox: When Convenience Comes at a Cost

The core privacy challenge of autonomous agents lies in what experts call the "Privacy Paradox." The personalization and automation that users desire are only achievable through intensive, continuous, and often opaque data collection. This creates a fundamental disconnect between a user's initial intent and the agent's subsequent actions.

Data Lifecycle Vulnerabilities

Autonomous agents engage with data throughout its entire lifecycle, creating multiple points of vulnerability:

Massive Scale Collection: To function effectively, these systems routinely handle terabytes or petabytes of data, including sensitive information like healthcare records, financial data, and biometric information. The sheer volume increases the likelihood of data exposure.

Data Repurposing: Information collected for one purpose may be used for entirely different, unforeseen purposes without the user's knowledge. A notable example involved a surgical patient who discovered that medical photos she had consented to for treatment were used in an AI training dataset without her permission.

Data Persistence: The persistent memory of autonomous agents and plummeting storage costs mean information can be stored indefinitely, potentially outlasting the person who created it. This is problematic because privacy preferences change over time—consent given in early adulthood may lead to data being used in ways an individual would no longer agree to later in life.

Data Spillover: Agents may inadvertently collect information about individuals who weren't the intended subjects of data collection, such as bystanders who appear in photos or conversations.

Security Amplification: When Autonomy Becomes a Weapon

The independent nature of autonomous agents fundamentally transforms the security threat landscape through a concept known as "Excessive Agency"—agents having too much functionality, permissions, and autonomy.

Real-World Security Failures

Several high-profile incidents illustrate how agent autonomy amplifies security risks:

The Chevrolet Dealership Incident: An AI bot was manipulated through prompt injection to sell a $76,000 car for just $1, demonstrating how agents can be tricked like "over-trusting interns."

Microsoft's 38 Terabyte Exposure: Researchers accidentally exposed massive amounts of private data, including employee messages and passwords, through a single misconfigured token with validity until 2051. An autonomous agent with access to such systems could have amplified this exposure catastrophically.

Samsung's Shadow AI Problem: Employees accidentally leaked sensitive internal data, including proprietary source code, by using public chatbots to debug errors. Autonomous agents with broader access could turn such user errors into company-wide breaches.

ChatGPT Deep Research Vulnerability: A flaw discovered in this agent could have allowed hackers to manipulate it into forwarding sensitive Gmail documents without any user action.

These incidents reveal a dangerous pattern: technological complexity leads to human error, which autonomous agents then amplify into catastrophic consequences.

The Legal Maze: When Laws Meet Autonomy

Current privacy regulations struggle to address the unique challenges posed by autonomous agents. While frameworks like GDPR, CCPA/CPRA, and the EU AI Act provide important foundations, they weren't designed for systems that can learn and act independently.

The Informed Consent Dilemma

GDPR requires explicit, informed consent for data processing, but obtaining truly informed consent from autonomous agents is nearly impossible. Users would need to understand exactly which services and data the agent will access—information that's often unknowable at the outset. The agent, not the user, makes real-time decisions about data collection and processing.

The Right to be Forgotten Challenge

GDPR's Article 17 grants individuals the right to have their personal data deleted, but this presents profound technical challenges for AI systems. Personal information isn't stored in discrete files but is embedded in the model's weights and vector representations. Even if original training data is deleted, the patterns remain, making complete erasure technically difficult without expensive model retraining.

The Accountability Gap

Perhaps the most significant challenge is determining liability when an AI agent makes a costly mistake. Traditional legal systems weren't designed for entities that lack legal identity and cannot be held accountable for wrongdoing. This creates a potential future where "synthetic agents operate at scale with no one to answer for them."

The Inherent Risks of Black Box Decision-Making

Beyond security vulnerabilities, autonomous agents pose inherent risks due to their operational nature:

Algorithmic Opacity: Many AI models operate as "black boxes," making it difficult to understand how they make decisions or use data. This undermines accountability and makes it challenging to identify biases that could lead to discriminatory outcomes.

Unpredictable Behaviors: As AI models grow more complex, they can develop emergent abilities that weren't explicitly programmed. These unintended consequences can lead to unexpected and harmful results, such as an agent optimizing server speed by deleting security monitoring software.

Building a Defense: Technical and Operational Safeguards

Despite these challenges, organizations can implement comprehensive strategies to mitigate privacy risks:

Technical Safeguards

Principle of Least Privilege: Grant agents only the minimum permissions necessary to perform specific tasks, preventing the catastrophic consequences of excessive agency.

Privacy-Enhancing Technologies: Implement federated learning to train models without centralizing sensitive data, use differential privacy to add mathematical noise that protects individual privacy, and develop machine unlearning capabilities to address the right to be forgotten.

Security Fundamentals: Encrypt data at rest and in transit, authenticate all requests, and regularly audit third-party services for security and compliance.

Operational Controls

Human-in-the-Loop (HITL): Integrate human oversight at critical decision points, especially for high-stakes decisions with legal, financial, or safety implications. This creates verifiable audit trails and restores accountability.

Continuous Monitoring: Implement ongoing auditing to detect model drift, track data provenance, and ensure compliance. Maintain tamper-proof, human-verifiable audit trails.

Privacy-Centric Culture: Train employees on privacy risks and establish clear policies for handling autonomous agents and sensitive data.

Recommendations: A Blueprint for Responsible Innovation

To navigate the privacy challenges of autonomous AI agents successfully, organizations should:

Adopt Layered Defense: Combine technical controls, architectural principles, and human oversight rather than relying on single solutions.
Prioritize Human Oversight: Implement mandatory human review for high-impact decisions to create verifiable chains of custody and close accountability gaps.
Embrace Privacy by Design: Make privacy a core engineering requirement from the outset, treating it as a strategic asset that builds user trust.
Invest in Governance: Implement continuous monitoring and auditing systems to ensure ongoing compliance and accountability.

Conclusion: Toward Accountable Autonomy

The future of autonomous AI agents isn't about preventing autonomy—it's about ensuring that every action carries a verifiable signature. This requires a fundamental shift in how we approach AI development, regulation, and deployment.

As we stand at the threshold of an agentic era, we face a critical choice: we can either allow these powerful systems to operate in the shadows, creating unprecedented privacy risks and accountability gaps, or we can proactively build frameworks that harness their potential while protecting individual rights and freedoms.

The path forward demands a layered defense that integrates legal principles, technical safeguards, and human oversight. Only by treating privacy and accountability as foundational requirements—not afterthoughts—can we ensure that the unseen hand of AI becomes a force for good rather than a source of fear.

The stakes couldn't be higher. The decisions we make today about autonomous agent governance will shape the digital landscape for generations to come. By acting now to establish responsible frameworks, we can unlock the tremendous potential of these systems while preserving the privacy and autonomy that form the bedrock of a free society.

Forem: Agbo, Daniel Onuoha

Browser-Based LLMs in Healthcare

The Core Architecture: Edge AI in the Browser

Why Healthcare Is a Perfect Fit

Privacy by Architecture

Zero-Latency Clinical Interactions

Offline Capability and Rural Access

Real-World Healthcare Use Cases

1. EMR De-identification and Anonymization

2. Private Symptom Screening

3. Clinical Note Generation

4. Patient-Facing EHR Interpretation

5. Medical Record Summarization

Implementation: Getting Started with WebLLM

Limitations and Engineering Challenges

The Regulatory Landscape

The Road Ahead

Use Google Gemini to Illustrate an Entire Book in Minutes

Introduction

The Big Idea: AI as a Creative Pipeline

Step 1: Ingest the Entire Story

Step 2: Establish a Cohesive Art Direction

Why this matters

Step 3: Build a Character Bible

Why this is critical

Step 4: Generate High-Fidelity Artwork

Step 5: Automate Chapter-by-Chapter Illustration

Result

The Real Breakthrough: Agentic Workflows

Architecture

Practical Considerations

⚠️ Cost

⚡ Performance Tips

Getting Started

Final Thoughts

Building a CI/CD Pipeline

Jenkins: Maximum Flexibility, Maximum Ownership

What It Is

Installation

Defining a Pipeline

Connecting to Source Control

When Jenkins Makes Sense

GitHub Actions: Zero-Infrastructure CI/CD for GitHub Teams

What It Is

Workflow Structure

Reusable Workflows

When GitHub Actions Makes Sense

CircleCI: Speed-Optimized Cloud-Native Pipelines

What It Is

Defining a Pipeline

Advanced Caching

When CircleCI Makes Sense

Side-by-Side Comparison

Choosing the Right Tool

Firestore's New Query Engine

Prerequisites and Setup

Step 1: Create a Firestore Enterprise Database

Step 2: Update Your SDKs

Step 3: Connect to the Enterprise Database

Core Concepts: Stages, Expressions, and Functions

Your First Pipeline Query

Filtering and Projection

Filtering with where()

Projecting Fields with select()

Aggregations and Grouping

Global Aggregation

Grouped Aggregation

Unnesting Arrays

Finding Trending Hashtags

Filtering on Array Element Values

String Operations

Substring Search

Regex Matching

Chaining Stages: A Real-World Example

Sampling Documents

Query Explain: Diagnosing Performance

Analyzing a Query Without Executing It

Running with Full Profiling

Creating an Index

Input Stages: More Than Just Collections

Filtering with `where()`

Projecting Fields with `select()`