code example

Build Similar Items with altor-vec

What this pattern solves: More-like-this retrieval for catalogs, playlists, and content grids.

Users often discover what they want by starting from one good item and asking for nearby options. A vector index gives you a fast semantic neighborhood lookup that feels natural in browsing-heavy products.

Because the query can be the item's own vector, similar-item retrieval is cheap once the local index exists. That makes it a strong fit for static catalogs and collections with high browse-to-search behavior.

Install

npm install altor-vec

Concept explanation

In a similar items workflow, users usually describe intent in their own words. That is why vector search works well here: each record is turned into an embedding, the embeddings are indexed once, and later queries retrieve the nearest semantic neighbors instead of relying only on exact tokens. In practice this means the interface can respond to paraphrases, shorthand, and partial descriptions far better than a literal-only search box.

The browser is often the right place to do this when the corpus is moderate in size and safe to ship. The instant benefit is lower latency. The architectural benefit is that you remove a whole search service from the request path. That matters for keystroke-heavy interactions, offline-capable apps, and product surfaces where search should feel like a UI primitive rather than a network round trip.

This page uses a deterministic embedding helper so the sample is runnable with only altor-vec installed. That keeps the example honest and easy to paste into a demo project. This pattern is close to recommendation retrieval, but the UI trigger is different: the starting point is an existing item rather than an open-ended user query.

Runnable JavaScript example

The following snippet indexes a small in-memory dataset, performs a semantic lookup for linen short sleeve button up, and prints the nearest matches. It uses the real altor-vec API, including init(), WasmSearchEngine.from_vectors(), and search().

import init, { WasmSearchEngine } from 'altor-vec';

        const dims = 12;
        const records = [
  {
    "title": "Linen camp shirt",
    "text": "Breathable short-sleeve shirt for warm weather with relaxed fit.",
    "meta": "apparel"
  },
  {
    "title": "Cotton oxford shirt",
    "text": "Structured button-down shirt for office and casual wear.",
    "meta": "apparel"
  },
  {
    "title": "Seersucker resort shirt",
    "text": "Light textured shirt with airy fabric and vacation styling.",
    "meta": "apparel"
  },
  {
    "title": "Merino travel tee",
    "text": "Odor-resistant lightweight t-shirt for packing light.",
    "meta": "apparel"
  },
  {
    "title": "Drawstring summer shorts",
    "text": "Soft shorts with stretch waist and side pockets.",
    "meta": "apparel"
  },
  {
    "title": "Canvas overshirt",
    "text": "Heavier layer for cool evenings and transitional weather.",
    "meta": "apparel"
  }
];

        function embedText(text) {
  const vector = new Float32Array(dims);
  for (const token of text.toLowerCase().split(/[^a-z0-9]+/).filter(Boolean)) {
    let hash = 2166136261;
    for (const char of token) {
      hash = Math.imul(hash ^ char.charCodeAt(0), 16777619);
    }
    const slot = Math.abs(hash) % dims;
    vector[slot] += 1;
    vector[(slot + token.length) % dims] += token.length / 10;
  }
  const magnitude = Math.hypot(...vector) || 1;
  return Array.from(vector, (value) => value / magnitude);
}

        async function main() {
          await init();

          const flat = new Float32Array(
            records.flatMap((record) => embedText(`${record.title} ${record.text} ${record.meta}`))
          );

          const engine = WasmSearchEngine.from_vectors(flat, dims, 16, 200, 64);
          const hits = JSON.parse(engine.search(new Float32Array(embedText('linen short sleeve button up')), 4));

          const results = hits.map(([id, distance]) => ({
            ...records[id],
            similarity: Number((1 - distance).toFixed(3)),
          }));

          console.table(results);
          engine.free();
        }

        main();

React component version

The React version keeps the same index build but wires it into component state so the UI can query on input changes. That is usually how teams introduce semantic retrieval into an existing product: initialize once, keep the engine in memory, and map nearest-neighbor hits back to the original records.

