tutorialrecommendationmicroapps

Build a Restaurant Chooser Micro App: fuzzy matching, group preferences, and ranking

ffuzzy

2026-01-31

11 min read

Ship a restaurant micro app: fuzzily match names, aggregate group preference vectors, and rank with embeddings for fast, accurate recommendations.

Stop losing group plans to bad search. Build a fast dining micro app that understands fuzzy inputs, aggregates group tastes, and ranks recommendations with lightweight embeddings.

Decision friction in group chats is real: misspelled restaurant names, vague requests (“somewhere spicy”), and clashing tastes stall the plan. In 2026 the tools to solve that—on-device inference, hybrid vector search, lightweight embeddings, and efficient fuzzy matching—are cheap and practical. This guide walks you through a production-ready micro app: fuzzy match user inputs to places, aggregate group preferences, and rank suggestions using embeddings. Expect full code snippets, SQL, and deployment notes so you can ship in days, not months.

What you’ll build (and why it matters in 2026)

We’ll create a small web micro app (server + client) that:

Fuzzily matches user-typed place names and aliases (client+server approaches).
Aggregates group preferences into a single group vector for semantic matching.
Ranks results by combining fuzzy score, embedding similarity, popularity, and distance.
Is deployable with Postgres + pg_trgm for trigram fuzzy search, pgvector (or Milvus/Pinecone) for embeddings.

"Micro apps" and fast prototypes exploded in 2025–2026—people now build tools they actually use. This dining micro app is intentionally small, focused, and deployable.

Architecture overview

Keep the architecture minimal and composable. The pattern below balances simplicity with production needs:

Client (React/Vue/Svelte): quick fuzzy matching and results UI.
API (Node/Express or FastAPI): orchestrates fuzzy search, vector similarity, and ranking.
Database: Postgres + pg_trgm for trigram fuzzy search, pgvector (or Milvus/Pinecone) for embeddings.
Embedding provider: hosted (OpenAI, Anthropic) or local lightweight model (sentence-transformers / ONNX).
Cache: Redis for precomputed group vectors and hot results.

Flow (high level)

User types a query (e.g., "Juans Tacos" or "vegan pizza").
Client runs a fast fuzzy suggestion (Fuse.js) to surface exact candidates immediately.
Server receives the final query and group member IDs; it fetches member preferences and computes a group preference vector.
Server gets candidate set (fuzzy + category filter), computes embedding similarities via pgvector or vector DB, applies final ranking formula, and returns top N.

Data model

Minimal schema for restaurants and users. Use Postgres with pgvector for vectors.

-- restaurants table
  CREATE TABLE restaurants (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    aliases TEXT[],           -- common misspellings, short names
    address TEXT,
    lat DOUBLE PRECISION,
    lon DOUBLE PRECISION,
    categories TEXT[],        -- e.g. ['mexican', 'tacos']
    popularity FLOAT DEFAULT 0, -- normalized metric
    vec VECTOR(1536)          -- embedding (adjust dim to your model)
  );

  -- users & preferences
  CREATE TABLE users (
    id UUID PRIMARY KEY,
    display_name TEXT,
    prefs JSONB               -- e.g. {"cuisines": {"mexican":2, "vegan":1}, "price": 2}
  );

Fuzzy matching—client-first and server fallbacks

Fuzzy matching should be instant in the UI. Use a lightweight client-side library for immediate feedback and keep server-side fuzzy as the authoritative source for final ranking.

Client-side: Fuse.js (fast, local)

// React example: run this on the client for instant suggestions
  import Fuse from 'fuse.js'

  const options = {keys: ['name', 'aliases'], threshold: 0.3}
  const fuse = new Fuse(restaurantsIndex, options)
  const suggestions = fuse.search(query).slice(0, 6).map(r => r.item)

Fuse gives instant UX. But fuse’s ranking is based on edit-distance & weighting, not semantics—so use embeddings server-side.

Server-side: Postgres trigram (pg_trgm) for authoritative fuzzy scores

