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.

Filtering vs Search
Filtering: Exact or structured conditions
Examples include category, status, date ranges, and boolean conditions.
Search: Text and relevance
Often requires indexing, tokenization, ranking, and relevance calculations.
Key Takeaways
  • 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.
Knowledge Check

Why might a production application use a dedicated search engine instead of a simple database filter?