If we can extend edx-search in a way that we’re actually supporting different search backends properly, (i.e. not a bunch of if statements littering the other repos), then that would seem like a decent migration path for existing search functionality that already uses Elasticsearch. So In that scenario, Elasticsearch doesn’t actually go away, per se, as long as someone’s interested in maintaining that code–even if the platform default becomes Meilisearch.
I’d worry about maintaining this over time, and how we ensure that new features don’t break under other search engines. The course-discovery PR you put up has an explicit set of classes defined when Meilisearch is being used–which is understandable since those definitions have to exist somewhere, but I’m not clear if we have the ability to adequately test and maintain the separate backends over time. How would you see that working?
I think it is related in the sense that we could decide that we only want to support backends with that sort of frontend, live-search capability (e.g. Meilisearch, Algolia, Typesense), which would significantly change how we build those features going forward. Yes, it doesn’t mean we’d have to kill edx-search, but it would affect how deep changes might go.
@qasimgulzar: Maybe it makes sense to take this conversation to the other thread evaluating Meilisearch?