Gridify.Elasticsearch generate DSL query (non-generic)

[alirezanet]

Details

Currently, we're expanding the Elastic client's capabilities using a few extension classes powered by Gridify. It would be awesome if we could have a dedicated and non-generic DSL query generator that can give us DSL query JSON strings. This feature would come in handy when we want to create and use queries in web dashboards like OpenSearch.

What do you think, @ne4ta? Your thoughts are much appreciated!

something like this:

string elasticQueryBuilder = new ElasticQueryBuilder()
         .AddCondition("field = value")
         .Build();

note: the non-generic version of the queryBuilder doesn't need the GridifyMapper.

[ne4ta]

Hi @alirezanet. The idea to have a non-generic option for building requests sounds interesting. However, I'm not sure I understand its use case. Could you please describe it in more detail? I haven't used OpenSearch. It looks like it requires another .NET client to work with. And in this case we would add an ability to work with OpenSearch too. But I'm a bit confused about the raw JSON request. Do you mean the creation of a JSON request to be able to send a request to OpenSearch instead of Elasticsearch? And why should it be non-generic?

[alirezanet]

Hi @ne4ta,

No, it is not related to .Net, OpenSearch is one of the open-source Elasticsearch dashboards. Using these dashboards, it is sometimes difficult to write a proper query. I was thinking of having a query builder to help generate DSL queries if we need to integrate with these dashboards. I was considering a non-generic version mainly because we wouldn't have to create additional models to create the query. However, having another generic version, QueryBuilder<T> that can also build the JSON string and the Elasticsearch client Query would be nice.

I haven't looked at the elastic client features but I think it also should accept these DSL json strings...

[ne4ta]

I've got the idea now. I'll see if we can implement this without complicating things, as we currently can't reuse our implementation that heavily relies on generics.