In this post, we’ll build a semantic documentation search API that lets users ask natural-language questions instead of matching exact keywords. We’ll use Qdrant as the vector database, Xenova/transformers to generate local text embeddings and NestJS as our API to tie everything together.

We will learn how to run Qdrant with Docker, generate embeddings in Node.js and index docs as vectors with metadata in Qdrant. Our documentation API will provide a pure semantic search endpoint and a hybrid search endpoint that combines filters for an even more effective search.

Prerequisites

• Basic knowledge of NestJS and TypeScript
• Basic knowledge of HTTP, RESTful APIs, and cURL
• Node.js and Docker should be installed

How Semantic Search Works

Semantic search focuses on meaning, not just words. It understands user intent and contextual meaning, then finds data with similar meaning rather than matching keywords. Semantic search solves this by converting text into vectors (arrays of numbers) that capture meaning, and then comparing these vectors to find related information.

For example, if our docs contain the phrase “How to authenticate users using JWT” and a user searches for “login security setup,” semantic search can infer they mean the same thing.

What Is Qdrant?

Qdrant is a vector database built for speed. It stores vectors and handles nearest neighbor calculations quickly. Qdrant uses the HNSW algorithm (Hierarchical Navigable Small World) to find similar vectors and return results in milliseconds. We’ll use the official Docker image to run it locally, which keeps our environment clean and makes the database easy to start and stop.

What Is Xenova?

Xenova lets you run machine learning models directly in Node.js. We’ll use it through the @xenova/transformers package to generate embeddings locally. This means no API calls, no rate limits and our data doesn’t leave our machine. The model downloads once (~23 MB) and caches locally for future use.

Project Setup

First, create a NestJS project:

nest new semantic-search-api
cd semantic-search-api

Next, run the command below to install our dependencies:

npm install @nestjs/config @qdrant/js-client-rest @xenova/transformers uuid \
  && npm install --save-dev @types/uuid

In our install command, @nestjs/config is used to import environment variables into our app, @qdrant/js-client-rest is the JavaScript client for interacting with the Qdrant vector database, @xenova/transformers is used to generate local text embeddings, and uuid is used to create unique identifiers for documents and embeddings.

Running Qdrant with Docker

Instead of installing Qdrant directly, we’ll use Docker Compose to keep our environment clean. Create a docker-compose.yml file at the root of your project and paste the code below:

version: '3.8'

services:
  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"  # REST API port
    volumes:
      - ./qdrant_storage:/qdrant/storage

Start the database in the background:

docker-compose up -d

Next, create a .env file and paste your Qdrant connection settings and embedding configuration:

QDRANT_URL=http://localhost:6333
QDRANT_COLLECTION=documentation
QDRANT_VECTOR_DIMENSION=384
HF_MODEL_CACHE=./models

The variables above configure Qdrant’s URL and collection name, set the vector dimension to 384 (which matches our embedding model), and specify where Xenova caches the downloaded model.

Next, let’s update the app module to import the ConfigModule, so that we can load environment variables in our app:

Update your app.module.ts file with the following:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      envFilePath: '.env',
    }),
    // ... we will add other modules here later
  ],
})
export class AppModule {}

Project Structure

Our project structure will look like this:

src/
├── qdrant/
│   ├── qdrant.module.ts
│   └── qdrant.service.ts
├── embeddings/
│   ├── embeddings.module.ts
│   └── embeddings.service.ts
├── documents/
│   ├── documents.module.ts
│   ├── documents.controller.ts
│   ├── document-ingestion/
│   │   ├── document-ingestion.service.ts
│   │   └── document-ingestion.service.spec.ts
│   └── document-processor/
│       ├── document-processor.service.ts
│       └── document-processor.service.spec.ts
└── search/
    ├── search.module.ts
    ├── search.service.ts
    ├── search.service.spec.ts
    └── search.controller.ts

Run the command below to generate the necessary files:

nest g module qdrant && \
nest g service qdrant && \
nest g module embeddings && \
nest g service embeddings && \
nest g module documents && \
nest g service documents/document-processor && \
nest g service documents/document-ingestion && \
nest g controller documents && \
nest g module search && \
nest g service search && \
nest g controller search

Choosing an Embedding Model

For this project, we’ll be using Xenova/all-MiniLM-L6-v2 for embeddings. This model is great at producing sentence-level embeddings, which work well for semantic search over documentation. It is relatively small and fast, and this makes it practical to run in Node.js without requiring a GPU. It outputs fixed 384-dimensional vectors (arrays with a fixed length of 384), which match our Qdrant collection configuration.

The model runs completely locally. On first use, Xenova downloads and caches it, and every subsequent run uses the cached version.

Building the Embedding Service

Our EmbeddingService will be responsible for converting text into vectors. Open the embeddings.service.ts file and update it with the following:

import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import {
  pipeline,
  env,
  FeatureExtractionPipeline,
} from '@xenova/transformers';

export type EmbeddingVector = number[];

@Injectable()
export class EmbeddingsService {
  private extractor: FeatureExtractionPipeline | null = null;
  private readonly DIMENSION: number;

  constructor(private readonly configService: ConfigService) {
    const vectorDimensionEnv = this.configService.getOrThrow<string>(
      'QDRANT_VECTOR_DIMENSION',
    );
    this.DIMENSION = parseInt(vectorDimensionEnv, 10);
  }

  private async getExtractor(): Promise<FeatureExtractionPipeline> {
    if (!this.extractor) {
      env.localModelPath = this.configService.getOrThrow<string>(
        'HF_MODEL_CACHE',
      );

      console.log('Loading embedding model (first time only, ~5s)...');
      const pipe = await pipeline(
        'feature-extraction',
        'Xenova/all-MiniLM-L6-v2',
      );
      this.extractor = pipe;
      console.log('Embedding model loaded.');
    }

    return this.extractor;
  }

  async embed(text: string): Promise<EmbeddingVector> {
    const extractor = await this.getExtractor();
    const output = await extractor(text, {
      pooling: 'mean',
      normalize: true,
    });

    return Array.from(output.data as Float32Array);
  }

  async embedBatch(texts: string[]): Promise<EmbeddingVector[]> {
    const extractor = await this.getExtractor();
    const output = await extractor(texts, {
      pooling: 'mean',
      normalize: true,
    });

    const data = Array.from(output.data as Float32Array);
    return Array.from({ length: texts.length }, (_, i) =>
      data.slice(i * this.DIMENSION, (i + 1) * this.DIMENSION),
    );
  }

  async warmup(): Promise<void> {
    try {
      await this.embed('warmup');
      console.log('Embedding model warmup completed.');
    } catch (error) {
      console.error('Embedding model warmup failed:', error);
      throw error;
    }
  }
}

The extractor property stores our loaded embedding model. It is initialized as null and loaded lazily on first use. This means the model only downloads when it is actually needed, rather than slowing down application startup.

The getExtractor() method loads and caches the model. First, we check if this.extractor already exists. If it does, we return it. If not, we set env.localModelPath to tell Xenova where to cache the downloaded model files, then call pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2') to download and load the model.

The embed() method calls the extractor with two options: pooling: 'mean', which averages all token embeddings into a single vector, and normalize: true, which scales the vector to unit length (required for cosine similarity in Qdrant). The extractor returns a Float32Array, which we convert to a regular array using Array.from().

For embedBatch(), we pass an array of texts to the extractor. The model returns a flattened array containing all vectors concatenated together. We split this back into individual vectors by slicing out chunks of 384 values (our vector dimension). The first text gets indices 0–383, the second gets 384–767 and so on.

The warmup() method runs a dummy embedding to preload the model, preventing the first real user request from experiencing a delay while the model loads. Be sure to export the EmbeddingsService in the EmbeddingsModule.

Building the Qdrant Service

This service wraps the vector database and handles creating the collection as well as reading and writing vectors. Update the qdrant.service.ts file with the following:

import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import {
  QdrantClient,
  Schemas,
} from '@qdrant/js-client-rest';

export interface IQdrantPayload {
  title: string;
  category: string;
  url: string;
  text: string;
  chunkIndex: number;
  [key: string]: unknown;
}

export interface IQdrantPoint {
  id: string;
  vector: number[];
  payload: IQdrantPayload;
}

@Injectable()
export class QdrantService {
  private readonly client: QdrantClient;
  private readonly vectorDimension: number;
  private readonly collectionName: string;

  constructor(private readonly configService: ConfigService) {
    const url = this.configService.get<string>('QDRANT_URL');
    if (!url) {
      throw new Error('QDRANT_URL is not set in environment');
    }

    this.collectionName =
      this.configService.get<string>('QDRANT_COLLECTION') || 'documentation';

    const vectorDimensionEnv = this.configService.getOrThrow<string>('QDRANT_VECTOR_DIMENSION');
    this.vectorDimension = parseInt(vectorDimensionEnv, 10);

    this.client = new QdrantClient({ url });
  }

  getCollectionName(): string {
    return this.collectionName;
  }

  async setupCollection(): Promise<void> {
    const collections = await this.client.getCollections();
    const exists = collections.collections?.some(
      c => c.name === this.collectionName,
    );

    if (exists) {
      console.log(`✓ Collection "${this.collectionName}" already exists.`);
      return;
    }

    await this.client.createCollection(this.collectionName, {
      vectors: {
        size: this.vectorDimension,
        distance: 'Cosine',
      },
    });

    console.log(`✓ Created collection "${this.collectionName}".`);
  }

  async upsertPoints(points: IQdrantPoint[]): Promise<void> {
    await this.client.upsert(this.collectionName, {
      wait: true,
      points,
    });
  }

  async search(
    vector: number[],
    limit: number,
    filter?: Schemas\['SearchRequest'\]['filter'],
  ): Promise<Schemas\['ScoredPoint'\][]> {
    const params: Schemas['SearchRequest'] = {
      vector,
      limit,
      with_payload: true,
      with_vector: false,
      ...(filter && { filter }),
    };

    return this.client.search(this.collectionName, params);
  }
}

We define an interface for our vector points. Each point has an ID, a vector and a payload. The payload holds metadata such as the text content and URL.

Our constructor reads our environment variables and creates a Qdrant client. The setupCollection() method checks if our collection exists and creates it if it doesn’t. We use Cosine distance, which is the standard for semantic similarity.

The upsertPoints() method saves vectors and their metadata to Qdrant. Finally, the search() method finds similar vectors. We request the payload but not the vector itself, since we only need the metadata for displaying results.

Document Chunking

Document Processing Service

LLMs and vector databases work best with smaller chunks of text. When large text, such as a 10-page document, is embedded as a single vector, specific details get lost.

While our Xenova model has a safe upper bound limit of approximately 2,000 characters, for best search quality it is advised to embed text with a length of 400–600 characters. Therefore, we need to split documents into chunks; for this project, we’ll aim for around 500 characters.

Our chunking strategy will aim for the maximum number of complete paragraphs we can fit within the 500-character limit. Then we’ll start a new chunk with an overlap from the end of the previous chunk. The purpose of the overlap is to preserve context across chunk boundaries.

Update your document-processor.service.ts file with the following:

import { Injectable } from '@nestjs/common';

export interface IDocumentMetadata {
  title: string;
  category: string;
  url: string;
}

export interface IDocumentChunk {
  text: string;
  chunkIndex: number;
  metadata: IDocumentMetadata;
}

@Injectable()
export class DocumentProcessorService {
  private readonly CHUNK_SIZE = 500; // characters
  private readonly OVERLAP = 50;     // characters


  chunkDocument(
    content: string,
    metadata: IDocumentMetadata,
  ): IDocumentChunk[] {
    const chunks: IDocumentChunk[] = [];
    const paragraphs = content
      .split('\n\n')
      .map(p => p.trim())
      .filter(p => p.length > 0);

    let currentChunk = '';
    let chunkIndex = 0;

    for (const paragraph of paragraphs) {
      const potentialChunk = currentChunk
        ? `${currentChunk}\n\n${paragraph}`
        : paragraph;

      if (potentialChunk.length > this.CHUNK_SIZE && currentChunk) {
        // Current chunk is full; emit it
        chunks.push({
          text: currentChunk,
          chunkIndex,
          metadata,
        });

        // Start new chunk with overlap (prefer complete sentence, fallback to word boundary)
        const overlap = this.findOverlap(currentChunk);
        currentChunk = overlap + '\n\n' + paragraph;
        chunkIndex++;
      } else {
        currentChunk = potentialChunk;
      }
    }

    // Emit last chunk
    if (currentChunk.length > 0) {
      chunks.push({
        text: currentChunk,
        chunkIndex,
        metadata,
      });
    }

    return chunks;
  }

  private findOverlap(text: string): string {
    const searchWindow = text.slice(-this.OVERLAP * 2);
    
    // Try to find last complete sentence
    const sentenceMatch = searchWindow.match(/[.!?]\s+([^.!?]+)$/);
    if (sentenceMatch) {
      return sentenceMatch[1].trim();
    }
    
    // Fallback: find word boundary near target overlap length
    const tail = text.slice(-this.OVERLAP * 1.5);
    const wordMatch = tail.match(/\s+(\S+.*)$/);
    if (wordMatch) {
      return wordMatch[1].trim();
    }
    
    // Last resort: from last space
    const lastSpace = text.lastIndexOf(' ', text.length - this.OVERLAP);
    return lastSpace !== -1 ? text.slice(lastSpace + 1) : text.slice(-this.OVERLAP);
  }
}

In the code above, we set our chunk size to 500 characters with a 50-character overlap. The overlap helps preserve context across chunk boundaries.

The chunkDocument() method splits text by paragraph, then accumulates paragraphs until the next one would exceed our limit. It then saves the chunk and starts a new one with an overlap from the end of the chunk that was just saved.

The findOverlap() method tries to find a complete sentence for the overlap first. If that fails, it looks for a word boundary. This keeps the overlap readable rather than cutting words in half.

Document Ingestion Service

This service processes raw documents, converts them to vectors and saves them in Qdrant. Update your document-ingestion.service.ts file with the following:

import { Injectable } from '@nestjs/common';
import { v4 as uuidv4 } from 'uuid';
import { DocumentProcessorService, IDocumentMetadata, IDocumentChunk } from '../document-processor/document-processor.service';
import { EmbeddingsService, EmbeddingVector } from '../../embeddings/embeddings.service';
import { QdrantService, IQdrantPoint, IQdrantPayload } from '../../qdrant/qdrant.service';

export interface IRawDocument extends IDocumentMetadata {
  content: string;
}

@Injectable()
export class DocumentIngestionService {
  constructor(
    private readonly processor: DocumentProcessorService,
    private readonly embeddings: EmbeddingsService,
    private readonly qdrant: QdrantService,
  ) {}

  /**
   * Ingest one or more raw documents:
   * - Chunk content into smaller overlapping pieces.
   * - Embed all chunk texts in a batch.
   * - Upsert points (vector + payload) into Qdrant.
   */
  async ingestDocuments(docs: IRawDocument[]): Promise<{
    status: 'ok' | 'error';
    documents: number;
    totalChunks: number;
    skipped: number;
    error?: string;
  }> {
    try {
      if (!docs?.length) {
        return { status: 'ok', documents: 0, totalChunks: 0, skipped: 0 };
      }

      await this.qdrant.setupCollection();

      let totalChunks = 0;
      let skipped = 0;

      for (const doc of docs) {
        const result = await this.ingestDocument(doc);
        if (result.success) {
          totalChunks += result.chunks;
        } else {
          skipped++;
        }
      }

      return {
        status: 'ok',
        documents: docs.length - skipped,
        totalChunks,
        skipped,
      };
    } catch (error) {
      console.error('Fatal error during ingestion:', error);
      return {
        status: 'error',
        documents: 0,
        totalChunks: 0,
        skipped: docs?.length ?? 0,
        error: error instanceof Error ? error.message : 'Unknown error',
      };
    }
  }

