Add full-text search across catalog entries — lab audio overview

Host: Welcome back to AI Developer Platform Engineering. This is the chapter on Internal Developer Platform Vision — the idea that a central team builds the tools, templates, and self-service systems that every other engineer in the company uses to ship software. Today's skill — making a catalog of services searchable — is one of those things that sounds small but completely changes how people use your platform. Expert: Picture a mid-size company, maybe eight hundred engineers, thirty product teams. The platform team has built what's called a service catalog — basically a living directory of every service, every machine-learning model, every shared library the company runs. Think of it like an internal phone book for software. When it has a hundred entries, people browse it. When it has two thousand, nobody browses anything. They open the page, and if they can't find what they want in about three seconds, they give up and ask in Slack, which defeats the whole point of having a catalog. Without fast, forgiving search, your beautiful platform becomes shelfware. This is the moment where a platform team either earns trust — "the catalog actually works, just type what you want" — or loses it. And the exercise you're about to do is exactly that moment. You're adding real search to the catalog. Host: In the previous exercise, you built the part that lists catalog entries one page at a time, using a bookmark-style approach so that even a huge catalog stays fast and stable as people scroll. Now you're extending that same catalog. So what exactly are we building this time? Expert: You're building three things that work together as one search experience. First, full-text search — meaning someone types a few words, like "payment fraud model," and the system looks across the names, descriptions, and tags of every catalog entry and returns the ones that match, sorted by how relevant they are. Relevance ranking just means the closest matches come first, not a random order. Second, prefix matching for autocomplete — that's the thing where you start typing "pay" and a dropdown instantly suggests "payments-api," "payment-fraud-model," "payout-service." It has to feel instant, which means it runs on every keystroke. Third, combined search with structured filters — meaning the user can type free text and also narrow by category, like "only show me services owned by the data team, written in Python, that match the word billing." Free text plus structured filters, working together in one query. The key idea to hold in your head is this: search is not one feature. It's a ranked, filtered, partial-match experience, and all three pieces have to cooperate. The database you're working with already has tools for this built in — you don't write the ranking math yourself, you tell the database what to rank. Host: Alright, before people dive in — what's the part that trips most engineers up on their first attempt at this? Expert: The thing that catches people is mixing up two very different jobs — ranking and filtering — and trying to do them with the same tool. Full-text ranking is fuzzy. It asks, "how well does this text match those words?" and returns a score. Filtering is exact. It asks, "is the owner equal to the data team, yes or no?" If you try to express an exact filter as a fuzzy text match, you get wrong results — a service owned by "data-platform" will leak into results for the "data" team. The fix is to keep them in separate lanes: run the fuzzy text match to get a relevance score, apply the exact filters as a hard yes-or-no gate, and then combine them. The other small trap is autocomplete. Regular full-text search usually needs whole words — if someone types "pay," a strict word match returns nothing, because "pay" isn't a complete word in any entry. So autocomplete needs prefix matching, which is a different mode. Watch out for that split: full words for the main search box, prefixes for the dropdown suggestions. Host: Last thing — what will you walk away able to do, and where does this go next? Expert: After this exercise, you'll be able to take any catalog of structured records in your company — services, models, datasets, runbooks, anything — and give it a search experience that actually feels like a modern search box. Fuzzy matching, ranked results, instant autocomplete, and sharp filters layered on top. That's a building block your platform team can reuse everywhere: the model registry, the dataset catalog, the internal documentation portal, the incident search. It's the same pattern every time. In the next and final exercise in this sequence, you'll add versioning to the catalog using something called ETags — basically digital fingerprints on each entry that let clients ask "has this changed since I last looked?" and also prevent two people from overwriting each other's edits. Together, the three exercises — pagination, search, and versioning — give you a production-grade catalog API you can bring straight back to your team's platform design. Good luck, and thanks for listening.