The expensive part of federated search was never the query fan-out.
It's the N integrations behind it, each with its own API, auth, query
syntax, and response format. SWIRL's answer is to make each integration a configuration object called a SearchProvider, and the 66-second video above walks through one in the admin tool.
The anatomy, per provider:
- Connection: which connector to use (HTTP GET/POST returning JSON, M365 Graph, SQL, Elastic DSL, ...), the endpoint, and the authenticator that supplies each user's credentials at query time.
- Query: a template that maps SWIRL's query into the source's own syntax, plus query processors that adapt it automatically (synonyms, rewrites, source-specific quirks).
- Results: JSONPath-style mappings that normalize each source's response into a common result shape: title, body, author, date, URL. This is what makes cross-source ranking honest; every result competes in the same schema, re-ranked by the same three-pass pipeline.
Because providers are rows, not code, the workflow is: activate a
preloaded provider (M365, Box, ServiceNow, Elastic, PostgreSQL,
BigQuery, and dozens more ship in the box), add credentials, search.
Change a mapping and the next query uses it; there is no deploy step.
Example provider JSON: https://github.com/swirlai/swirl-search/tree/main/SearchProviders
Top comments (0)