  private async ingestDocument(doc: IRawDocument): Promise<{
    success: boolean;
    chunks: number;
  }> {
    try {
      if (!doc.title || !doc.content) {
        console.warn('Skipping document, missing title or content');
        return { success: false, chunks: 0 };
      }

      const metadata: IDocumentMetadata = {
        title: doc.title,
        category: doc.category || 'uncategorized',
        url: doc.url || '',
      };

      const chunks = this.processor.chunkDocument(doc.content, metadata);
      if (chunks.length === 0) {
        console.warn(`Skipping "${doc.title}" - produced no chunks`);
        return { success: false, chunks: 0 };
      }

      const vectors = await this.embeddings.embedBatch(
        chunks.map(chunk => chunk.text),
      );

      if (vectors.length !== chunks.length) {
        console.error(
          `Error ingesting "${doc.title}": expected ${chunks.length} vectors, got ${vectors.length}`,
        );
        return { success: false, chunks: 0 };
      }

      const points = this.createQdrantPoints(chunks, vectors);
      await this.qdrant.upsertPoints(points);

      console.log(`✓ Ingested "${doc.title}" (${chunks.length} chunks).`);
      return { success: true, chunks: chunks.length };
    } catch (error) {
      console.error(`Error ingesting "${doc.title}":`, error);
      return { success: false, chunks: 0 };
    }
  }

  private createQdrantPoints(
    chunks: IDocumentChunk[],
    vectors: EmbeddingVector[],
  ): IQdrantPoint[] {
    return chunks.map((chunk, index) => ({
      id: uuidv4(),
      vector: vectors[index],
      payload: {
        title: chunk.metadata.title,
        category: chunk.metadata.category,
        url: chunk.metadata.url,
        text: chunk.text,
        chunkIndex: chunk.chunkIndex,
      },
    }));
  }
}

In our constructor, we inject three services: the document processor for chunking, the embeddings service for generating vectors and the Qdrant service for database operations.

The ingestDocuments() method processes multiple documents at once. First, it confirms that the Qdrant collection is set up, then it processes each document individually. If one document fails, we still proceed with the others while tracking which documents were skipped and which were successful.

The ingestDocument() method handles the actual ingestion for individual documents. It verifies that the document has the required fields, sets up metadata, chunks the content, generates embeddings and saves them to Qdrant. It also confirms that the number of vectors is consistent with the number of chunks; if not, it sends a warning and skips that document.

The createQdrantPoints() method is a helper that combines our chunks, vectors and metadata into the format Qdrant expects.

Documents Controller and Module

Update your documents.controller.ts file with the following:

import { Body, Controller, Post } from '@nestjs/common';
import { DocumentIngestionService, IRawDocument } from './document-ingestion/document-ingestion.service';

@Controller('documents')
export class DocumentsController {
  constructor(private readonly ingestionService: DocumentIngestionService) {}

  @Post('ingest')
  async ingest(@Body() body: { docs: IRawDocument[] }) {
    if (!body?.docs?.length) return { error: 'No documents provided' };
    return this.ingestionService.ingestDocuments(body.docs);
  }
}

Next, update the DocumentsModule to import the EmbeddingsModule and QdrantModule.

Building the Search Service

The search service handles user queries. Update your search.service.ts file with the following:

import { Injectable } from '@nestjs/common';
import { EmbeddingsService } from '../embeddings/embeddings.service';
import { QdrantService, IQdrantPayload } from '../qdrant/qdrant.service';
import { Schemas } from '@qdrant/js-client-rest';

export interface ISearchResult {
  title: string;
  snippet: string;
  url: string;
  category: string;
  score: number;
  chunkIndex: number;
}

@Injectable()
export class SearchService {
  private static readonly MIN_LIMIT = 1;
  private static readonly MAX_LIMIT = 100;
  private static readonly DEFAULT_LIMIT = 10;

  constructor(
    private readonly embeddings: EmbeddingsService,
    private readonly qdrant: QdrantService,
  ) {}

  private mapHits(hits: Schemas\['ScoredPoint'\][]): ISearchResult[] {
    return hits
      .filter(hit => hit.payload && hit.score !== undefined)
      .map(hit => {
        const payload = hit.payload as IQdrantPayload;
        return {
          title: String(payload?.title ?? ''),
          snippet: String(payload?.text ?? ''),
          url: String(payload?.url ?? ''),
          category: String(payload?.category ?? ''),
          score: hit.score ?? 0, //similarity score
          chunkIndex: Number(payload?.chunkIndex ?? 0),
        };
      });
  }

  private validateAndNormalizeQuery(query: string): string | null {
    const trimmed = query?.trim();
    return trimmed && trimmed.length > 0 ? trimmed : null;
  }

  private clampLimit(limit: number): number {
    return Math.max(SearchService.MIN_LIMIT, Math.min(SearchService.MAX_LIMIT, limit));
  }

  private createCategoryFilter(category: string | null | undefined): Schemas\['SearchRequest'\]['filter'] | undefined {
    const trimmed = category?.trim();
    if (!trimmed) {
      return undefined;
    }
    return {
      must: [
        {
          key: 'category',
          match: { value: trimmed },
        },
      ],
    };
  }

  private async performSearch(
    query: string,
    limit: number,
    filter?: Schemas\['SearchRequest'\]['filter'],
  ): Promise<ISearchResult[]> {
    try {
      const vector = await this.embeddings.embed(query);
      const hits = await this.qdrant.search(vector, limit, filter);
      return this.mapHits(hits);
    } catch (error) {
      console.error('Error performing search:', error);
      return [];
    }
  }

  
  async search(query: string, limit = SearchService.DEFAULT_LIMIT): Promise<ISearchResult[]> {
    const normalizedQuery = this.validateAndNormalizeQuery(query);
    if (!normalizedQuery) {
      return [];
    }
    return this.performSearch(normalizedQuery, this.clampLimit(limit));
  }

  async searchWithCategory(
    query: string,
    category?: string | null,
    limit = SearchService.DEFAULT_LIMIT,
  ): Promise<ISearchResult[]> {
    const normalizedQuery = this.validateAndNormalizeQuery(query);
    if (!normalizedQuery) {
      return [];
    }
    const filter = this.createCategoryFilter(category);
    return this.performSearch(normalizedQuery, this.clampLimit(limit), filter);
  }
}

The mapHits() method converts Qdrant’s raw response into a user-friendly format. The validateAndNormalizeQuery() method verifies we have an actual query string, clampLimit() keeps result counts within safe limits and createCategoryFilter() builds the Qdrant filter object when users filter by category.

The performSearch() method embeds the user query, searches Qdrant and maps the results.

The search() method uses only pure semantic search with no filters, while searchWithCategory() adds category filtering for more specific searches.

Search Controller

Our search controller exposes two endpoints. The /search endpoint provides pure semantic search, while /search/hybrid adds category filtering. Update your search.controller.ts file with the following:

import { Controller, Get, Query } from '@nestjs/common';
import { SearchService } from './search.service';

@Controller('search')
export class SearchController {
  constructor(private readonly searchService: SearchService) {}

  private parseLimit(limit: string | undefined): number {
    const parsed = Number(limit);
    return isNaN(parsed) || parsed <= 0 ? 10 : parsed;
  }

  @Get()
  async search(
    @Query('q') q: string,
    @Query('limit') limit?: string,
  ) {
    if (!q) {
      return { error: 'Query parameter "q" is required' };
    }
    return this.searchService.search(q, this.parseLimit(limit));
  }

  @Get('hybrid')
  async hybrid(
    @Query('q') q: string,
    @Query('category') category?: string,
    @Query('limit') limit?: string,
  ) {
    if (!q) {
      return { error: 'Query parameter "q" is required' };
    }
    return this.searchService.searchWithCategory(q, category, this.parseLimit(limit));
  }
}

Finally, update the SearchModule to import the EmbeddingsModule and QdrantModule.

Application Warmup

We don’t want the first user request to hang while our ML model loads, so we’ll add a warmup phase during application startup.

Update your main.ts file with the following:

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { EmbeddingsService } from './embeddings/embeddings.service';
import { QdrantService } from './qdrant/qdrant.service';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  try {
    console.log('Starting services warmup...');
    const embeddings = app.get(EmbeddingsService);
    const qdrant = app.get(QdrantService);
    
    await Promise.all([
      embeddings.warmup(),
      qdrant.setupCollection(),
    ]);
    console.log('✓ Services ready.');
  } catch (err) {
    console.error('Warmup failed', err);
    process.exit(1);
  }

  await app.listen(3000);
}
bootstrap();

This loads the ML model and sets up the database collection before accepting requests.

Testing the API

Run the following in your terminal to start your server:

npm run start:dev

You should see the warmup logs followed by the server start message.

Ingesting Documents

Let’s add some test documents:

curl -X POST http://localhost:3000/documents/ingest \
  -H "Content-Type: application/json" \
  -d '{
    "docs": [
      {
        "title": "API Authentication",
        "category": "Security",
        "url": "/docs/auth",
        "content": "To access the API, you must use a Bearer token in the header. Tokens expire after 1 hour."
      },
      {
        "title": "Rate Limiting",
        "category": "Performance",
        "url": "/docs/rate-limits",
        "content": "We limit requests to 100 per minute per IP address. Exceeding this returns a 429 Too Many Requests error."
      }
    ]
  }'

Your response should be:

{
  "status": "ok",
  "documents": 2,
  "totalChunks": 2,
  "skipped": 0
}

Searching Documents

Let’s try a semantic search. Note that we’re not using the exact words “Bearer” or “header”:

curl "http://localhost:3000/search?q=how%20do%20I%20log%20in%20to%20the%20api"

The system understands that “log in” is semantically related to “authentication” and “Bearer token,” so it returns the Authentication document.

Testing Hybrid Search

Let’s try searching with a category filter:

curl "http://localhost:3000/search/hybrid?q=api%20limits&category=Performance"

Your response should be:

This searches for content semantically related to “api limits” but only returns results in the “Performance” category.

Conclusion

In this article, we learned how to run a vector database locally with Docker, generate embeddings without external APIs, chunk documents with overlapping windows and combine vector similarity with metadata filtering.

Possible next steps include swapping Xenova for OpenAI if we need larger models, or moving Qdrant to a cloud cluster for millions of vectors, while preserving the existing NestJS logic.

Testing a web API involves much more than simply checking whether methods return or send data correctly. It requires validating real-world behaviors like pagination, unique keys, data persistence and other database rules. Anticipating and reproducing these scenarios can be challenging, especially when they depend on specific query behaviors or stored data.

To address this, the .NET ecosystem provides powerful tools for unit testing. In this post, we explore how in-memory SQLite serves as an effective solution for testing ASP.NET Core APIs, enabling developers to simulate common scenarios without deploying a real database. Additionally, we demonstrate how tools like Progress Telerik JustMock can streamline test implementation and help validate business rules efficiently.

The Importance of Testing in Real-World Environments

A common example of functionality in web APIs is paginated search, which at first glance is quite simple. We receive parameters such as page and pageSize, apply a Skip and a Take, return the data and move on. In a controlled scenario, with few records, it’s difficult for something to go wrong.

The problem begins when this code reaches production or even test environments, without having been validated with a real database. Consider a common scenario: in a paginated search, sorting is essential for it to function correctly. Without an explicit OrderBy, the database does not guarantee the order of the returned records.

In in-memory lists, the result usually appears stable, which completely masks the problem. Without tests running this query on a relational database, the error goes unnoticed, resulting in inconsistent pagination with duplicate records between pages, items “disappearing” when navigating between pages or different results for the same request. This type of bug is especially difficult to reproduce locally when not using a real database or even a simulation of one.

This is where the in-memory database plays a very important role. It allows the query to be executed exactly as it will be executed in production, revealing flaws that only appear when pagination, sorting and the database work together.

Understanding In-Memory SQLite

In-memory SQLite is a way to use the SQLite database entirely in memory. Instead of saving data to a .db file, SQLite creates the database only while the application or connection is active. When the connection is closed, all data is discarded.

In-memory SQLite is widely used in automated testing, especially in ASP.NET Core applications in conjunction with Entity Framework Core, as it has advanced features such as simulating a real database and executing real SQL (constraints, indexes, unique keys, FK and others).

Testing with SQLite in Memory

Next, we’ll look at some examples of unit tests in common web API scenarios where in-memory SQLite excels. But first, let’s create the basic application and then add the tests.

You can access all the code discussed in this post in this GitHub repository: Memo Order source code.

To create the application you can use the command below:

dotnet new web -o MemoOrder

To add the NuGet packages you can use the following commands:

dotnet add package Microsoft.EntityFrameworkCore --version 10.0.1
dotnet add package Microsoft.EntityFrameworkCore.Sqlite --version 10.0.1

Then, open the application and create the following classes:

namespace MemoOrder;

public class Order
{
    public int Id { get; set; }
    public string Number { get; set; } = string.Empty;
    public decimal TotalAmount { get; set; }
    public DateTime CreatedAt { get; set; }
    public bool IsDeleted { get; set; }
}

namespace MemoOrder;

public class OrderSummaryDto
{
    public string Number { get; set; }
    public decimal Total { get; set; }
}

using Microsoft.EntityFrameworkCore;

namespace MemoOrder;

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options) { }

    public DbSet<Order> Orders => Set<Order>();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>(entity =>
        {
            entity.HasKey(o => o.Id);
            entity.Property(o => o.Number).IsRequired();
            entity.HasIndex(o => o.Number).IsUnique();
entity.HasQueryFilter(o => !o.IsDeleted);
        });
    }
}

using Microsoft.EntityFrameworkCore;

namespace MemoOrder;

public class OrderRepository
{
    private readonly AppDbContext _context;

    public OrderRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task AddAsync(Order order)
    {
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    }

    public async Task<List<Order>> Pagination(AppDbContext context, int skip, int take)
    {
        return await context.Orders
                    .OrderBy(o => o.Id)
                    .Skip(skip)
                    .Take(take)
                    .ToListAsync();
    }
}

Now let’s create a special factory class that will be used in the tests to create the in-memory database and keep the connection open while the tests are running. Create the following class in the application:

namespace MemoOrder;

using Microsoft.Data.Sqlite;
using Microsoft.EntityFrameworkCore;

public static class SqliteInMemoryFactory
{
    public static AppDbContext Create()
    {
        var connection = new SqliteConnection("DataSource=:memory:");
        connection.Open();

        var options = new DbContextOptionsBuilder<AppDbContext>()
            .UseSqlite(connection)
            .Options;

        var context = new AppDbContext(options);
        context.Database.EnsureCreated();

        return context;
    }
}

Note that to tell SQLite to use an in-memory database, we use DataSource=:memory: in the connection string.

Creating the Test Project

All the code needed to implement the unit tests is ready, so let’s create the test project and download the NuGet packages for it. To do this, you can use the following commands, simply run them in a terminal in the application’s root directory:

