Sorry, I’m not clear on what you’re proposing. Is your goal to (A) make the existing LMS courseware search work with meilisearch instead of Elasticsearch, (B) implement a new “auto-suggest” courseware search feature using Meilisearch/edx-search, (C) implement a new abstraction layer for search backends, or (D) all of the above?
What I’d love to see (in an ideal world) is:
- Propose a design for a simple new search abstraction layer on the backend that supports Meilisearch and Algolia, supports proper creation/updating of indexes similar to how django handles migrations (you can even use django migrations as the framework for this), supports “personalized access tokens” (requests go directly from browser to search engine, for instant results as you type), etc.
- Once you get buy-in, implement the Meilisearch backend for (1) and convert my existing Studio search code to use the new abstraction layer on the backend.
- Create an edx-search backend that uses (1) so that the existing courseware search can be used with meilisearch instead of Elasticsearch.
But if nobody is willing to take that on, we can just do:
- Hack edx-search/courseware search with the minimal changes needed to run Meilisearch instead of Elasticsearch.
Post Sumac (or sooner if possible):
- Rewrite courseware search to use the new abstraction layer instead of edx-search and follow the design discussed in Auto-suggest course content on search (Meilisearch-compatible) so that it uses “personalized access tokens” (requests go directly from browser to search engine, for instant results as you type)
- Rewrite forums/notes/etc. to use the new abstraction layer
- Discovery service - tbd; there will be a bunch of proposals about this in the coming months