Should searching a few letters of an arcade name require downloading every arcade first? Searching inside the browser needs a comparison list. That is straightforward for a small collection, but as the service approaches 300 venues, it also transfers more places the user will never search for.

Gamma moves keyword matching to the server and returns relevant venues. Search and nearby-distance calculations were receiving similar data through separate APIs, making the search download a useful place to reduce repeated transfer.

Preparation costs of browser search

Browser search compares typed text against a previously received list. Even when someone wants one venue, the browser needs all candidates before it can decide where the match is. Matching after input is simple, but preparation grows with the whole collection.

The existing screen separately fetched search data and data for distance calculations. Repeating the same venues in large responses adds work for people merely opening the initial page. The transferred scope had become broader than the result needed.

The previous Beta search screen, reproduced from the 2023-12-25 code with sample data. Queries were compared against the downloaded list. Original Korean screen; Beta supported Korean only.

flowchart TD
    accTitle: Preparation cost of the previous search
    accDescr: The browser downloaded all data, then selected results using the entered query.
    A["Transfer the full arcade list"] --> B
    B["Prepare list in browser"] --> C
    C["Filter results by query"]

A keyword search API

An API is the route through which the interface requests work from the server. The search API receives a keyword, finds related arcades and returns them. Server queries replace comparisons against a complete list in the browser.

This reduces the need to prepare every venue before finding one. It also makes searches depend on requests, so removing the full download introduces another consideration: how often typing should trigger communication.

flowchart TD
    accTitle: Keyword-based requests
    accDescr: When the input settles, send the keyword and receive only relevant venues.
    A["Enter query"] --> B
    B["Wait for input to settle"] --> C
    C["Send keyword to server"] --> D
    D["Display relevant results"]

Input delays and result queries

Search terms are typed over time. Sending every intermediate string while someone enters a name would produce responses for unfinished input as well as the intended term. We wait briefly for the value to remain unchanged before querying, a technique called debouncing.

The interface manages the current term and displays the returned results. This migration covers search; it does not move every Home distance calculation to the server. Those two uses of arcade data still need separate improvements.

flowchart TD
    accTitle: This change and remaining distance work
    accDescr: Reduce search’s dependency on the full list, leaving the home page’s distance calculation as separate work.
    A["Dedicated search request"] --> B
    B["Remove full-list search transfer"] --> C
    C["Home distance calculation remains separate"]

Initial loading and network dependence

We observed about one second less initial loading during this change, following removal of the full search-list preparation. That is an observation from this work, rather than an identical saving expected across devices and networks.

Server search depends on network latency and successful responses. Rapidly changing input also requires keeping results associated with the right term. Incorrect names, aliases or outdated venue data can still prevent useful matches even after transfer volume falls.

Reference: Musecat engineering history.

Related updates

• Recent Feedback Responses and Musecat δ8 Update