dotnet new xunit -n MemoOrder.Tests
cd MemoOrder.Tests
dotnet add package Microsoft.NET.Test.Sdk --version 18.0.1
dotnet add package xunit --version 2.9.3
dotnet add package xunit.runner.visualstudio --version 3.1.5
dotnet add package coverlet.collector --version 6.0.4
dotnet add reference ../MemoOrder/MemoOrder.csproj

Next, inside the project MemoOrder.Tests, create a new class called OrderRepositoryTests and let’s add tests to it.

Testing Persistence

The first test will be used to validate persistence—that is, to insert data into the database (which in this case will be the in-memory database). To do this, simply add the following test method to the OrderRepositoryTests class:

[Fact]
public async Task AddAsync_ShouldPersistOrder()
{
    // Arrange
    using var context = SqliteInMemoryFactory.Create();
    var repository = new OrderRepository(context);

    var order = new Order
    {
        Number = "ORD-2026-0001",
        TotalAmount = 200m,
        CreatedAt = DateTime.UtcNow
    };

    // Act
    await repository.AddAsync(order);

    // Assert
    var savedOrder = await context.Orders.FirstAsync();

    Assert.Equal("ORD-2026-0001", savedOrder.Number);
    Assert.Equal(200m, savedOrder.TotalAmount);
}

Note that we use var context = SqliteInMemoryFactory.Create(); to create and represent the database in memory. It works exactly like the EF Core context that maps database tables to class entities.

Testing Constraint UNIQUE

Another common mistake is allowing duplicate records to reach the production environment, which in many cases can have catastrophic impacts. With in-memory testing, we can anticipate problems like this. Simply create a test that verifies inserting a duplicate record will generate an exception. In this case, we could do the following:

[Fact]
public async Task Should_Throw_When_Duplicated_Order_Number()
{
    using var context = SqliteInMemoryFactory.Create();

    context.Orders.Add(new Order
    {
        Number = "ORD-001",
        TotalAmount = 100,
        CreatedAt = DateTime.UtcNow
    });

    await context.SaveChangesAsync();

    context.Orders.Add(new Order
    {
        Number = "ORD-001",
        TotalAmount = 200,
        CreatedAt = DateTime.UtcNow
    });

    await Assert.ThrowsAsync<DbUpdateException>(() => context.SaveChangesAsync());
}

In this test, we created an instance of the database in memory, added an item to the table and saved it.

Then, we tried to add the same item, which generates an exception because, in the dbContext configuration, we declared the Number property of the Order entity as Unique: entity.HasIndex(o => o.Number).IsUnique();.

Thus, we have a real-world scenario, demonstrating that duplicate records will not reach the production environment, as the unit test is able to reproduce exactly the same result.

Testing Pagination

To test pagination using an in-memory database, we could do the following:

[Fact]
public async Task Should_Return_Paginated_Orders()
{
    using var context = SqliteInMemoryFactory.Create();
    var repository = new OrderRepository(context);

    for (int i = 1; i <= 10; i++)
    {
        context.Orders.Add(new Order
        {
            Number = $"ORD-{i}",
            TotalAmount = i * 10,
            CreatedAt = DateTime.UtcNow
        });
    }

    await context.SaveChangesAsync();

    List<Order> page = await repository.Pagination(context, 5, 5);

    Assert.Equal(5, page.Count);
    Assert.Equal("ORD-6", page.First().Number);
}

Note that here we create 10 items and insert them into the in-memory database. Then, we use the Pagination(context, 5, 5) method to perform the pagination and finally verify if the expected quantity and item are correct.

An in-memory database wouldn’t be mandatory to test pagination. This could be done using only regular in-memory lists. However, in this way, we can reproduce the same production scenario.

Testing Soft Delete

Soft-delete is a technique where data is not physically removed from the database, but rather marked as inactive through a flag, such as an isDeleted or deleted_at column. This allows you to keep the entire transaction history in the database.

The problem is that in some cases soft delete can leak unwanted data into reports, new endpoints or even refactored queries. To prevent this from happening, we can use the in-memory database and simulate a search with and without soft-delete:

[Fact]
 public async Task SoftDeleted_Orders_Should_Not_Appear_In_Default_Queries()
 {
     using var context = SqliteInMemoryFactory.Create();

     context.Orders.AddRange(
         new Order
         {
             Number = "ORD-001",
             TotalAmount = 100,
             CreatedAt = DateTime.UtcNow,
             IsDeleted = false
         },
         new Order
         {
             Number = "ORD-002",
             TotalAmount = 200,
             CreatedAt = DateTime.UtcNow,
             IsDeleted = true
         }
     );

     await context.SaveChangesAsync();

     var orders = await context.Orders.ToListAsync();

     Assert.Single(orders);
     Assert.Equal("ORD-001", orders.First().Number);
 }

In this test, the list returns only one item because the second one is marked as deleted. This happens because we declared the query filter entity.HasQueryFilter(o => !o.IsDeleted); when the database is created. By using an in-memory database, we can verify this mechanism works.

It’s also possible to ignore the query filter and still verify it works:

[Fact]
public async Task Admin_Query_Should_See_SoftDeleted_Orders()
{
    using var context = SqliteInMemoryFactory.Create();

    context.Orders.AddRange(
        new Order
        {
            Number = "ORD-001",
            TotalAmount = 100,
            CreatedAt = DateTime.UtcNow,
            IsDeleted = false
        },
        new Order
        {
            Number = "ORD-002",
            TotalAmount = 200,
            CreatedAt = DateTime.UtcNow,
            IsDeleted = true
        }
    );

    await context.SaveChangesAsync();

    var orders = await context.Orders.IgnoreQueryFilters().ToListAsync();

    Assert.Equal(2, orders.Count);
}

Testing Rollback

When performing multiple operations, we run the risk of something failing during the process and the data becoming inconsistent. To keep this from happening, we can use the in-memory database to test if the rollback operation solves this problem.

[Fact]
public async Task Transaction_Should_Rollback_When_Error_Occurs()
{
    using var context = SqliteInMemoryFactory.Create();

    using var transaction = await context.Database.BeginTransactionAsync();

    context.Orders.Add(new Order
    {
        Number = "ORD-NMBR-1",
        TotalAmount = 100,
        CreatedAt = DateTime.UtcNow
    });

    await context.SaveChangesAsync();

    await transaction.RollbackAsync();

    var count = await context.Orders.CountAsync();

    Assert.Equal(0, count);
}

In this test, we added an item to the order list, saved it and then performed a rollback. Finally, we verified that the list was empty, checking that the operation was undone.

Testing Query Refactoring

Refactoring queries is often necessary, whether to improve performance or simply to make the code cleaner. The problem is that this can break queries that previously worked.

To see that both the old and new queries have the same result, we can use an in-memory database as demonstrated in the example below:

   [Fact]
    public async Task Refactored_Query_Should_Return_Same_Result()
    {
        using var context = SqliteInMemoryFactory.Create();

        var oldResult = await context.Orders
            .Where(o => o.TotalAmount > 100)
            .Select(o => o.Id)
            .ToListAsync();

        var newResult = await context.Orders
            .Select(o => new { o.Id, o.TotalAmount })
            .Where(o => o.TotalAmount > 100)
            .Select(o => o.Id)
            .ToListAsync();

        Assert.Equal(oldResult, newResult);
    }

In this example, we verify that both queries have the same result, so even after refactoring, the old logic will continue to work.

Query Test with Projection to DTO

When using Data Transfer Objects (DTOs) for data transport, we are subject to errors that can silently break our queries. Again, with an in-memory database, we can simulate a query using a DTO.

   [Fact]
    public async Task Projection_To_Dto_Should_Work()
    {
        using var context = SqliteInMemoryFactory.Create();

        var result = await context.Orders
            .Select(o => new OrderSummaryDto
            {
                Number = o.Number,
                Total = o.TotalAmount
            })
            .ToListAsync();

        Assert.NotNull(result);
    }

Note that through this test, we can be sure that our DTOs will function correctly.

Not All Tests Need a Database

Until now, we’ve used in-memory SQLite to validate constraints (UNIQUE), global filters (Soft Delete), real pagination, GroupBy, Sum, transactions and rollback.

Tests like these depend on database behavior, but it’s common to encounter scenarios where the database isn’t present, and only business rules are involved. In this case, to facilitate our work and validate our tests, we can use tools like JustMock and simulate a production-facing environment.

Next, we’ll look at some examples of business rule tests where we can use JustMock to easily create mocks for our tests.

Verifying the Repository Will Be Called

[Fact]
public async Task CreateAsync_Should_Call_Repository_AddAsync()
{
    // Arrange
    var repository = Mock.Create<IOrderRepository>();

    var order = new Order
    {
        Id = 1,
        Number = "ORD-001"
    };

    Mock.Arrange(() => repository.AddAsync(order))
        .Returns(Task.CompletedTask)
        .MustBeCalled();

    var service = new OrderService(repository);

    // Act
    await service.CreateAsync(order);

    // Assert
    Mock.Assert(repository);
}

Verifying the GetHighValueOrders Method Returns Only Orders Above the Minimum Value

[Fact]
public void GetHighValueOrders_Should_Return_Only_Orders_Above_MinValue()
{
    // Arrange
    var repository = Mock.Create<IOrderRepository>();

    var orders = FakeOrders()
        .Where(o => o.TotalAmount >= 150 && !o.IsDeleted)
        .ToList();

    Mock.Arrange(() => repository.GetHighValueOrders(150))
        .Returns(orders);

    var service = new OrderService(repository);

    // Act
    var result = service.GetHighValueOrders(150);

    // Assert
    Assert.AreEqual(1, result.Count);
    Assert.IsTrue(result.First().TotalAmount >= 150);
}

Verifying the Service Forwards Exactly the Filter Received

       [Fact]
        public void GetHighValueOrders_Should_Call_Repository_With_Same_MinValue()
        {
            // Arrange
            var repository = Mock.Create<IOrderRepository>();

            Mock.Arrange(() => repository.GetHighValueOrders(500))
                .Returns(new List<Order>())
                .MustBeCalled();

            var service = new OrderService(repository);

            // Act
            service.GetHighValueOrders(500);

            // Assert
            Mock.Assert(repository);
        }

If you run all the tests, you can verify that they all passed:

Conclusion

Testing web applications is common in software development, but these tests don’t always guarantee that errors won’t occur in the production environment. Using in-memory databases, such as in-memory SQLite, allows you to reproduce scenarios closer to reality.

In this post, we saw how this approach helps identify common errors, such as persistence, pagination and projection issues. Furthermore, we explored how JustMock can help save time when validating business rules. I hope the content covered here helps you further improve your applications, making them more reliable through even more realistic testing.

Try JustMock free for 30 days, or try out the whole Telerik DevCraft suite for access to the ASP.NET Core component library and lots more (also a free 30-day trial).

If you have worked with Blazor in versions prior to .NET 10, you have certainly encountered some difficulties in implementing not found pages and in handling NavLink to show users the page they are currently on.

This is why, during the last update to .NET 10, the team behind Blazor has significantly improved the handling of routes and the management of not found pages. In this article, we will analyze the most important aspects. Let’s get started!

Understanding the Handling of Not Found Routes in Blazor

When we talk about routing, we refer to the mechanism that allows the user to navigate to a specific component based on the requested URL. However, there may be times when there are non-existent URLs that the user attempts to navigate to, such as when an item has been deleted or when, for some reason, a page has been removed from the site.

Properly handling these scenarios is essential for a good user experience, good SEO and, in general, having a reliable web application.

The Problem with Not Found Pages Before .NET 10

You should know that before .NET 10, as part of the Router component, there was a render fragment called NotFound, which at first glance could lead us to think that it allowed defining graphical code to show content when a route was not found:

<Router AppAssembly="typeof(Program).Assembly">
    <Found Context="routeData">
        ...
    </Found>
    <NotFound>
        <LayoutView Layout="typeof(Layout.MainLayout)">
            <h1>Page not found</h1>
            <p>Sorry, but there is nothing here!</p>
        </LayoutView>
    </NotFound>
</Router>

In practice, something different occurred, as when attempting to navigate to a non-existent page, an error page was displayed instead of the defined graphical code:

Another technique that was used before .NET 10 was to handle the not found page code within the components. For example, there could be an ecommerce-type application with a products page and a product details page. On the product details page, if the user tried to access a non-existent page, it was handled similarly to the following way:

@if (product == null)
{    
    <div class="alert alert-warning text-center" role="alert">
        <h4 class="alert-heading">Product Not Found</h4>
        <p>The product with ID <strong>@Id</strong> does not exist in our catalog.</p>
        <hr>
        <button class="btn btn-outline-primary" @onclick="GoBack">
            &larr; Back to Products
        </button>
    </div>
}
else
{
    ...
}

The execution of the previous code resulted in the following appearance:

The previous code, although it achieved the goal of showing the user that the product did not exist, had several problems:

• It returned an HTTP 200 code, not a 404.
• Each component had to implement its own logic.
• If there was navigation to a non-existent URL (not handled by a component), a site error page was shown.

Next, let’s see how .NET 10 improves the handling of not found pages.

Features in .NET 10 for Route Management

In .NET 10, things have changed regarding route management. Let’s analyze what these new features are.

The Router.NotFoundPage Parameter

One of the most prominent updates is the addition of the NotFoundPage parameter to the Router component, which allows specifying a Razor page component that will be displayed when a route is not found. By default, in Blazor projects starting from .NET 10, in the Pages folder we find a component called NotFound.razor, whose structure is as follows:

NotFound.razor

@page "/not-found"
@layout MainLayout

<h3>Not Found</h3>
<p>Sorry, the content you are looking for does not exist.</p>

Routes.razor

<Router AppAssembly="typeof(Program).Assembly" NotFoundPage="typeof(Pages.NotFound)">
   ...
</Router>

The preview of this code gives the following result:

In the code above, we can see that the 404 error page must include the @page directive for it to function correctly.

Customizing the NotFound Component

With the NotFound.razor component showing us how to implement a 404 page in our Blazor apps, the next step is to customize it. There are several ways to do this. For example, by adding support for contextual messages through a service class called NotFoundContext:

public class NotFoundContext
{
    public string? Heading { get; private set; }
    public string? Message { get; private set; }

    public void UpdateContext(string heading, string message)
    {
        Heading = heading;
        Message = message;
    }
}

This class will allow you to show a custom heading and message based on the operation the user has requested. For it to work correctly, you need to register the service in Program.cs:

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddScoped<NotFoundContext>();
...
var app = builder.Build();

Now, let’s give a bit more design to the NotFound.razor template:

@page "/not-found"
@layout MainLayout
@using NotFoundManagementNET102.Services
@inject NotFoundContext NotFoundContext

<PageTitle>Not Found</PageTitle>

<div class="container mt-5">
    <div class="row justify-content-center">
        <div class="col-md-8 col-lg-6">
            <div class="card shadow-sm border-0 text-center">
                <div class="card-body p-5">
                    <div class="mb-4">
                        <svg xmlns="http://www.w3.org/2000/svg" width="80" height="80" fill="#6c757d"
                             class="bi bi-exclamation-triangle" viewBox="0 0 16 16">
                            <path d="M7.938 2.016A.13.13 0 0 1 8.002 2a.13.13 0 0 1 .063.016..." />
                        </svg>
                    </div>

                    <h3 class="card-title text-dark mb-3">
                        @(NotFoundContext.Heading ?? "Page Not Found")
                    </h3>

                    <p class="card-text text-muted mb-4">
                        @(NotFoundContext.Message ?? "Sorry, the content you are looking for does not exist.")
                    </p>

                    <div class="d-flex justify-content-center gap-2">
                        <a href="/products" class="btn btn-primary">
                            &larr; Back to Products
                        </a>
                        <a href="/" class="btn btn-outline-secondary">
                            Go Home
                        </a>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