-- enable extension
  CREATE EXTENSION IF NOT EXISTS pg_trgm;

  -- a query to find fuzzy matches on name and aliases
  SELECT id, name,
         GREATEST(similarity(name, $1),
                  (SELECT MAX(similarity(alias, $1)) FROM unnest(aliases) alias)) AS fuzzy_score
  FROM restaurants
  WHERE name % $1 OR EXISTS(SELECT 1 FROM unnest(aliases) a WHERE a % $1)
  ORDER BY fuzzy_score DESC
  LIMIT 100;

Use trigram for misspellings; return the fuzzy_score (0–1) to merge with semantic scores.

Lightweight embeddings: options for 2026

By 2026 there are two practical options: hosted embeddings (very convenient) or local lightweight models (cheap and private). For micro apps you’ll often pick one of these:

Hosted: OpenAI or Anthropic embeddings. Easier to integrate, pay-per-call, latency depends on network.
Local: small S-BERT or 1–3B models exported to ONNX / quantized. Fast on CPU with ONNX Runtime or WASM for on-device. Good for privacy and predictable cost. See hardware benchmarks for on-device embedding performance (e.g. AI HAT+ 2).

Compute embeddings (Node + OpenAI example)

import OpenAI from 'openai'
  const client = new OpenAI({ apiKey: process.env.OPENAI_KEY })

  // compute embedding for a restaurant description or user preference text
  const embed = async (text) => {
    const res = await client.embeddings.create({ model: 'text-embedding-3-small', input: text })
    return res.data[0].embedding // Float32[]
  }

Local compute (Python) — batch creating vectors

# Using sentence-transformers (local) for batch embeddings
  from sentence_transformers import SentenceTransformer
  import numpy as np

  model = SentenceTransformer('all-MiniLM-L6-v2')
  texts = [r['name'] + ' ' + ' '.join(r['categories']) for r in restaurant_rows]
  vecs = model.encode(texts, show_progress_bar=True)
  # store vecs in pgvector via psycopg2

Pick a dimension you can support—384 or 768 are common for tiny models; 1536 appears with some hosted providers. Make your vec column match.

Aggregating group preferences into a single vector

A core trick: represent each user's preferences as a vector then aggregate to make a group preference vector. Use either:

Text-based preference embeddings: embed natural-language summaries of each user's tastes (e.g., "likes spicy Mexican, dislikes seafood"), or
Feature-level vectors: map categorical preferences (cuisines, price) to one-hot or learned vectors and combine with embeddings.

Why embeddings for group prefs?

Embedding vectors capture nuance—"prefers spicy Mexican" sits closer to taco restaurants than simply the word "Mexican" would. Aggregation is a weighted average; you can weight by recency or a user-specified priority.

Example aggregation (Node)

import { dot } from 'vector-math' // hypothetical helper

  // given per-user preference text
  async function computeGroupVector(members) {
    // members = [{id, weight}] weight is importance in decision (default 1)
    const embeds = await Promise.all(members.map(async m => {
      const text = await fetchUserPreferenceText(m.id) // e.g. "vegan, casual, close"
      const e = await embed(text)
      return { vec: e, weight: m.weight ?? 1 }
    }))

    // weighted average
    const dim = embeds[0].vec.length
    const group = new Array(dim).fill(0)
    let totalW = 0
    for (const e of embeds) {
      totalW += e.weight
      for (let i=0;i<dim;i++) group[i] += e.vec[i] * e.weight
    }
    for (let i=0;i<dim;i++) group[i] /= Math.max(totalW, 1)
    return group
  }

Ranking: combine fuzzy scores, embedding similarity, and business signals

Ranking is the most important place to iterate. A pragmatic formula blends both exact/fuzzy matching and semantic matching:

final_score = α * embedding_sim + β * fuzzy_score + γ * popularity_norm - δ * distance_norm + ε * recency_bonus

Recommended starting weights (tweak by A/B test): α=0.6, β=0.2, γ=0.15, δ=0.05. If query is an explicit place name (high fuzzy_score), raise β.