import { useEffect, useState } from 'react';
        import init, { WasmSearchEngine } from 'altor-vec';

        const dims = 12;
        const records = [
  {
    "title": "Linen camp shirt",
    "text": "Breathable short-sleeve shirt for warm weather with relaxed fit.",
    "meta": "apparel"
  },
  {
    "title": "Cotton oxford shirt",
    "text": "Structured button-down shirt for office and casual wear.",
    "meta": "apparel"
  },
  {
    "title": "Seersucker resort shirt",
    "text": "Light textured shirt with airy fabric and vacation styling.",
    "meta": "apparel"
  },
  {
    "title": "Merino travel tee",
    "text": "Odor-resistant lightweight t-shirt for packing light.",
    "meta": "apparel"
  },
  {
    "title": "Drawstring summer shorts",
    "text": "Soft shorts with stretch waist and side pockets.",
    "meta": "apparel"
  },
  {
    "title": "Canvas overshirt",
    "text": "Heavier layer for cool evenings and transitional weather.",
    "meta": "apparel"
  }
];

        function embedText(text) {
  const vector = new Float32Array(dims);
  for (const token of text.toLowerCase().split(/[^a-z0-9]+/).filter(Boolean)) {
    let hash = 2166136261;
    for (const char of token) {
      hash = Math.imul(hash ^ char.charCodeAt(0), 16777619);
    }
    const slot = Math.abs(hash) % dims;
    vector[slot] += 1;
    vector[(slot + token.length) % dims] += token.length / 10;
  }
  const magnitude = Math.hypot(...vector) || 1;
  return Array.from(vector, (value) => value / magnitude);
}

        export function SimilarItemsExample() {
          const [engine, setEngine] = useState(null);
          const [query, setQuery] = useState('');
          const [results, setResults] = useState([]);

          useEffect(() => {
            let cancelled = false;
            let instance;

            (async () => {
              await init();
              const flat = new Float32Array(
                records.flatMap((record) => embedText(`${record.title} ${record.text} ${record.meta}`))
              );
              instance = WasmSearchEngine.from_vectors(flat, dims, 16, 200, 64);
              if (!cancelled) setEngine(instance);
            })();

            return () => {
              cancelled = true;
              instance?.free();
            };
          }, []);

          useEffect(() => {
            if (!engine || query.trim().length < 2) {
              setResults([]);
              return;
            }

            const hits = JSON.parse(engine.search(new Float32Array(embedText(query)), 5));
            setResults(
              hits.map(([id, distance]) => ({
                ...records[id],
                similarity: Number((1 - distance).toFixed(3)),
              }))
            );
          }, [engine, query]);

          return (
            <section>
              <input
                value={query}
                onChange={(event) => setQuery(event.target.value)}
                placeholder="Describe an item or reuse an existing vector"
              />
              <ul>
                {results.map((result) => (
                  <li key={result.title}>
                    <strong>{result.title}</strong> — {result.meta} (score {result.similarity})
                  </li>
                ))}
              </ul>
            </section>
          );
        }

How this example works

The pattern has three moving parts. First, you choose what text represents each record: title, description, metadata, or a chunk of content. Second, you turn that text into vectors and flatten them into one Float32Array. Third, you build the HNSW graph and query it with a vector created from the user input. The library returns nearest-neighbor IDs and distances, and your app decides how to display or post-process them.

Because the retrieval step is approximate nearest-neighbor search, it stays fast even as the dataset grows beyond trivial linear scans. The most important quality lever is still the embedding model. Better vectors usually matter more than micro-optimizing ANN parameters, so teams should benchmark retrieval quality on real user phrasing before shipping the experience widely.

When to use this pattern

This is a practical fit when the search corpus is small to medium, shipped with the app, and searched frequently enough that backend latency would be noticeable. Common examples include docs portals, embedded support widgets, local-first assistants, and curated catalogs.

• More like this modules
• Playlist expansion
• Article related reads
• Marketplace browsing

Limitations

Similarity alone can create repetitive results. Many products add diversity rules, stock checks, or popularity signals to keep the recommendations useful and commercially sensible.

Be especially careful about corpus size, update frequency, and data sensitivity. Browser vector search is excellent when those three constraints are favorable, but it is not the right answer when the dataset is huge, private, or changing constantly for every user.

FAQ

How is this different from recommendation-engine pages?

The retrieval mechanics are similar, but similar-items usually starts from one known item instead of a free-form shopper query.

Can I precompute 'related items' offline?

Yes. Many teams build the index ahead of time and query it instantly in the browser at render time.

What usually improves result quality the most?

Better embeddings plus post-filters for category, price, availability, and diversity.

Get started: npm install altor-vec · GitHub