In the code above, you can notice that it checks whether the user sets a value for Heading and Message, in order to display either a generic message or a personalized one. Let’s see next how to display custom pages based on the user’s context.

Handling Not Found Pages with NavigationManager.NotFound() and OnNotFound

In .NET 9, NavigationManager.NotFound() and OnNotFound were introduced as part of the framework improvements for handling not found pages. We can combine both with the NotFoundContext service to display a 404 response and custom messages, through the following code:

@page "/product/{Id:int}"
@using NotFoundManagementNET102.Models
@using NotFoundManagementNET102.Services
@implements IDisposable
@inject ProductService ProductService
@inject NavigationManager Navigation
@inject NotFoundContext NotFoundContext

<PageTitle>@(product?.Name ?? "Product Detail")</PageTitle>

@if (product != null)
{
    <div class="container mt-4">
        <nav aria-label="breadcrumb">
            <ol class="breadcrumb">
                <li class="breadcrumb-item"><a href="/products">Products</a></li>
                <li class="breadcrumb-item active" aria-current="page">@product.Name</li>
            </ol>
        </nav>

        <div class="card shadow-sm">
            <div class="card-body">
                <div class="row">
                    <div class="col-md-8">
                        <h2 class="card-title">@product.Name</h2>
                        <span class="badge bg-secondary mb-3">@product.Category</span>
                        <p class="card-text text-muted">@product.Description</p>

                        <div class="row mt-4">
                            <div class="col-6">
                                <h5>Price</h5>
                                <p class="fs-4 text-primary fw-bold">$@product.Price.ToString("N2")</p>
                            </div>
                            <div class="col-6">
                                <h5>Stock</h5>
                                <span class="badge @(product.Stock > 30 ? "bg-success" : product.Stock > 10 ? "bg-warning" : "bg-danger") fs-6">
                                    @product.Stock units
                                </span>
                            </div>
                        </div>
                    </div>
                </div>
            </div>
            <div class="card-footer">
                <TelerikButton OnClick="GoBack"
                               ThemeColor="@ThemeConstants.Button.ThemeColor.Primary">
                    &larr; Back to Products
                </TelerikButton>
            </div>
        </div>
    </div>
}

@code {
    [Parameter]
    public int Id { get; set; }

    private Product? product;

    protected override void OnInitialized()
    {
        // 1.
        Navigation.OnNotFound += HandleNotFound;

        // 2.
        product = ProductService.GetProductById(Id);

        if (product == null)
        {
            // 3.            
            Navigation.NotFound();
        }
    }

    private void HandleNotFound(object? sender, NotFoundEventArgs e)
    {
        // 4.
        NotFoundContext.UpdateContext(
            "Product Not Found",
            $"The product with ID {Id} does not exist in our catalog.");
    }

    private void GoBack()
    {
        Navigation.NavigateTo("/products");
    }

    public void Dispose()
    {
        // 5.
        Navigation.OnNotFound -= HandleNotFound;
    }
}

Let’s analyze in more detail what happens in the code above:

1. We subscribe to Navigation.OnNotFound to monitor when a product is not found.
2. The product is searched by its ID.
3. If the product does not exist, Navigation.NotFound is invoked, allowing the rendering of the component with an HTTP 404 code.
4. In the HandleNotFound handler, we set a custom title and message.
5. We unsubscribe from the event to avoid memory leaks.

With the previous implementation, if we navigate to a nonexistent URL such as https://localhost:7038/not-found-page, a generic message will be displayed:

However, when trying to access the URL of a nonexistent product such as https://localhost:7038/product/122, we will find a custom message:

With the above, we have confirmed that it is now much easier to handle not found routes.

Improvements in URL Detection using NavLinkMatch.All

Before .NET 10, when using Match="NavLinkMatch.All", Blazor was very strict in detecting links. For example, suppose you had something like this in your navigation menu:

<NavLink href="https://www.telerik.comproducts" Match="NavLinkMatch.All">Products</NavLink>

If you visited the /products page, the UI would mark an active link in the menu. However, if you navigated to a different URL such as /products?price=cheap or /products#offers, the UI would mark the section as inactive, leading to a poor user experience. This behavior is currently happening in our application:

In the image above, you can see how the focus is lost when navigating to a product details page. This happens because the main URL is http://localhost:5084/products, while the product URL looks like this: http://localhost:5084/product/2.

Fortunately, in .NET 10 we can inherit from NavLink and write custom logic to handle matching the URLs we need:

public class CustomNavLink : NavLink
{
    protected override bool ShouldMatch(string currentUriAbsolute)
    {
        // 1.
        var baseUri = new Uri(NavigationManagerBase.BaseUri);
        var currentUri = new Uri(currentUriAbsolute);
        var relativePath = currentUri.AbsolutePath.TrimStart('/').ToLowerInvariant();

        // 2.
        var href = AdditionalAttributes != null
            && AdditionalAttributes.TryGetValue("href", out var hrefValue)
            ? hrefValue?.ToString()?.TrimStart('/').ToLowerInvariant()
            : null;

        if (string.IsNullOrEmpty(href))
            return base.ShouldMatch(currentUriAbsolute);

        // 3.
        if (href == "products")
        {
            return relativePath == "products"
                || relativePath.StartsWith("product/");
        }

        return base.ShouldMatch(currentUriAbsolute);
    }

    [Inject]
    private NavigationManager NavigationManagerBase { get; set; } = default!;
}

In the code above:

1. We obtain the relative path from the absolute URI.
2. We get the href.
3. We perform a custom match so that NavLink is active both in /products and /product/{id}.

For the previous implementation to work in the project, we need to swap NavLink for CustomNavLink in NavMenu.razor:

...
<div class="nav-item px-3">
    <CustomNavLink class="nav-link" href="products">
        <span class="bi bi-bag-fill-nav-menu" aria-hidden="true"></span> Products
    </CustomNavLink>
</div>
...

The result of the implementation is that the user knows at all times where they are, thanks to the implementation of a custom NavLink:

Conclusion

Throughout this article, you have learned about some new features in .NET 10 that are particularly useful for handling routes.

This includes creating a context for managing information on an error page and how to use this context to show users specific error pages, in addition to an inheritance of NavLink to define custom rules for better navigation.

Undoubtedly, these new features were much needed in Blazor. Now it’s your time to use them and create better user experiences utilizing them alongside Progress Telerik components for Blazor.

AI-driven applications introduce a new set of challenges for user experience design. Traditional web applications operate within predictable boundaries, where requests complete in a consistent and measurable way. AI features change that dynamic, with response times ranging from near-instant to long-running operations that can take minutes. Designing for that variability is no longer optional, it is a core part of building reliable AI-powered applications.

The challenge extends beyond implementation into perception. Users do not experience time objectively; they react to how it feels. A blank screen creates doubt, while visible progress keeps the experience grounded. When feedback aligns with the effort required, the interaction feels natural. When it does not, friction builds quickly. Thoughtful loading design addresses this gap by communicating progress, setting expectations and reinforcing the value of the task in motion.

This guide focuses on practical loading UI patterns for AI scenarios, organized by real-world wait times. Each pattern is implemented with Blazor and Progress Telerik UI components, keeping the discussion grounded in tools developers already use. The goal is simple: create loading experiences that do more than fill time, improving perceived performance and building confidence in the system behind the scenes.

Understanding AI Application Loading Patterns

AI applications introduce a different class of loading behavior. Traditional web requests are relatively predictable, but AI workloads are not. Inference, natural language processing and computer vision all introduce variability based on model complexity, input size and system load. As powerful as these capabilities are, they require a more deliberate approach to how progress is communicated.

Effective loading experiences center on managing expectations through clear, continuous feedback. Every loading state should communicate what is happening now, what has completed and what comes next, keeping users oriented as the system works. With this foundation in place, loading patterns can be tailored to specific wait times, keeping the experience responsive and understandable regardless of how long processing takes.

Near Instantaneous Responses (Less Than 1 Second)

For interactions under one second, traditional loading indicators often add more friction than value. Quick flashes of spinners or progress bars create a visual glitch that feels broken rather than helpful. Instead, the interface should respond immediately with subtle visual feedback that confirms the action without interrupting flow.

One exception stands out: when a fast action represents the final step in a longer workflow. In these cases, introducing a brief, intentional delay can create a sense of completion, giving users a moment to recognize the result of their effort before moving on.

AI Task Examples

AI tasks that typically complete in under one second include:

• Real-time text suggestions and autocomplete
• Simple sentiment analysis on short text
• Basic image classification with lightweight models
• Cached AI responses
• Rule-based chatbot responses
• Simple recommendation filtering

Blazor Implementation Strategy

Implementing instantaneous feedback in Blazor requires careful coordination between state changes and visual cues. The goal is to reflect user actions immediately while avoiding flicker from overly brief loading states. In practice, this often means enforcing a minimal display duration for indicators so that interactions feel smooth and intentional.

Try the A/B samples below by clicking the “Zoom and Enhance” buttons twice. The A sample should feel smoother on short intervals because of the intentional delay.

UX Strategy

Instant interactions benefit from confirmation rather than explanation. Subtle cues like button state changes, input highlighting or lightweight animations signal that the system has responded, keeping the experience fluid and uninterrupted. When these signals are consistent and immediate, users stay oriented without feeling like they are waiting.

Short Wait Times (1–3 Seconds)

Short waits call for lightweight, indeterminate indicators that acknowledge progress without interrupting flow. Simple spinners or skeleton screens work well because they provide immediate feedback while keeping the interface responsive. More elaborate animations tend to work against this, as users do not have enough time to process them and the interaction can feel slower than it is.

Skeleton screens are especially effective in AI scenarios because they establish structure upfront. By rendering a placeholder version of the final layout, the interface maintains continuity and gives users a clear sense of what is coming next as content is generated.

AI Task Examples

AI operations in the 1–3 second range include:

• Text generation for short responses
• Image enhancement or basic filtering
• Summarizing a document of moderate length
• Translation of short to medium text
• Basic data analysis and insights generation
• Voice-to-text conversion for brief audio

Blazor Implementation Strategy

Chat Progress and Thinking

The Telerik UI for Blazor Skeleton component provides a straightforward way to mirror final layouts while AI-generated content is loading and the agent is thinking.

Smart Paste Loading

The following demo shows a smart paste interaction that incorporates loading indicators to signal the process taking place. The Loading Container is displayed over the form fields being populated, while a button loader indicates the action is taking place once the button is clicked.

UX Strategy

Short waits benefit from clarity without added friction. Contextual messaging that reflects the task in progress, such as “Thinking” or “Generating recommendations,” helps users understand what is happening without slowing the experience down. When combined with progressive disclosure, where partial results are rendered as they become available, the interface stays active and responsive, reducing perceived wait time while making the system’s work visible.

Medium Wait Times (3–10 Seconds)

Users begin to question responsiveness, and a lack of visible progress quickly turns into doubt. Multi-agent workflows or agentic workflows with multiple indeterminate steps can be difficult to navigate. Agents can make requests to external tools that have asynchronous processes. While these processes run, it is important to report the activity in a manageable way without losing focus of the main content.

Blazor Implementation

Provide feedback for AI operations that expose measurable progress. The example below shows a chat process where the agent uses external tools. Loading indicators are exposed in a collapsible panel to allow the user to see the progress but also hide it when the details are no longer necessary.

UX Strategy

Medium waits benefit from a balance of clarity and momentum. Directional time estimates, even something as simple as “This may take about a minute,” help users decide whether to stay engaged or return later, while continuously moving progress indicators reinforce that the system is still working. When paired with contextual messaging that explains the current step or highlights what is being processed, the experience shifts from passive waiting to a guided interaction that keeps users oriented and informed.

Extended Wait Times (10+ Seconds)

Extended wait times require a different approach. Clear visibility into progress matters, but so does the freedom to move on without losing track of what is happening. Combining progress indicators with background processing patterns allows the system to stay transparent while keeping the rest of the application usable.

Percent-complete indicators play a central role here by giving users a sense of scale. Seeing measurable progress helps them judge how much work remains and whether it is worth continuing to wait. At the same time, providing cancel or abort options keeps users in control rather than locked into a long-running process.

Step-based indicators work especially well for multi-stage AI operations by breaking the process into clear, understandable phases. Even when exact timing is uncertain, each completed step provides direction and reinforces forward movement.

Blazor Implementation

The following example uses a grid format to display and manage agent activity. Each element displays important information about the task’s state. In addition, failure modes are included and made actionable from the interface. This type of UX is great for dashboard-like scenarios where users can launch agent workflows and return later to see the task completion status.

If the user may encounter a long and undetermined loading state, a looping indicator can be used to communicate the overall steps that are running in the background, without labeling exactly what stage the process is at now. This nondeterministic progress indicator displays a carousel of information while the user waits.

With agentic applications, long processes can give the impression of wasted time, even though a process that takes minutes for an agent may have taken a human hour to complete manually. This loading pattern reminds users of the work going on behind the scenes. While some consider this a “dark pattern” when used to obscure the process details, it can be quite useful when used correctly to share honest information about the value the process provides.

Extended waits benefit from a design that prioritizes flexibility and user control. Background task patterns, such as persistent status panels or drawers, allow users to continue working while keeping progress visible, reducing the friction of being forced to wait in place. When paired with notification systems that signal completion, the need to actively monitor progress is removed entirely, giving users confidence that the system will follow through.

Longer waits create space to surface meaningful insights, explain processing steps or provide guidance for improving future results. When these elements are combined effectively, the experience shifts from a blocking delay to a managed, transparent process that keeps users informed without interrupting their workflow.

Advanced Patterns for AI Applications

Contextual Loading Messages

AI applications benefit from contextual loading messages that explain current processing steps. Replace generic “Loading...” text with specific descriptions: “Analyzing image composition,” “Generating creative variations” or “Cross-referencing knowledge base.” These messages build user understanding of AI capabilities while setting realistic expectations for output quality.

Streaming and Incremental Results

Many modern AI applications support streaming responses, particularly for text generation. Implement progressive disclosure patterns that display AI outputs as they generate, reducing perceived wait time while demonstrating active processing. This approach works particularly well for conversational AI interfaces and content-generation tools.

Summary

Designing loading experiences for AI applications is no longer about handling delays. It is about shaping how users understand and interact with the system. When feedback aligns with the work being performed, users stay engaged and in control regardless of how long processing takes.

By matching loading strategies to expected wait times, developers can move beyond generic indicators and deliver feedback that is intentional and informative. From immediate visual confirmation to multi-stage progress tracking, each pattern helps make AI interactions feel predictable and responsive.

Blazor and Telerik UI components provide a practical foundation for implementing these patterns, enabling teams to build consistent loading experiences without introducing unnecessary complexity. The advantage comes from how these tools are applied, not just their availability.

