search

opensearch-project / OpenSearch

🔎 Open source distributed and RESTful search engine.
https://opensearch.org/docs/latest/opensearch/index/
Apache License 2.0
9.65k stars 1.78k forks source link

Extension points for RestHighLevelClient classes #2211

Open mrMigles opened 2 years ago

mrMigles commented 2 years ago

Is your feature request related to a problem? Please describe.

In our company we need to extend index creation logic for RestHighLevelClient, in particular to call some API of our service before create indices via OpenSearch. We don't want to fork repository at all, because we need to add small logic in index creation process, and features of our framework assume that this code should be performed on OpenSearch client side, not in our wrappers.

We didn't find any extension points like interceptors or something else, so we thought to extend RestHighLevelClient and IndicesClient with our implementations and override necessary methods.

But we found out, that it's not possible because IndicesClient is initializing on instance creating without any abilities to override it https://github.com/opensearch-project/OpenSearch/blob/main/client/rest-high-level/src/main/java/org/opensearch/client/RestHighLevelClient.java#L265, moreover class IndicesClient is final https://github.com/opensearch-project/OpenSearch/blob/main/client/rest-high-level/src/main/java/org/opensearch/client/IndicesClient.java#L102 and it's not possible to extend it.

Yes, we understand that these classes are forked from Elasticsearch and probably these restrictions are legacy.

Describe the solution you'd like We suggest to remove final keyword from classes of this client (because now it looks like vendor lock) and make it possible to use our own implementation of IndicesClient or any other clients with RestHighLevelClient.

We can implement this feature and prepare PR, but we would like to know what do you and community think about this feature?

Describe alternatives you've considered Design interceptors mechanism for all client's operations, but it looks more difficult. Looks like adding the ability to extend clients is more preferable.

Additional context

saratvemulapalli commented 2 years ago

From what I understand (I have no knowledge how the HLRC works), what you'd like to have is receive notifications for few events. In this case it is for the IndexClient.

Initially I did like the idea of removing final for these classes. But thinking little deeper, we'd like the client to solve the core problem of what its doing and its not worth duplicating the business logic by every customer. The only use cases I can think of is: a. Missing Features b. Notifications on events (which is what you are looking for) c. Specific overrides.

Can we make these API's pluggable so they make call backs to handle these event notifications?

mrMigles commented 2 years ago

Thanks @saratvemulapalli ,

Actually, we need to override index name that client uses in code. For example, it tries to create index with name "test", but in overridden code of client we need to generate specific for this client (microservice) index prefix befor erequest to OpenSearch, for example "client1-test". It should be transparent for clients. And other similar cases with custom index names overrides, so it's not about notifications. It may be some pluggable extension points that allows to implement some request transformations (like interceptors), or something like the option "c. Specific override".