Designing Search in GraphQL
Search is different from simple filtering.
Filtering asks questions such as:
category = ELECTRONICS
price >= 1000
isActive = true
Search may ask for relevance across text:
Find products matching "wireless mechanical keyboard"
A GraphQL schema can expose:
products(search: "wireless keyboard") {
edges {
node {
id
name
}
}
}
But the GraphQL schema should not dictate how search is implemented.
Possible backends include:
- MongoDB text search
- MongoDB Atlas Search
- Elasticsearch
- OpenSearch
- PostgreSQL full-text search
- A dedicated search service
Search systems often provide relevance scoring, stemming, typo tolerance, tokenization, ranking, and autocomplete features that simple database filters do not.
For large systems, the GraphQL service may query a dedicated search index and then load full domain objects from the primary database.
The important architectural principle is that GraphQL exposes a stable search capability while the implementation can evolve independently.
Exact or structured conditionsText and relevance- Filtering and search solve different problems.
- Search can require specialized infrastructure.
- The GraphQL schema should hide search implementation details.
- Large search workloads may use a dedicated search index.
Why might a production application use a dedicated search engine instead of a simple database filter?