As AI continues to shape modern applications, loading design becomes a defining part of the user experience. Applications that communicate clearly during processing will feel faster and more reliable, regardless of the work happening behind the scenes.

Get Started with These Examples

Use any of the Telerik UI for Blazor components shown above, plus the Blazor MCP servers free with the 30-day trial.

Try Now

What Is Progress Agentic RAG?

Progress Agentic RAG is a RAG-as-a-Service that makes it dramatically easier to build AI systems grounded in real, trusted content. Rather than wiring together vector databases, embedding pipelines and retrieval logic yourself, Progress Agentic RAG provides an end-to-end platform for indexing, understanding and retrieving multimodal data.

It enables intelligent, agent-driven workflows that combine structured knowledge, contextual search and LLM orchestration into a unified experience.

With the introduction of the .NET SDK for Progress Agentic RAG, .NET developers can integrate this capability directly into their applications with just a few lines of code, leveraging modern .NET architecture patterns such as dependency injection, async workflows and strongly typed APIs.

From Retrieval to Agentic Intelligence

Progress Agentic RAG offers a fully capable AI Search Dashboard solution that allows you to get started in a matter of minutes. Simply connect or upload your data to a Knowledge Box, wait for NucliaDB’s blazing-fast indexing engine to process it, and you’re ready to explore grounded, contextual AI responses.

That immediate productivity is powerful. But modern enterprise development requires more than a dashboard.

Enterprise environments demand typed APIs, strong tooling and predictable behavior. Many RAG solutions are Python-first, leaving .NET teams stitching together REST calls manually and building custom abstractions just to regain the ergonomics they expect from their platform.

The new .NET SDK changes that.

It provides:

• Strongly typed APIs
• Async-first patterns
• Native .NET integration
• Simplified knowledge base interaction

With these capabilities, you can move beyond simple retrieval and begin composing intelligent, agent-driven experiences directly inside your application architecture. As powerful as it is convenient, the .NET SDK makes a great choice for new AI-enabled .NET applications.

Getting Started

Once a Knowledge Box has been established, you can begin interacting with Progress Agentic RAG through the .NET SDK.

The SDK is distributed as a NuGet package and covers the complete NucliaDB REST API. That includes strongly typed models, structured output helpers, dependency injection extensions and more than 200 APIs that expose the full surface area of the platform. See the SDK documentation page for a comprehensive list of service providers available.

Install the NuGet Package

dotnet add package Progress.Nuclia

With the package installed, you can register the INucliaDb interface using modern dependency injection patterns. The SDK supports everything from basic configuration to advanced multi-tenant scenarios using keyed services.

Register the Client

using Progress.Nuclia.Extensions;

// Create configuration
var config = new NucliaDbConfig(
    ZoneId: "aws-us-east-2-1",
    KnowledgeBoxId: "your-knowledge-box-id",
    ApiKey: "your-api-key"
);

// Register with logging
builder.Services.AddNucliaDb(config).UseLogging();

This approach aligns naturally with ASP.NET Core’s architecture. You configure once, inject where needed, and keep your AI integration cleanly separated from business logic.

Ask Questions with Agentic RAG

With configuration complete, you can begin querying your Knowledge Box using AskAsync or AskStreamingAsync.

// Make request
AskRequest askRequest = new("What issues are driving the most customer escalations this quarter?");
var response = await client.Search.AskAsync(askRequest);

// Display answer
Console.WriteLine(response.Data.Answer);

In just a few lines of code, you’re executing a grounded, agent-driven query against indexed enterprise data.

The Ask functionality is only the beginning. With more than 200 APIs available in the SDK, you can ingest and manage resources, create conversational interactions and perform search, all using strongly typed, async-first C# patterns.

With structured configuration and native .NET integration in place, you can move from experimentation to production-ready AI systems with confidence.

Explore the Examples: Blazor and .NET MAUI

The fastest way to understand what Progress Agentic RAG can do in a real application is to see it running inside the frameworks you already use.

We’ve published hands-on examples built with:

• Blazor — showcasing grounded AI experiences in modern web applications
• NET MAUI — demonstrating cross-platform, AI-powered mobile and desktop apps

These samples go beyond simple API calls. They show how to:

• Register the SDK using dependency injection
• Execute agentic queries with structured output
• Stream responses into interactive UI components
• Keep AI concerns cleanly separated from presentation logic

If you’re building internal tools, customer-facing dashboards or cross-platform AI assistants, these examples provide a production-oriented starting point.

Clone the samples, wire up your Knowledge Box and see how quickly you can integrate grounded, agent-driven intelligence into your existing .NET architecture.

Additional Media

Learn more about Progress Agentic RAG and the .NET SDK from video tutorials and podcasts:

• The Progress Agentic RAG .NET SDK was featured on episode 1997 of .NET Rocks: .NET Rocks! Agentic RAG with Ed Charbeneau
• Getting started videos by Jeff (Csharp) Fritz

While many developers using Windows love the fully integrated development experience Visual Studio provides, it’s not an option for some of us.

We will learn how to set up Visual Studio Code for Blazor web application development, a few first-hand tips and how to conveniently debug.

Why Use Visual Studio Code for Blazor Web Development?

Maybe you or your team already use Visual Studio Code for software development because of its excellent code editor or GIT integration. Why learn something new if you are happy with what you already have?

Another reason that comes to mind is your preferred operating system.

Visual Studio is only available for Windows. While I am a Windows user and have always loved the fully fledged feature set provided by Visual Studio for .NET development, I understand that there are other options.

For macOS or Linux, you do not have the option to use Visual Studio. Visual Studio Code (VS Code) is a great, lightweight, and free alternative.

Also, licensing can be an issue. While the Visual Studio Community edition has limitations, VS Code is free for .NET development, both personal and commercial.

Last but not least, VS Code uses less RAM, hard-drive space and CPU compared to fully fledged IDEs, such as Visual Studio. For hardware constraint situations, it’s an ideal choice.

Getting Started: The Setup

We need two essential things before we can start developing Blazor web applications with VS Code.

1. Obviously, we need the latest Visual Studio Code version installed
2. We also need the latest .NET SDK installed

Make sure you can execute the dotnet --version command in a terminal. If it doesn’t show the version of the installed .NET SDK, add the .NET CLI to the PATH variable of your operating system and restart your computer before trying again.

Installing the C# Dev Kit

Next, we want to install the C# Dev Kit extension for Visual Studio Code.

This extension adds C# development features, including project and solution management, debugging, syntax highlighting, code navigation, refactorings and more, to VS Code. It’s a mature extension with more than 13 million downloads.

Hint: The C# Dev Kit extension not only adds support for Blazor web development but for all C# project types, including desktop, mobile, web, or cloud-native applications.

Creating a Blazor Web App in VS Code

If you open an empty VS Code instance, you’ll get the Create .NET Project menu option in the Explorer panel.

Pressing the Create .NET Project button will execute a VS Code command that allows you to select the project type. We select the default Blazor Web App project template and choose the destination folder on the hard drive.

Depending on the project template you choose, you’ll be able to add additional information to influence the outcome of the created project.

After a few seconds, the Explorer now shows the project folder containing the created solution file, the project file and the Components folder containing the example pages and layouts.

Hint: We won’t explore the structure and architecture of the Blazor Web application.

Another option for creating a .NET project is using the .NET CLI from the terminal. The dotnet new blazor command creates the same project as shown above.

Running the Blazor Web Application in VS Code

Running a Blazor Web Application is no different from running any other .NET-based application. In a terminal, you can use the dotnet run or dotnet watch run command to run it.

The dotnet watch run command automatically rebuilds and refreshes the browser (hot reload) when you edit the code and save the file.

The application runs the same whether you run it in Visual Studio or from the command line without VS Code. All three options use the .NET CLI under the hood.

Compared to Visual Studio, VS Code is noticeably faster at applying simple changes to components, such as the text of the default Home page component.

Tip: Using hot reload saves a lot of time. Use the dotnet watch run command and open the Counter.razor component. Change the code in the IncrementCount method from currentCount++ to currentCount+=2 and save the file. Whenever you hit the Click Me button, the counter now increases the value by two instead of one.

Debugging C# Code in VS Code

VS Code not only supports running the Blazor web app, but also debugging it.

To enable debugging:

1. Open the Run and Debug panel (CTRL+SHIFT+D)
2. Click the Run and Debug button.
3. Select C#
4. Select one of the available project options, or launch the Startup project.
5. Click on Start Debugging (Green Triangle), or press F5.

You can click left of any C# code line to add a breakpoint. A yellow background highlights the code line when the debugger stops the execution. And you can use the toolbar to step through your code and hover over variables to see their values.

The debugging experience is comparable to that of other fully fledged IDEs and allows you to find bugs and understand code execution.

You can add variables to the watch view to keep their values visible as you step through program execution. You also see the call stack whenever the program execution halts, and you can enable or disable the breakpoints.

Hint: Make sure the application isn’t running from a terminal, such as using the dotnet watch run command.

Conclusion

While I personally prefer using Visual Studio 2026 for most of my development work, I hopefully was able to have shown that Visual Studio Code also offers a first-class development environment.

For Linux or macOS, VS Code would definitely be my first choice because it provides most of the tools I regularly use and contains much less bloat than a fully fledged IDE. VS Code is free for personal and commercial use.

Depending on the scope of your project and how you want to work, VS Code is a good choice to get started with Blazor web development. Especially if you already use VS Code for other projects, such as React or Angular web application development.

If you want to learn more about Blazor development, watch my free Blazor Crash Course on YouTube. And stay tuned to the Telerik blog for more Blazor Basics.

You open your code editor, create an HTML table, and try to render one million rows. The browser freezes. The tab crashes. Your Monday just got worse.

You need to display large amounts of data in a grid without killing the browser. The trick is simple: don’t render what the user can’t see.

This is where virtual scrolling comes in. Instead of creating a DOM element for every single row, you only render the rows visible on screen, plus a few extra. The user scrolls smoothly through millions of records, each new batch loading in as needed, and the browser stays fast and responsive.

Let’s do it together! Today, we will build a Super Bowl Dashboard in Angular. We will see how to handle one million viewers using Progress Kendo UI for Angular Grid. We will start with a simple table, see why it fails and then fix it using virtual scrolling and server-side data fetching.

Let’s make this work in a real project.

Setting Up the Project

First, create a new Angular application by running the command:

ng new superbowl-dashboard

Navigate to the project:

cd superbowl-dashboard

Now install the Angular Grid. The ng add command handles dependencies and theme configuration for us:

ng add @progress/kendo-angular-grid --skip-confirmation

This installs the grid package and its peer dependencies and sets up the Kendo UI default theme.

Once the installation is done, we need to activate our Kendo UI license. This step removes the watermark and unlocks all the features.

Don’t have a license? Don’t worry! You can get a completely free trial with no credit card required, so you can follow along and build the dashboard without worrying about the watermark.

To do this, download the license key file from your Telerik account. Then, run this command inside your project folder:

npx kendo-ui-license activate

Because the Kendo UI Grid is so robust, it includes many features that can slightly increase the initial bundle size. We need to prevent Angular from throwing a “bundle initial exceeded maximum budget” error when we run or build an app. Open the angular.json file and increase the budgets config for the initial type to around 5MB for warnings and 10MB for errors.

Perfect! We have a fresh Angular project with Kendo UI Grid installed and styled. Now let’s generate our Super Bowl viewers’ fake data.

Generating One Million Viewers

Before we start with the grid, we need data. We’ll create a single service that handles everything: generating fake viewer data for client-side demos and simulating a paginated server API for server-side scrolling.

To create the service, open the terminal and run the following Angular CLI command:

ng g s services/viewer

First, we will define a simple Viewer interface so our grid knows what fields to expect. Then, our service will include a generateViewers method to create mock data, and a fetchPage method that simulates a paginated server API. We won’t use fetchPage right away, but it will be ready for when we implement server-side virtual scrolling later.

Don’t worry too much about the exact implementation of the helper methods; the main idea here is not how to generate fake users, but how to create a grid capable of supporting massive amounts of data without breaking a sweat!

Open src/app/services/viewer.ts and add the following:

import { Injectable } from "@angular/core";

export interface Viewer {
  id: number;
  username: string;
  watchTimeMin: number;
  isLive: boolean;
}

export interface PagedResult {
  data: Viewer[];
  total: number;
}

const ADJECTIVES = [
  "Swift",
  "Lucky",
  "Bold",
  "Chill",
  "Epic",
  "Happy",
  "Lazy",
  "Wild",
  "Cool",
  "Fast",
];

const NOUNS = [
  "Fan",
  "Eagle",
  "Tiger",
  "Bear",
  "Wolf",
  "Hawk",
  "Fox",
  "Lion",
  "Shark",
  "Bull",
];

@Injectable({ providedIn: "root" })
export class ViewerService {
  private readonly TOTAL_VIEWERS = 1_000_000;

  generateViewers(count: number, startId = 0): Viewer[] {
    const viewers: Viewer[] = [];

    for (let i = 0; i < count; i++) {
      viewers.push({
        id: startId + i + 1,
        username: `${this.randomFrom(ADJECTIVES)}${this.randomFrom(NOUNS)}${this.randomBetween(1, 9999)}`,
        watchTimeMin: this.randomBetween(1, 240),
        isLive: Math.random() > 0.08,
      });
    }

    return viewers;
  }

  /**
   * Simulates a server API call with pagination.
   * Uses a small delay to mimic real network latency.
   */
  async fetchPage(skip: number, take: number): Promise<PagedResult> {
    await new Promise((resolve) => setTimeout(resolve, 80));

    return {
      data: this.generateViewers(take, skip),
      total: this.TOTAL_VIEWERS,
    };
  }

  private randomFrom<T>(arr: T[]): T {
    return arr[Math.floor(Math.random() * arr.length)];
  }

  private randomBetween(min: number, max: number): number {
    return Math.floor(Math.random() * (max - min + 1)) + min;
  }
}

Each viewer has a fun auto-generated username (like SwiftEagle4821), their watch time and a live status. The fetchPage method is an async function that simulates a paginated API with a small delay to mimic network latency. We’ll use generateViewers first and come back to fetchPage later.

With our service ready, let’s see what happens when we try to render all these viewers at once.

The Problem: Rendering All Rows at Once

Let’s try to do it and experience the problem firsthand. Open src/app/app.ts and replace its content:

import { Component, inject, signal } from "@angular/core";
import { CommonModule } from "@angular/common";
import { ViewerService, Viewer } from "./services/viewer";

@Component({
  selector: "app-root",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./app.html", 
})
export class App {
  private viewerService = inject(ViewerService);
  viewers = signal<Viewer[]>([]);

  loadViewers(count: number): void {
    const data = this.viewerService.generateViewers(count);
    this.viewers.set(data);
  }
}

Now, let’s open our template file, src/app/app.html and add a few buttons for 1K, 10K and 100K viewers. These buttons will call our loadViewers() method to quickly generate different amounts of fake data.

Finally, we’ll use the <kendo-grid> component in our template. The key property to pay attention to is [data]="viewers()", which tells Kendo UI to read from our reactive signal and constantly display the list of viewers.

<h1>Super Bowl Viewers Dashboard</h1>
<p>Connected viewers: {{ viewers().length.toLocaleString() }}</p>

<div class="actions">
  <button (click)="loadViewers(1_000)">1K Viewers</button>
  <button (click)="loadViewers(10_000)">10K Viewers</button>
  <button (click)="loadViewers(100_000)">100K Viewers</button>
  <button (click)="loadViewers(1_000_000)">1M Viewers</button>
