SLSearch Technical Overview

In earlier versions, SLSearch only supported a single rich result, which was a Wikipedia-based knowledge graph.

The feature was initially processed entirely on the server, where the backend fetched and rendered the data before returning the final response.

While functional, this approach introduced a few issues:

• Additional server-side fetching and processing
• Increased response times, even when no valid Wikipedia result was available
• Unnecessary load placed on the backend

To address these issues, rich results were migrated from the backend to the frontend.

Since Wikipedia data can be fetched directly without CORS restrictions, the information can be processed and rendered client-side.

However, moving rich results to the frontend also introduced its own set of limitations:

• CORS-related issues are encountered frequently
• Increased reliance on third-party CORS proxy services
• API key–protected services cannot be used, as keys cannot be securely stored on the client side

While frontend processing presents various limitations, it significantly reduces search latency, keeps the backend lightweight, and preserves informative results for users without sacrificing server performance.

An additional benefit of this approach is improved user control.

Since rich features are processed client-side, users can enable or disable individual features without requiring the server to track feature preferences and alter responses.

Previously, SLSearch relied entirely on keyword-based matching to determine when certain feature panels should be displayed.

While simple, this approach had several issues:

• Queries in other languages, such as Chinese, would fail to trigger anything
• Maintaining keyword lists for every language was impractical

To address these issues, instead of relying solely on the query text, SLSearch now also analyzes the search results.

By scanning result sources and identifying recurring well known websites, the system can reliably deduce the nature of the query.

In addition, SLSearch evaluates which words appear most frequently across the results.

This fuzzy scoring approach allows feature panels to be activated even when the query language varies.

This system is used in features such as weather, dictionary, flight, and finance panels.