Implementation: similarity via pgvector

-- using pgvector cosine similarity (higher = better)
  SELECT id, name,
         (1 - (vec <#> $1::vector)) AS embedding_sim, -- if using cosine distance operator
         fuzzy_score
  FROM (
    SELECT r.*, 
           GREATEST(similarity(name, $2), (SELECT MAX(similarity(a,$2)) FROM unnest(aliases) a)) AS fuzzy_score
    FROM restaurants r
    WHERE categories && $3::text[] -- optional filter
  ) r
  ORDER BY (0.6 * (1 - (r.vec <#> $1)) + 0.2 * r.fuzzy_score + 0.15 * popularity) DESC
  LIMIT 20;

// POST /recommend { query: 'Juans Tacos', members: [{id, weight}], location: {lat,lng} }
  app.post('/recommend', async (req, res) => {
    const { query, members, location, categories } = req.body

    // 1. early client-side suggestion already returned; server now computes authoritative list
    const groupVec = await computeGroupVector(members)
    const queryEmb = await embed(query)

    // 2. build candidate set: use trigram to filter + top 200 by fuzzy
    const fuzzyCandidates = await db.query(FUZZY_SQL, [query, categories])

    // 3. fetch vectors for candidate ids and compute combined score
    const rows = await db.query(SELECT_VECS_SQL, [candidateIds])

    const scored = rows.map(r => {
      const embSim = cosineSim(groupVec, r.vec)
      const qSim = cosineSim(queryEmb, r.vec)
      const fuzzy = r.fuzzy_score || 0
      const popularity = r.popularity
      const dist = haversine(location, {lat: r.lat, lon: r.lon})

      const final = 0.55 * embSim + 0.15 * qSim + 0.2 * fuzzy + 0.08 * popularity - 0.02 * normalizeDistance(dist)
      return {...r, final}
    })

    scored.sort((a,b) => b.final - a.final)
    res.json(scored.slice(0,10))
  })

Performance & deployment considerations

Batch embedding: compute embeddings for restaurants ahead of time and on updates. Run nightly jobs for new rows.
Cache group vectors: store in Redis keyed by hashing member IDs + weights to avoid recomputation for repeated meetings. For edge caching patterns and indexing, see discussions on edge indexing and privacy-first sharing.
Candidate filtering: always narrow by categories, distance, or fuzzy-first. Embedding nearest-neighbor across millions is expensive; keep candidate set small (100–500) and rerank.
Vector store: for <10k restaurants, pgvector inside Postgres is fine. At scale, use Milvus, Weaviate, or Pinecone with hybrid search (ANN + exact rerank). See notes on scaling storefronts and edge performance for comparable operational tradeoffs: Shopfront to Edge.
Local vs hosted embeddings: For groups with privacy concerns or high volume, run embeddings local (quantized models) in 2026 are cheaper than hosted calls for steady traffic. Hardware benchmarks (e.g., small on-device boards) are helpful when choosing models and runtimes: AI HAT+ 2 benchmark.

UX recommendations

Show the fuzzy match confidence (e.g., "Did you mean: Juan's Tacos?") when fuzzy score is low but candidates exist.
Let group members weight their importance when the vote matters (slider for influence).
Provide a short "why" snippet per result: highlight matching prefs e.g., "Great for spicy tacos—3 members liked spicy Mexican."
Allow fast re-ranking in the UI (more distance, cheaper, vegan-only) and show immediate client-side filtering for responsiveness.

Operational concerns: monitoring and fairness

Track these metrics after launch:

Latency (P95 for /recommend). For playbooks and runbooks around search incidents and observability, see Site Search Observability & Incident Response.
Click-through rate on top-1 recommendation.
Conversion to reservations or navigation actions.
Feedback signals: thumbs up/down for explanations—use to adjust popularity and retrain models.

Guard against feedback loops (popularity spirals) by decaying popularity signals over time and exposing some exploration in the top-5 results.

Deployment: minimal Docker Compose

version: '3.8'
  services:
    db:
      image: postgres:15
      environment:
        POSTGRES_PASSWORD: example
      volumes:
        - ./pgdata:/var/lib/postgresql/data
    api:
      build: ./api
      environment:
        DATABASE_URL: postgres://postgres:example@db/postgres
        OPENAI_KEY: ${OPENAI_KEY}
      depends_on: [db]

Run a background worker to compute embeddings and keep vectors up-to-date. Use pg_trgm and pgvector extensions in your Postgres image or a managed Postgres with extensions enabled. If you want a ready-made starter repo and Docker Compose for this pattern, see the micro-app starter guidance at Build a Micro-App Swipe.

2026 Trends & future directions (what to watch)

On-device embeddings: In 2025–2026, cheap quantized models and WASM runtimes made on-device embedding feasible for mobile micro apps. This reduces API costs and improves privacy—benchmarks like AI HAT+ 2 are useful when evaluating hardware.
Hybrid search: Vector DBs now natively support trigram/hybrid scoring—expect faster end-to-end queries when combining fuzzy and semantic logic in the DB. For incident playbooks and search observability, review Site Search Observability.
LLM-augmented explanations: Small LLMs can summarize "why" a place fits the group—embed these explanations for transparency and better UX. Consider autonomous desktop AIs and orchestration patterns in research such as Using Autonomous Desktop AIs (Cowork) for orchestration ideas.
Composable micro apps: Micro apps in 2026 are often built as small composable pieces—preferences service, search service, and suggester—so you can swap a hosted vector DB for a local one easily. Edge-optimized pages and caching are becoming common; see Edge-Powered Landing Pages for related performance strategies.

Advanced strategies

Personalized time-of-day boosts: Rank brunch spots higher in the morning for users that frequently choose them. Store short-term signals and bias ranking.
Embedding hybridization: Blend static restaurant embeddings with dynamic context (current weather, events) by concatenating short context embeddings and re-normalizing.
Cold-start groups: If no prefs exist, seed group vector with popularity and distance priors, then encourage quick preferences from users to personalize faster.

Security, privacy, and costs

Minimize PII in embeddings (avoid sending raw user messages to hosted APIs unless consent is explicit). For cost control, cache embeddings for repeated queries, use smaller models for queries, and batch embedding jobs. For hardening local AI agents and minimizing data exposure, review guidance on hardening desktop AI agents.

Actionable takeaways

Start with a small dataset and use Fuse.js for immediate UX while implementing server-side pg_trgm and pgvector for authoritative search.
Represent user tastes as text, compute lightweight embeddings, and aggregate them via weighted average for group vectors.
Use a transparent ranking formula combining embedding_sim and fuzzy_score and tune weights with A/B tests. Track experiment metrics and incident signals with a search observability playbook: site search observability.
Precompute and cache embeddings for restaurants; batch update periodically. Consider edge caching and indexing strategies from the edge indexing playbook.

Conclusion & next steps

Building a restaurant chooser micro app in 2026 is tractable: inexpensive embedding models, mature hybrid search options, and simple fuzzy tooling let you ship a delightful group recommender quickly. Start client-first (Fuse.js), add server-side trigram checks, compute group vectors, and use a combined ranking formula. Measure, iterate, and consider on-device embeddings to cut cost and increase privacy.

Ready to ship? Clone the starter repo (server + client + DB scripts), deploy to a small cloud instance, and run the background embedding job. If you want, I can generate the exact starter code for your preferred stack (Node or Python) and a Docker Compose you can run locally—tell me your stack and I’ll scaffold it.

Call to action

Try the minimal proof-of-concept: implement client Fuse.js suggestions, add pg_trgm fuzzy on the server, and compute user preference embeddings. If you want a ready-made repo scaffolded for Express + Postgres + pgvector (or FastAPI + Milvus), ask now and I’ll generate it with full deployment scripts.

fuzzy

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.