</div>

<div class="grid-container" style="height: 600px; overflow: auto;">
  <table border="1" style="width: 100%; border-collapse: collapse;">
    <thead>
      <tr>
        <th>#</th>
        <th>Username</th>
        <th>Watch (min)</th>
        <th>Live</th>
      </tr>
    </thead>
    <tbody>
      @for (viewer of viewers(); track viewer.id) {
      <tr>
        <td>{{ viewer.id }}</td>
        <td>{{ viewer.username }}</td>
        <td>{{ viewer.watchTimeMin }}</td>
        <td>{{ viewer.isLive ? 'Yes' : 'No' }}</td>
      </tr>
      }
    </tbody>
  </table>
</div>

Now we can run our app. Go to the terminal and execute the following command:

ng serve

This will start the local development server. Once it finishes compiling, open your browser and navigate to http://localhost:4200.

Click “1K Viewers” and it feels smooth. Click “10K Viewers” and you will notice a significant lag.

Now click “100K Viewers” … and watch the browser scream for help. The page will freeze, the scroll will be jumpy and you might even get the “Page Unresponsive” dialog.

We have seen the problem: standard HTML tables and simple loops cannot handle huge datasets. When you click the 1M Viewers button, the browser stops working.

OK, but how can we fix this?

The Solution: Angular Grid withVirtual Scrolling

If you read about Kendo UI, you know the Kendo UI Grid, but before we to start to use it, I want to explain “virtual scrolling.” Think of virtual scrolling like a camera moving over a big stadium. You only see the seats in the camera frame, maybe 50 seats. The stadium has 1,000,000 seats, but the camera doesn’t need to show all of them at once. It only shows what is visible.

Kendo UI Grid does exactly this with one property: scrollable="virtual". Let’s use it.

First, update your app.ts. We need to import KENDO_GRID and remove the CommonModule because the grid will handle everything now:

import { Component, inject, signal } from "@angular/core";
import { KENDO_GRID } from "@progress/kendo-angular-grid";
import { ViewerService, Viewer } from "./services/viewer";

@Component({
  selector: "app-root",
  imports: [KENDO_GRID],
  templateUrl: "./app.html", 
})
export class App {
  private viewerService = inject(ViewerService);
  viewers = signal<Viewer[]>([]);

  loadViewers(count: number): void {
    const data = this.viewerService.generateViewers(count);
    this.viewers.set(data);
  }
}

Now, let’s update src/app/app.html. We will replace the standard <table> with the <kendo-grid> component:

<h1>Super Bowl Viewers Dashboard</h1>
<p>Connected viewers: {{ viewers().length.toLocaleString() }}</p>

<div class="actions">
  <button (click)="loadViewers(10_000)">10K</button>
  <button (click)="loadViewers(100_000)">100K</button>
  <button (click)="loadViewers(1_000_000)">1M</button>
</div>

<kendo-grid
  [data]="viewers()"
  [height]="600"
  scrollable="virtual"
  [rowHeight]="36"
  [pageSize]="50"
>
  <kendo-grid-column field="id" title="#" [width]="70"></kendo-grid-column>
  <kendo-grid-column field="username" title="Username" [width]="180"></kendo-grid-column>
  <kendo-grid-column field="watchTimeMin" title="Watch (min)" [width]="110"></kendo-grid-column>
  <kendo-grid-column field="isLive" title="Live" [width]="70"></kendo-grid-column>
</kendo-grid>

Why Does This Work?

We added three important properties to the <kendo-grid> to make it fast:

1. scrollable="virtual": This tells Kendo UI: “Don’t create all the rows at once. Only create the ones the user can see right now.”
2. [rowHeight]="36": The grid needs to know exactly how tall each row is. This helps the grid calculate the scroll position correctly.
3. [pageSize]="50": This is how many rows Kendo UI keeps in the DOM. A good tip: set this to 3 times the number of rows visible on your screen.

Now, if you click the buttons, you will see that a page with 10,000, 100,000 or even one million viewers scrolls smoothly. The browser is fast because only ~50 rows are in the DOM at any time.

Kendo UI Grid does all the hard work for the rendering.

But there is one more problem. We fixed the rendering, but we are still loading one million records into the browser’s memory. For a real app, loading 1,000,000 records at once is a bad idea. It uses too much RAM and it is slow to start.

What if we want to show one million users in real-time without using all the RAM? Let’s use the final solution: Server-Side Data Fetching.

Server-Side Data Fetching with Endless Scrolling

Here’s the reality: the Super Bowl has 120 million viewers. We can’t load all of them into the browser at once. Instead, the grid should fetch data page by page as the user scrolls , loading only what’s needed, when it’s needed.

Kendo UI Grid supports this out of the box with the scrollBottom event. When the user scrolls to the bottom of the current data, the grid fires this event, and we simply fetch the next page and append it. Let’s build it!

Generate a new component by running the command in the terminal:

ng g c components/live-grid

Open src/app/components/live-grid/live-grid.ts and replace the content with:

import { Component, inject, signal, ChangeDetectionStrategy } from "@angular/core";
import { KENDO_GRID } from "@progress/kendo-angular-grid";
import { ViewerService, Viewer } from "../../services/viewer";

