Feature request: ElasticSearch backend compatibility mode

Description

We have developed a platform for de-identifying, storing and searching clinical narrative reports. Example can be: reports from the radiology department. We have chosen early on to utilize ElasticSearch. Our frontend team used Elastic's JS widgets and modified them. We feel like frontend part is working fine, but ElasticSearch is slow. We want to get the search to be consistent and below 1-2s. We were hoping that moving to Typesense's backend would solve the speed issue, but we'd love to not throw the frontend code away.

It'd be nice if Typesense had ElasticSearch compatibility mode - the backend endpoint where queries from ES JS widgets could be sent, and handled, as if Typesense's backend was ElasticSearch. This could be a nice way for you to transparently switch existing customers to Typesense, as I imagine there are many frontends that format JSON queries according to ES.

Steps to reproduce

We are using those JS widgets:

https://www.npmjs.com/package/@elastic/react-search-ui
https://npmjs.com/package/@elastic/search-ui-app-search-connector

Expected Behavior

Would love to just move from e.g.: elastic.mysearchplatform.com to typesense.mysearchplatform.com transparently without rewriting anything in FE and get 10x the speed.

Actual Behavior

We'd have to rewrite a lot of code to Typesense.

Metadata

Typesense Version:

OS:

Start with the linked @elastic/react-search-ui and @elastic/search-ui-app-search-connector packages to identify the Elasticsearch JSON queries they send. Define the compatibility endpoint and supported query surface, then verify that the widgets work without frontend changes and that searches meet the requested 1–2 second target.