Proposal: Search Gateway

Proposal

  1. make a golang search client that is capable of doing concurrent search requests (federated search)
    • example: one request goes to self managed and another goes to gitlab.com
    • another example: one request goes to elasticsearch cluster and another goes to opensearch cluster
  2. make a "Search Gateway" that runs alongside rails. It would be a lightweight golang REST API for our search client.
    • for SaaS, the Search Gateway would just send searches to the existing elasticsearch cluster
                     REST API
RAILS ───────────► SEARCH GATEWAY
                        ▲┐        ┌───────────►  DATASTORE
                        └▼        │
                                  │
                  (SEARCH CLIENT)─┼───────────►  DATASTORE
                                  │
                                  │
                                  └───────────►  DATASTORE

What this could potentially give us (top of mind):

  • federated search
  • decouples us from elasticsearch gem inside rails
  • helps with opensearch/elasticsearch compatability

Things to consider:

  • Adding another "hop" between rails and elasticsearch (rails -> search gateway -> elasticsearch) could add some latency, but if the search gateway is co-located with rails the latency add would most likely be minimal.
  • We could consider routing requests with prefix of /search and /api/v4/search directly from loadbalancer to search gateway to reduce latency but incur complexity (authentication, etc)

cc @JohnMcGuire

Edited by John Mason