@Component({
  selector: "app-live-grid",
  imports: [KENDO_GRID],
  templateUrl: "./live-grid.html",
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class LiveGrid {
  private viewerService = inject(ViewerService);

  isConnected = signal(false);
  loading = signal(false);
  viewers = signal<Viewer[]>([]);
  pageSize = 1_000;

  connect(): void {
    this.isConnected.set(true);
    this.loadMore();
  }

  onScrollBottom(): void {
    if (this.loading()) return;
    this.loadMore();
  }

  private loadMore(): void {
    this.loading.set(true);
    
    this.viewerService.fetchPage(this.viewers().length, this.pageSize).then((result) => {
      this.viewers.update((current) => [...current, ...result.data]);
      this.loading.set(false);
    });
  }
}

The logic here is straightforward. First, connect() starts the process by fetching the initial data page using loadMore(). Then, whenever the user scrolls to the bottom of the grid, the (scrollBottom) event fires, triggering onScrollBottom() to fetch and append the next chunk of data to our viewers signal.

To make this work in the UI, we just need to set scrollable="scrollable" on our Kendo Grid to enable endless scrolling, and bind our loading signal to show a skeleton animation during the fetch.

Now let’s build the template in src/app/components/live-grid/live-grid.html to tie all of this together:

<h2>Live Server Feed</h2>
<p>Viewers: {{ viewers().length }}</p>

<button (click)="connect()" [disabled]="isConnected()">Connect to Live Feed</button>

@if (isConnected()) {
<kendo-grid 
    [data]="viewers()" 
    [height]="600" 
    scrollable="scrollable"
    [loading]="loading()"
    (scrollBottom)="onScrollBottom()">
    <kendo-grid-column field="id" title="#" [width]="70"></kendo-grid-column>
    <kendo-grid-column field="username" title="Username" [width]="180"></kendo-grid-column>
    <kendo-grid-column field="watchTimeMin" title="Watch (min)" [width]="110"></kendo-grid-column>
    <kendo-grid-column field="isLive" title="Live" [width]="70"></kendo-grid-column>
</kendo-grid>
}

Wire the component into the app. Update app.ts:

import { Component } from "@angular/core";
import { LiveGrid } from "./components/live-grid/live-grid";

@Component({
  selector: "app-root",
  imports: [LiveGrid],
  templateUrl: "./app.html",
})
export class App {}

And src/app/app.html:

<h1>Super Bowl Viewers Dashboard</h1>
<app-live-grid />

Run ng serve, open http://localhost:4200 and click “Connect to Live Feed.”

You’ll see the grid load the first 1,000 viewers. Now scroll down. When you reach the bottom, the grid fetches the next 1,000 viewers and appends them and the loading skeleton appears briefly while data is being fetched. Keep scrolling, and watch the viewers counter grow until it gets to 1,000,000. Yeah!!

Recap

We saw the problem: rendering thousands of rows at once makes the browser freeze. Then we added Kendo UI virtual scrolling with scrollable="virtual". This is the secret to showing large datasets without crashing.

Finally, we used server-side data fetching with the (scrollBottom) event. The grid loads data page by page. This keeps the memory usage low and the experience smooth.

In your next challenge don’t worry about the data, Kendo UI Grid makes it easy. With a few properties, your dashboard can handle millions of rows. ✌

Give it a try for free!

Try Kendo UI for Angular

Happy coding!

Source Code: https://github.com/danywalls/kendo-grid-large-app

The State of React 2025 survey results paint an interesting picture of where React stands as it heads into 2026. React 19 adoption is well underway, but stability hasn’t translated into consensus about what comes next.

What the survey shows is that some of React’s biggest bets are paying off while others are still finding their footing. The patterns we’re building with, the tools we’re reaching for and the way we think about React architecture are all shifting. In this article, we’ll look at what the data actually says and what it means for the year ahead.

React Server Components

One of the most talked about additions to React in the last couple of years has been React Server Components (RSC). Server Components are components that run on the server and let us keep server-only logic, data access and sensitive code out of the client bundle. Alongside that, Server Functions let client-side code invoke server-side logic through a framework-managed interface, without hand-rolling traditional API endpoints for every interaction.

For a great read on Server Components, check out The Current State of React Server Components: A Guide for the Perplexed.

Some have said that Server Components were to be the foundation of React’s next evolution toward a more complete full-stack framework. The survey data, however, is more nuanced.

About 45% of respondents have used Server Components, and among those who have, only about a third report a positive experience. Server Functions tell a similar story, with roughly 37% adoption and 33% positive sentiment among users. In both cases, only a small fraction of the overall community has used these features and come away with a positive sentiment.

Contrast that with Suspense, React’s mechanism for declaratively handling loading states while waiting for asynchronous data or code. Suspense has the highest adoption rate among new features and boasts strong satisfaction numbers.

It’s a useful comparison because it shows that the React community isn’t resistant to new patterns: when a new API solves a clear problem with a reasonable developer experience, adoption follows. With that said, Suspense is a smaller, more contained feature that’s easier to introduce into existing applications, while Server Components require a more fundamental shift in how we think about our application architecture.

The architecture data reinforces this picture. When asked which rendering patterns they’ve used, most teams still rely on the tried-and-true: Single-Page Applications lead the way at 84%, followed by Server-Side Rendering (61%) and Static Site Generation (44%). Newer approaches like partial hydration (25%), streaming SSR (18%) and islands architecture (14%) are gaining traction, but they’re far from mainstream.

None of this means Server Components don’t matter. Architecturally, the ability to move rendering logic to the server, reduce client-side JavaScript and simplify data fetching is significant. But the developer experience may just need more time to mature and catch up to the architectural promise. For most teams, the pragmatic move is to adopt RSC incrementally and where it makes sense, rather than treating it as a mandate to rewrite everything.

What Developers Are Curious About

The survey also gives us a sense of where developer curiosity is headed. The reading list, the section of the survey that lets respondents flag topics they want to learn more about, is a useful signal here.

ViewTransition, a React API for coordinating animated transitions between UI states, ranks near the top. So does Activity, which lets us hide and show parts of our UI while preserving their internal state and DOM. Both are currently only available in React’s Canary channel, but they point to a future where React handles more of the UX polish that we currently rely on third-party libraries for.

What’s worth noting is the general pattern across the survey data. The features gaining the most positive attention tend to be the ones that solve focused problems without requiring a wholesale rethink of how we build applications. Developers are drawn to APIs that slot into their existing workflows and make specific things easier, whether that’s handling loading states with Suspense, coordinating transitions with <ViewTransition> or managing background rendering with <Activity>.

The UI Component Library Landscape

The survey data around UI component libraries also tells an interesting story. The average respondent has used 2.3 UI libraries and a significant proportion don’t use any component library at all. As the survey itself notes, this suggests the space isn’t quite settled yet, and that there’s still room for new entrants to make their mark.

What this tells us is that developers are still actively evaluating their options. Even the most widely used libraries in the survey sit around 50-57% usage, and the libraries with the highest satisfaction rates aren’t always the ones with the broadest adoption. The needs are clear: production-quality components, built-in accessibility, consistent theming, TypeScript support and, increasingly, integration with AI-powered development workflows.

KendoReact

For teams building enterprise applications, the choice of component library has long-term implications. It affects how quickly we can ship features, how accessible our applications are out of the box and how well our UI scales across complex use cases like data grids, schedulers and form-heavy workflows.

Progress KendoReact is one library worth looking at in this context. It provides 120+ production-ready components with built-in accessibility, deep theming support through ThemeBuilder and recent investments in AI-powered developer tooling including an MCP server and AI coding assistant. For teams evaluating their UI toolkit for the year ahead, it’s a library that’s actively investing in the same directions the ecosystem is moving.

AI as an Accelerator

It would be impossible to write about React development in 2026 without mentioning AI. However, the important thing to keep in mind is that AI is changing how we write React code, not what we build with it.

The AI tooling landscape has shifted significantly over the last couple of years. AI-native editors like Cursor and Claude Code understand our entire codebase and can generate components that match our existing patterns and conventions. Model Context Protocol (MCP) integrations give AI assistants real-time access to component library documentation, so the code they generate actually uses the right props and follows current best practices.

These capabilities make us faster by reducing the time we spend on boilerplate and letting us iterate more quickly. However, they don’t replace the architectural decisions we need to make: when to adopt Server Components, how to structure our state management and which rendering patterns fit our use case. AI accelerates the execution of those decisions, not the decisions themselves.

For a deeper dive into how AI is reshaping day-to-day React workflows, from code generation to theming to agentic development, check out AI Productivity for React Developers in 2026.

What This Means for 2026

The data we surveyed today gives us a clear picture of where React is today and where it could be heading in 2026. React is stable, widely adopted and evolving, but the community’s appetite for significant change is measured.

• Server Components represent React’s most ambitious shift, but mainstream acceptance will take time. For most teams, the winning approach is incremental adoption, where it solves real problems.
• Developer experience still wins. The features seeing the strongest adoption and interest (Suspense, ViewTransition, Activity) solve focused problems without demanding that we rebuild our mental model of React.
• The component library landscape remains unsettled. Teams need libraries that invest in accessibility, developer experience and integrate well with modern tooling, including AI assistants.
• AI is making us more productive at the execution layer, but strategic decisions about architecture and user experience still require human judgment.

Looking ahead, the most successful React teams in 2026 will stay pragmatic: adopting new patterns when they solve real problems, choosing stable tooling and using AI to accelerate delivery without losing sight of fundamentals. React’s ecosystem is mature enough that we can be selective about what we adopt and when.

I’ve been developing software for more than 15 years, and the industry never stops changing. Choosing a framework is a strategic decision that must fit the time we are building in.

Building apps in 2026 is very different from 2015, 2020 or even 2025. Today, picking a UI library is more complex than before. We are no longer just building simple “forms and tables”; we are building AI-powered experiences. As developers, we now work with AI agents like Cursor and Copilot, and our UI library must be ready for AI from day one.

The best Angular library does not just save time with CSS or provide basic typical components; it must provide components and tools to help AI and agents understand our code better, saving tokens, time and money for your company, and also help the entire team to work better.

But as always, the best way to explain the importance of this choice is to look at a real-world situation.

The Scenario

Imagine you were just hired by a startup. You must deliver a complex platform quickly to compete in the market, but your app is modern in the AI era, so it needs more than basic grids and buttons. It will also have complex calendars, real-time charts, chat interfaces and anything needed to perform in accordance with modern user expectations … and it needs to help our new teammates (AI coding agents) work better and faster.

In this situation, your UI library is not just about delivering on time. It is about providing a tool that can help you ship your project, support your team with very stable code and provide complex features so you don’t have to build everything from zero. You need a library that is already “AI-ready,” with components made for AI agents and chat interfaces.

I can tell you, from experience, picking the wrong library can mean months of extra work and watching your competitors launch while you are still fixing basic things.

Today, we are going to dive into each framework, showing its strengths and weaknesses, and finally my recommendation for each scenario.

1. Kendo UI for Angular

In the scenario we described, the Progress Kendo UI for Angular component library is your best all-in-one framework. When the deadline is close and the project is high-priority, you do not have time to build everything from scratch.

Why Kendo UI Is the Best Tool for Projects

• Built for speed: With 120+ components (Grid, Excel, Charts, Scheduler, etc.) and ready-to-use Page Templates, you will be assembling your app quickly. You can save weeks of work and focus on the important parts of your code while an entire team at Progress manages the upkeep of your component library.

• MCP Server: Kendo UI is an AI-ready framework for developers and agents to increase productivity. Today, every hour (and token) is valuable. The Kendo UI MCP Server helps your AI agents (like VS Code or Cursor) write better code by following Kendo UI best practices that come directly from the team that built the software, reducing hallucinations and allowing your developers and agents ship code fast yet with the highest quality.

• AI-ready Angular components: Add intelligent features quickly with components like AIPrompt, SmartPaste or AI features in the Grid. This makes your app look modern with very little effort.

• ThemeBuilder: Avoid wasting time on CSS. You can import design tokens from Figma and get your style right the first time without writing thousands of lines of code.

• Expert help: The tier-based support plans give you peace of mind. If you have a problem at a critical moment, you have a team of professional engineers to help you, not just a public forum (but the community support is also robust!).

Pro tip: You can try Kendo UI for Angular completely free for 30 days, no credit card required. It’s the fastest way to prove to your team that you can meet that “impossible” deadline.

But what if you are looking for Google’s official baseline? That brings us to our next pick.

2. Angular Material

Angular Material is the official UI suite maintained by the Angular team. It implements Google’s Material Design and is often the first choice for developers looking for a standard, predictable foundation. While it’s the community baseline, in 2026, many projects find its rigid structure a limiting factor.

If you’ve ever worked in an Angular project, you’ve probably used it. It’s the industry standard for a reason, but standards aren’t always enough for every project.

• The Good: It is very stable. Because it is built by the same team that makes Angular, it always works with the latest versions. It follows Google’s Material Design and looks clean and professional.

• The Cons: The customization is difficult. If you need a unique look for your brand, you will spend a lot of time fighting with CSS. It also lacks advanced components for big data, like high-performance Grids or Calendars.

• My Feedback: I have seen many teams spend weeks trying to make Material look different. Also, Material lacks complex tools like a Scheduler or a Gantt Chart. If your project needs more than just basic forms, I recommend Kendo UI. It gives you 120+ advanced parts that are ready for big business needs, saving you the work of building them yourself.

If Material feels too rigid and you need a massive variety of “out-of-the-box” gadgets, you might want to consider our next option.

3. PrimeNG

PrimeNG is one of the well-known libraries in the ecosystem with a collection of components. While its catalog is extensive, navigating its many options can require a significant investment in terms of styling and consistency in larger apps.

• The Good: Their variety is unmatched. PrimeNG has many components from simple buttons to complex organization charts.

• The Cons: Maintaining a perfectly consistent visual style across many complex components can become tricky in large-scale projects. The styling system can sometimes feel overwhelming when you need deep, unified brand customization.

• My Feedback: Kendo UI provides more than just a framework. It offers tools like ThemeBuilder, Figma kits, MCP tools and AI-ready components to provide a smooth developer experience.

Now, if your project is heavily focused on data and complex dashboards, check out the next player in the game.

4. Syncfusion Angular

Syncfusion is an enterprise-focused suite that offers a wide range of specialized components.

• The Good: Their charts and grids are powerful. They are a good choice for data-heavy applications and dashboards.

• The Cons: The API does not always feel like standard Angular, which makes it harder to learn. It is also difficult to customize the components to match a Figma design. This is a framework built for developers, but real-world projects need to include the whole team.

• My Feedback: We should not waste time manually syncing Figma styles with components. I prefer Kendo UI because it is designed for developers, designers and AI agents. This provides a smooth experience for everyone on the team.

Speaking of data apps, sometimes you don’t need a full suite. If your app is 90% tables, then you should take a look at the next one.

5. AG Grid

AG Grid is a specialized library almost entirely focused on data grids. It’s a common choice for applications where tabular data is the main focus, though it requires pairing with other libraries for common UI elements like buttons and modals.

• The Good: If your application is 90% tables, this is a great choice. Its performance with very large datasets is good.

• The Cons: The real world is not only a grid. You will still need to find and style other libraries to solve other scenarios in your app, often resulting in a UI with inconsistent styles that is hard to maintain.

• My Feedback: AG Grid is powerful, but it is only one part of what you’ll need. Kendo UI gives you that same grid power in a unified system. This means your Grid, Buttons and Charts all share the same style and logic. Plus, Kendo UI has built-in PDF and Excel exporting that works perfectly without extra work.

But what if you need that speed in more than just tables? Let’s see the next option.

6. Ignite UI for Angular

Ignite UI for Angular is focused on data visualization and performance. It’s often used in scenarios where real-time charts are a priority, though its ecosystem is smaller than other major players.

• The Good: Great charts and a very fast rendering engine, especially for real-time data.

• The Cons: The ecosystem and community are smaller than the large libraries on this list. This can make it harder to find help for specific problems. Also, similar to AG Grid, in the real world our apps are more than a dashboard. They work with a combination of features that take time to build by yourself.

• My Feedback: Unlike Ignite UI, Kendo UI has Building Blocks that can solve common scenarios like login, register, forgot password, etc. Kendo UI has a very large community and professional support. This means you can always get help when you are stuck, making it a safer choice for important projects.

If you’re already familiar with the DevExpress environment from other platforms, then you’ll feel right at home with our next pick.

7. DevExtreme Angular

DevExtreme Angular by DevExpress has its roots in traditional software development, carrying over patterns from WinForms and ASP.NET. This makes it a familiar choice for teams coming from a more classical enterprise background, though its developer experience can feel a bit dated for modern web standards.

• The Good: Perfect for developers who already use DevExpress and need complex reporting tools and traditional business components.

• The Cons: It can feel a bit “old” in terms of how you write code. Changing the CSS to meet modern web standards is often a difficult and long task.

• My Feedback: To avoid the old code patterns of DevExtreme, Kendo UI offers a clean, modern architecture. It helps you build fast without creating messy code that is hard to fix later.

For those who prefer a clean, minimal design system like Ant Design, there’s a popular community implementation you should know about.

8. NG-ZORRO

NG-ZORRO is a community-driven implementation of the Ant Design system for Angular. It’s aimed at developers who want a ready-made aesthetic for dashboards. However, its community-based nature means it lacks the dedicated professional support found in commercial suites.

• The Good: It creates beautiful and professional-looking interfaces immediately. Excellent for internal tools where speed is important.

• The Cons: It is very strict about its design. If you need to change the style or keep the same look across React or Vue teams, you will find it limited.

• My Feedback: Community libraries like NG-ZORRO are good until you find a difficult bug. In a startup, time is money. Kendo UI enterprise support gets you help from the engineers who actually built the tools. This professional protection is why big companies prefer Kendo UI.

If your focus is less on “fancy” and more on extreme accessibility and enterprise clean-room aesthetics, then check this out.

9. Clarity Design System

Clarity is a design system developed by VMware. It was built for their own internal products and emphasizes a specific enterprise-style UX. While it’s highly focused on its specific patterns, customizing it to fit a broader range of brand identities can be a challenge.

• The Good: Strong focus on user experience and accessibility. It is built by VMware, so it is proven to work well for complex business tasks.

• The Cons: The look is very specific to VMware. It is difficult to change the style for a brand that wants to look unique.

• My Feedback: Clarity is very accessible, but it is hard to change. If your designers use Figma, Kendo UI is a much better choice. Progress Kendo UI provides Figma UI Kits that match the components exactly. This means your developers can build exactly what the designers created without mistakes.

Finally, if you are the type of developer who loves full modularity and building your own patterns like LEGO, you’ll love our final pick.

10. Taiga UI

Taiga UI is a library that focuses on modularity and a TypeScript-first approach. It’s designed for developers who enjoy building their UI piece by piece, though this modularity often means a slower development cycle compared to more pre-integrated solutions.

• The Good: It uses modular principles, making it perfect for developers who want to build their own patterns from zero.

• The Cons: Building a complex business dashboard this way is a slow process. In a startup, you don’t have months to build every part; you have weeks to launch.

• My Feedback: Taiga UI is fun for small experiments, but for real business, you need speed. Kendo UI gives you the same modular power but with 120+ ready-to-use components. You don’t have to build the “LEGO blocks” yourself. Kendo UI gives you the whole castle ready to use.

Recap

Today, building software is a team effort. It is for designers, developers and AI agents. Choosing a framework that thinks about all these factors is the key to a successful product.

In 2026, picking a framework is a strategic decision that defines the success of your project. Choosing Kendo UI for Angular means giving your team the best tools for modern development. With features like the MCP Server, ThemeBuilder and AI-ready components, Kendo UI for Angular helps you build applications faster and handle future challenges.

Do you want to try it?

Download Free Trial

The 2025 Stack Overflow Developer Survey confirmed what most of us already know from experience: 84% of developers are now using or planning to use AI tools in their development process. What’s more revealing is how developers are still being cautious in their use of these tools. Only about one-third say they trust AI outputs completely, while nearly half question their accuracy.

This cautious adoption tells us something important. We’re not blindly handing our work over to AI. We’re learning to use these tools strategically, treating them as assistants rather than replacements. For React developers specifically, this means adapting how we approach building interfaces, managing component libraries and iterating on features.

If you’ve been building React applications for a while, you’ve probably experienced this shift firsthand. Maybe you’re using GitHub Copilot to autocomplete component logic, or Cursor to refactor entire feature branches. Perhaps you’re generating design themes with Progress ThemeBuilder, or using Claude to debug complex state management issues. These aren’t experimental workflows anymore; they’re part of how we work.

In this article, we’ll explore what this actually looks like in practice for React developers in 2026.

Coding Itself Has Changed

There’s a shift in how we write code, and it’s not what most people expected (don’t worry, we’re not being replaced by AI). We’re spending less time on the mechanical act of typing and more time on the creative work of guiding and refining.

Ryan Dahl, the creator of Node.js and Deno, aptly put it in a recent social media post: “This has been said a thousand times before, but allow me to add my own voice: the era of humans writing code is over. Disturbing for those of us who identify as SWEs, but no less true. That’s not to say SWEs don’t have work to do, but writing syntax directly is not it.”

For React developers, this means our day-to-day work looks different. Instead of spending an hour carefully typing out a form component with all its validation logic, we might spend 10 minutes describing what we need and then another 20 minutes reviewing and adjusting the generated code. The result? The same quality component in a fraction of the time.

The iteration cycles have also become faster. When we can generate and refine code quickly, we’re more willing to try multiple approaches. Need to see how our data grid looks with server-side pagination versus client-side? Generate both implementations and compare them. Want to experiment with different state management patterns? We can prototype each one in minutes rather than hours.

We still need to understand React’s rendering model, still need to know when to use useCallback versus useMemo, still need to architect our component hierarchy thoughtfully. However, we don’t need to manually type out every property definition or write boilerplate code repeatedly.

Continuous Context and AI-Native Editors

One of the significant improvements in AI-assisted development is persistent context. Modern AI coding assistants understand our entire codebase, not just the file we’re currently editing.

Traditional autocomplete tools could only see a few lines around our cursor. They might suggest completing a function name, but they had no idea what that function should actually do or how it fit into our broader application architecture. AI-native editors and tools like Cursor, Claude Code and others have changed this completely.

These tools help maintain an understanding of our project structure, our component patterns, our naming conventions and even our coding style. When we ask them to create a new feature, they don’t just generate generic React code; they generate code that looks like it belongs in our codebase because they’ve learned from the rest of our application.

Let’s say we’re building a React dashboard UI that needs to fetch user data and display it in a table. With traditional tools, we’d manually wire up the API call, handle loading states, manage errors and set up the table structure.

With an AI assistant that understands our codebase, we can describe what we need, and it’ll generate code that uses our existing API client, follows our established error handling patterns and implements the table using whatever libraries we’re already using in our app.

Working with these AI assistants feels less like using a tool and more like pair programming with someone who already knows our codebase inside and out.

Planning and Agentic Workflows

Writing individual functions or components is one thing, but modern AI tools are increasingly capable of handling multi-step workflows that require planning and coordination. This is where agentic AI comes in: systems that can break down complex tasks into smaller steps and execute them sequentially or in parallel.

For React developers, this means we can hand off entire features to an AI agent rather than just asking for help with specific files. Want to migrate from Redux to Zustand? An AI agent can analyze our current state management setup, create a migration plan, and then systematically work through each component to update the implementation.

For example, we might tell an agent: “Build a column chart that shows quarterly sales by region, with drill-down functionality to reveal monthly data when a quarter is clicked.”

The agent can generate the chart component, configure the data bindings, create any necessary helper functions for aggregation and even add default styling or tooltips.

What’s powerful is that these agents can handle refactors and migrations that would be tedious to do manually. Need to rename a prop across 50 components? Want to update all your class components to functional components with hooks? Planning to migrate from JavaScript to TypeScript? These are exactly the kinds of repetitive-but-important tasks that agents excel at.

UI Generation, Design and Theming with AI

Building user interfaces has always involved a fair amount of repetitive work. Creating layouts, styling components and maintaining design consistency across an application. These are all necessary tasks, but they’re not where some developers want to spend their creative energy.

With AI, layout generation has become surprisingly sophisticated. Tools like v0 can take a description or even a screenshot of a design and generate React components that implement that layout. The code they produce isn’t just a rough approximation either, it’s good-quality JSX with proper semantic HTML, accessibility attributes and responsive styling.

For React developers working with component libraries like Progress KendoReact, this gets even more powerful as long as the agent has the appropriate context about the library and components. Instead of generating generic HTML and CSS, these tools can generate code using the actual components from our library. Need a data grid with sorting, filtering and pagination? Describe it, and the AI will scaffold it using the React Grid component we’re already using elsewhere in our app: with all the right props, event handlers and styling.

Progress ThemeBuilder has taken this a step further with AI-powered theme generation. Instead of manually configuring dozens of color variables and spacing values, we can describe the aesthetic we’re going for in plain English: “Create a clean, modern analytics theme with a cool blue-gray palette that feels data-driven and professional, suitable for a B2B software dashboard.” The AI generates a complete design system that applies consistently across all our components.

What makes this valuable is that the generated themes aren’t just random color combinations. The AI understands design principles like color theory, contrast ratios for accessibility and how different UI states should relate visually. When it generates a theme, it’s creating a system where primary buttons, hover states, focus indicators and disabled states all work together. ThemeBuilder also provides component-level AI theming, which means we can refine specific components without having to regenerate our entire theme.

For developers who aren’t designers (which is most of us), this removes a huge source of friction. We can focus on building functionality while still delivering applications that look professional and cohesive.

Model Context Protocol and Integration

The tools we’ve talked about so far are impressive, but they have a limitation: they only know what’s in our codebase and what they learned during training. They don’t know about our specific component library’s latest features, our company’s internal design system, or the proprietary APIs we’re building against.

This is where Model Context Protocol (MCP) becomes important. Think of MCP as a standardized way for AI models to connect to external knowledge sources and tools. Instead of the AI being limited to its training data, it can reach out to documentation, component libraries, databases and other resources to get current, specific information about the tools we’re using.

For React developers, this means our AI assistant can understand the actual API of the components we’re working with, not just generic React patterns. When we’re using the KendoReact Grid component, an MCP-enabled assistant can query the real documentation to understand what props are available, what patterns are recommended and what changed in the latest version.

The @progress/kendo-react-mcp server implements this for KendoReact. When we install it and configure it with our editor, the AI assistant gains access to comprehensive knowledge about KendoReact components. It’s not guessing at how to use the Grid, or the Scheduler, or the DatePicker. It’s referencing the actual documentation and best practices.

Here’s an example of generating a KendoReact Grid from scratch with the help of the @progress/kendo-react-mcp tool.

This can make a large difference in practice. Without MCP, we might ask an AI to create a KendoReact Grid component and get something that looks right but uses outdated props or misses important configuration options. With MCP, the AI generates code that follows current best practices and uses the component exactly as it was designed to be used.

Quality, Review and Governance

As AI-generated code becomes more prevalent in React applications, questions about quality and review processes naturally arise. The good news is that AI isn’t just generating code; it’s starting to get better at reviewing and improving it.

Modern AI tools can perform code reviews that go beyond syntax checking. They understand architectural patterns, can spot potential performance issues and flag accessibility concerns. When we commit changes, these tools can analyze the diff and provide feedback similar to what a developer might offer in a pull request review.

For React applications specifically, this means AI can catch issues like unnecessary re-renders, missing dependency arrays in hooks, improper state management patterns or components that should be memoized but aren’t. It can also verify that our components follow established patterns in our codebase and flag when new code deviates from those conventions.

AI-generated code can greatly accelerate development and improve consistency, but it’s not a replacement for human judgment. Even the more sophisticated tools benefit from a steward: a developer who reviews, guides and validates the AI’s output. Humans remain essential for making nuanced decisions, verifying alignment with project goals and upholding quality standards that AI alone can’t fully guarantee. In other words, AI can handle the heavy (repetitive) lifting, but the final responsibility still rests with us.

What This Means for Day-to-Day React Work

What does all of this actually look like in practice? How has the daily experience of building React applications changed? Here are some takeaways:

• Faster iteration: Features that used to take days can now be scaffolded in hours. AI handles repetitive boilerplate, letting us focus on logic, architecture and user experience.
• Less boilerplate, more creativity: Forms, API integrations, responsive layouts and other common patterns can be generated automatically, freeing us to solve higher-level problems.
• Higher-level decisions matter more: Understanding React fundamentals like component composition, state management, performance optimization and accessibility is more important than ever because we’re guiding and reviewing AI outputs rather than typing everything ourselves.

In short, React development in 2026 is faster, more iterative and more creative. The mechanical work of writing boilerplate and translating designs into components is largely automated, but the critical thinking and stewardship still require skilled developers.

Ready to Explore How AI Can Enhance Your React Development?

• Give the KendoReact AI Components and Features a try.
• Watch demos of AI-powered theme generation in ThemeBuilder to see how design ideation can be automated.
• Try the KendoReact MCP Server to give your AI assistant deep knowledge of KendoReact components.
• Check out the KendoReact Prompt Library for ready-made prompts that target common development scenarios.

Authentication should be straightforward, but in practice, it takes time. You’re dealing with sessions, cookies, password hashing, OAuth redirects and email verification, and each piece has its own quirks and scattered documentation. The whole time, you may also be asking yourself if you’re doing this securely. One mistake exposes your users.

Most existing tools don’t help much. NextAuth is solid if you’re using Next.js, but switching frameworks means starting over. Building from scratch gives you control at the cost of maintaining every security detail yourself. Clerk and Auth0 work well until you reach their pricing tiers or require a feature they don’t support. Passport.js works, but it hasn’t aged well—there’s callback hell and endless boilerplate.

Better Auth takes a different approach. It’s lightweight, works with any framework (Next.js, Remix, Svelte, etc.), and comes with TypeScript baked in. You get OAuth, 2FA and password resets out of the box. You can also customize when you need to, or just use the defaults.

In this guide, we’ll build a complete email and password authentication system with session management to see how Better Auth works. Users will be able to sign up, log in and stay authenticated across page refreshes. We’ll use Next.js, Drizzle ORM and SQLite.

Prerequisites

To follow along with this guide, you’ll need:

• A decent understanding of JavaScript/TypeScript
• Basic familiarity with React and Next.js
• A database ready (PostgreSQL, MySQL or SQLite)

What Is Better Auth?

Better Auth is a TypeScript-first authentication library that avoids the usual trade-offs like vendor lock-in, expensive monthly fees or complex configurations. It is framework-agnostic, so you can use it with Next.js today and switch to Remix or SvelteKit tomorrow without rewriting your auth logic. It’s not a managed service, so there’s no per-user pricing or vendor lock-in.

What makes it different? It’s database-agnostic, meaning you can use PostgreSQL, MySQL, SQLite or MongoDB. Better Auth adapts through adapters like Prisma, Drizzle and Mongoose. It’s type-safe by default, built in TypeScript from the ground up, so your IDE knows what methods exist, what data comes back, and catches errors before you run your code. It also has security measures built in by default, with proper password hashing, HttpOnly cookies, CSRF protection and secure session management. The defaults follow best practices.

Better Auth supports OAuth providers (Google, GitHub, etc.), magic links, two-factor authentication, passkeys, even enterprise SSO, and more than what we’ll cover in this article. We’re focusing on the fundamentals so you understand how the system works. Once you grasp the basics, adding these features is straightforward through Better Auth’s plugin system.

Project Setup

Let’s start by creating a new Next.js project with TypeScript and Tailwind CSS. Run the following command in your terminal:

npx create-next-app@latest better-auth --ts --tailwind --eslint --app

This creates a Next.js project with TypeScript, Tailwind CSS, ESLint and App Router (the modern Next.js routing system) configured.

Run this command to navigate into the project:

cd better-auth

Run the following command to install Better Auth and its dependencies:

npm install better-auth drizzle-orm better-sqlite3 
npm install -D drizzle-kit @types/better-sqlite3

Database Setup

Before configuring Better Auth, we need to prepare our database. We’ll break this down into three distinct files to keep things organized:

• Define the tables: Create the tables Better Auth needs (users, sessions, accounts, verification)
• Database initialization: Set up the SQLite connection and wrap it with Drizzle for type-safe queries
• Configure auth: Finally, we connect our database to Better Auth using the Drizzle adapter

Define the Tables

We need to explicitly define the tables Better Auth expects. We will add all of these to a single file. Open your lib/auth-schema.ts file and add the following to it:

The User Table
This stores basic user information.

//lib/auth-schema.ts
import { sqliteTable, text, integer } from "drizzle-orm/sqlite-core";
export const user = sqliteTable("user", {
  id: text("id").primaryKey(),
  name: text("name").notNull(),
  email: text("email").notNull().unique(),
  emailVerified: integer("emailVerified", { mode: "boolean" }).notNull(),
  image: text("image"),
  createdAt: integer("createdAt", { mode: "timestamp" }).notNull(),
  updatedAt: integer("updatedAt", { mode: "timestamp" }).notNull(),
});

The email field is unique, meaning no two users can share the same email. Better Auth requires these specific fields for its internal functionality.

Notice we mark name and email as notNull() here. This is important because Better Auth infers its types from this schema. By making them required in the database, TypeScript will automatically force us to provide them in the sign-up form later.

The Session Table
This manages active login sessions.

//lib/auth-schema.ts
export const session = sqliteTable("session", {
  id: text("id").primaryKey(),
  expiresAt: integer("expiresAt", { mode: "timestamp" }).notNull(),
  token: text("token").notNull().unique(),
  createdAt: integer("createdAt", { mode: "timestamp" }).notNull(),
  updatedAt: integer("updatedAt", { mode: "timestamp" }).notNull(),
  ipAddress: text("ipAddress"),
  userAgent: text("userAgent"),
  userId: text("userId")
    .notNull()
    .references(() => user.id),
});

Each session has a unique token and links to a user via userId. The expiresAt timestamp determines when the session becomes invalid.

The Account Table
This handles OAuth providers and stores authentication credentials.

//lib/auth-schema.ts
export const account = sqliteTable("account", {
  id: text("id").primaryKey(),
  accountId: text("accountId").notNull(),
  providerId: text("providerId").notNull(),
  userId: text("userId")
    .notNull()
    .references(() => user.id),
  accessToken: text("accessToken"),
  refreshToken: text("refreshToken"),
  idToken: text("idToken"),
  accessTokenExpiresAt: integer("accessTokenExpiresAt", { mode: "timestamp" }),
  refreshTokenExpiresAt: integer("refreshTokenExpiresAt", {
    mode: "timestamp",
  }),
  scope: text("scope"),
  password: text("password"),
  createdAt: integer("createdAt", { mode: "timestamp" }).notNull(),
  updatedAt: integer("updatedAt", { mode: "timestamp" }).notNull(),
});

The account table stores the user’s credentials, including the password. This separation keeps the architecture flexible, allowing you to link other providers like GitHub or Google to the same user identity.

Verification Table
This stores temporary code for email verification and password resets.

export const verification = sqliteTable("verification", {
  id: text("id").primaryKey(),
  identifier: text("identifier").notNull(),
  value: text("value").notNull(),
  expiresAt: integer("expiresAt", { mode: "timestamp" }).notNull(),
  createdAt: integer("createdAt", { mode: "timestamp" }),
  updatedAt: integer("updatedAt", { mode: "timestamp" }),
});

This table acts as a temporary vault for security tokens. When the system sends an email to verify a user, the unique code is stored here to ensure the link is valid and hasn’t expired when clicked.

Database Initialization

We need a running database connection. Let’s create a file called lib/db.ts. This is where we initialize SQLite and wrap it in Drizzle so we can use it everywhere else. We wrap it because we want to write TypeScript, not SQL strings. By passing the connection to Drizzle, you get to query your database using typed methods.

// lib/db.ts 
import { drizzle } from "drizzle-orm/better-sqlite3";
import Database from "better-sqlite3";

// This creates a local 'sqlite.db' file if it doesn't exist
const sqlite = new Database("sqlite.db"); 

export const db = drizzle(sqlite);

We need to do this first so we can import db into our auth configuration without TypeScript yelling at us.

Configure Auth

Now we can write the auth config. This file is where we tell Better Auth about our database and configure how users will authenticate.

Create a lib/auth.ts file and add the following to it:

//lib/auth.ts
import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { db } from "./db";
import * as schema from "./auth-schema";

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: "sqlite",
    schema: schema, // passing the schema here
  }),
  emailAndPassword: {
    enabled: true,
  },
  })

