## Problem Currently, the engine does not expose a dedicated `globalSearch` API. However, most list queries already support a `queryString` parameter independently (`products`, `users`, `orders`, `assortments`, etc.). Because of this, the admin UI can already simulate a global search by running multiple parallel GraphQL queries and merging the results client-side. While functional, this approach has several drawbacks: * Increased network overhead * More client-side complexity * Duplicate query orchestration logic * Harder ranking/relevance handling * Slower command-palette/search UX due to multiple round trips Example today: ```graphql products(queryString: "john") users(queryString: "john") orders(queryString: "john") assortments(queryString: "john") ``` followed by client-side normalization + aggregation. --- ## Proposed Solution Introduce a dedicated GraphQL endpoint: ```graphql globalSearch( query: String!, types: [SearchableEntity!] ): [SearchResult!]! ``` Example: ```graphql query { globalSearch( query: "john", types: [PRODUCT, USER, ORDER] ) { __typename ... on Product { id name } ... on User { id email } ... on Order { id orderNumber } } } ``` --- ## Suggested Types ```graphql enum SearchableEntity { PRODUCT USER ORDER ASSORTMENT } ``` ```graphql union SearchResult = Product | User | Order | Assortment ``` --- ## Expected Benefits ### Better UX * Faster command palette/global search experience * Single request instead of N parallel requests * Easier debouncing/cancellation ### Cleaner Frontend * Removes duplicated aggregation logic from admin-ui * Centralized ranking and scoring possible in engine * Easier future extensibility ### Small Engine Change The underlying search capability already exists through `queryString` on entity lists Implementation could internally delegate to existing list search methods and merge results server-side. --- ## Potential Future Enhancements * Result scoring / relevance ranking * Pagination/cursor support * Per-type limits * Highlight/snippet support * Weighted entity prioritization * Search analytics --- ## Temporary Workaround Current admin-ui workaround: * Execute multiple list queries in parallel * Normalize results client-side * Merge into a unified search result set This works today, but a dedicated API would significantly simplify implementation and reduce latency.