In the code above, we import the database connection db and schema we created, then pass them to Better Auth through the drizzleAdapter. This adapter translates Better Auth operations into Drizzle queries so it can read and write user data.

The provider: "sqlite" tells Better Auth we’re using SQLite. If we were using something else like PostgreSQL, we would change it to whatever we’re using.

It is important to note that the emailAndPassword: {enabled: true} option activates email and password authentication. Better Auth will generate the signup and signin endpoints we need.

Syncing Database

Now that we have three core files, we need to create the database file. Currently, sqlite.db doesn’t exist.

Drizzle Configuration

Create a file named drizzle.config.ts at the your root of your project and add the following to it:

//drizzle.config.ts
import { defineConfig } from "drizzle-kit";

export default defineConfig({
  schema: "./lib/auth-schema.ts", // where our tables will be defined
  dialect: "sqlite",
  dbCredentials: {
    url: "sqlite.db", // This is the name of the file it will create
  },
});

Here, we tell Drizzle where to find our schema and what database to use. The config points to our schema file ./lib/auth-schema.ts and specifies SQLite as the database type. The url is the filename Drizzle will create and in this case, it’s sqlite.db.

Now, run this command in your terminal to sync your code with the database:

npx drizzle-kit push

If everything is set up correctly, you should see a success message. Drizzle just created a local sqlite.db file in your project root with all your user, session and account tables.

API Route

Now we need to set up an API route so our frontend can communicate with Better Auth. Create a file named app/api/auth/[...all]/route.ts. This will be the API route that handles all auth requests:

// app/api/auth/[...all]/route.ts

import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";

export const { GET, POST } = toNextJsHandler(auth);

If your project uses src/, this goes in src/api/auth/[...all]/route.ts.

Auth Client

Finally, for our setup, we need a way for our frontend to talk to the backend without writing messy fetch calls.

Create lib/auth-client.ts file and add the following to it:

import { createAuthClient } from "better-auth/react";

export const authClient = createAuthClient({
  baseURL: "http://localhost:3000",
});

This small utility will give us type-safe methods for signing in, signing up and checking sessions.

Email and Password Authentication

Now let’s build the authentication forms. We’ll create two components: one for sign-up and one for sign-in.

Sign-up Form

Create a file named components/sign-up.tsx and add the following to it:

// components/sign-up.tsx
"use client";

import { useState } from "react";
import { authClient } from "@/lib/auth-client";
import { useRouter } from "next/navigation";

export default function SignUp() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [name, setName] = useState("");
  const [isLoading, setIsLoading] = useState(false);
  const router = useRouter();

  const signUp = async () => {
    await authClient.signUp.email(
      {
        email,
        password,
        name,
      },
      {
        onRequest: () => {
          setIsLoading(true);
        },
        onSuccess: () => {
          router.push("/dashboard");
        },
        onError: (ctx) => {
          alert(ctx.error.message);
          setIsLoading(false);
        },
      }
    );
  };

return (
  <div className="flex flex-col gap-4 w-full max-w-md mx-auto mt-10 border border-gray-200 p-6 rounded-lg shadow-sm bg-white">
    <h1 className="text-xl font-bold text-gray-900">Create Account</h1>

    <div className="flex flex-col gap-2">
      <label className="text-sm font-medium text-gray-700">Name</label>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="John Doe"
        className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
      />
    </div>

    <div className="flex flex-col gap-2">
      <label className="text-sm font-medium text-gray-700">Email</label>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="user@example.com"
        className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
      />
    </div>

    <div className="flex flex-col gap-2">
      <label className="text-sm font-medium text-gray-700">Password</label>
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="••••••••"
        className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
      />
    </div>

    <button
      onClick={signUp}
      disabled={isLoading}
      className={`mt-2 p-2 rounded text-white font-medium transition-colors ${
        isLoading
          ? "bg-gray-400 cursor-not-allowed"
          : "bg-black hover:bg-gray-800"
      }`}
    >
      {isLoading ? "Creating an account..." : "Sign Up"}
    </button>
  </div>
);