Is Rust client for Elasticsearch safe for corporation/production use?

odyssey_2001 · June 26, 2021, 9:55pm

Hi,

I was on Github and I saw that apparently there is an official client for Elasticsearch written in Rust which is a language that I admire a lot. Here is the link.

However they say:

The project is still very much a work in progress and in an alpha state; input and contributions welcome!

When they say alpha state, do they talk about the lack of stability or the fact that it is stable and appropriate enough for a corporation/production use but there are features which are not still available?

Any experience? feedback about this client ?

Thanks.

stephenb · June 27, 2021, 5:04am

Hi @odyssey_2001 Welcome to the community and thanks for trying the Rust client.

In general Elastic does not recommend running any Elastic projects / component / code in production that is not marked GA.

The Rust client is alpha which means it will still need to progress through Beta before it becomes GA, Only then would we recommend running in production.

With other components that we release in alpha the API could change or performance could change significantly as the software matures.

Of course there'd be no formal support until it reaches GA either.

Perhaps @Russ_Cam can comment or be more specific on the Rust client.

odyssey_2001 · June 27, 2021, 8:27am

Hello Stephen

Thanks a lot for this information. The "GA" flag you are talking about, is it indicated on Github allowing to know whether the client is ready for production use? For example I was checking the official Python client here but I didn't find it.

stephenb · June 27, 2021, 3:48pm

Python is GA.

Typically and it looks like perhaps we are a bit inconsistent, components are GA when all language indicating otherwise is removed.

Example on the Rust you have

Rust client	Elasticsearch	Status
7.x	7.x	alpha

Where as on the Python there is no indicator.

And you can always ask here

odyssey_2001 · June 27, 2021, 6:28pm

Thanks a lot for confirmation.

One last question : Even approximately, is there by any chance any deadline/calendar indicating when Rust client might become GA (to know finally which client to choose which obviously impacts training, resource investment, etc. for the organization)?

warkolm · June 27, 2021, 10:33pm

We don't provide timelines for that sort of thing sorry to say.

odyssey_2001 · June 27, 2021, 10:38pm

I understand. Thanks.

forloop · June 27, 2021, 11:10pm

Hi @odyssey_2001,

The Rust client is currently still marked as alpha, primarily due to

Maturity/Confidence in the design of the client API
Request and Response types

For point 1, the design of the client API hasn't drastically changed since the first client release and I wouldn't expect it to drastically change going forward. The client supports all Elasticsearch APIs, including beta and experimental APIs (through features). The performance of the client over time can be seen on the client benchmarks.

The biggest missing piece are request and response types, which I would expect to come out of the effort going into the Elasticsearch specification. This issue is being tracked at

github.com/elastic/elasticsearch-rs

[ENHANCEMENT] Request and Response types

opened 02:29AM - 27 Mar 20 UTC

Veetaha

enhancement

**Is your feature request related to a problem? Please describe.** For some tim…e I was using the `TypeScript` client for `Elasticsearch`. The major source of bugs and inconvenience is that the exposed client API is mostly untyped. When moving to `Rust` I was hoping that the strong statically-typed nature of the language will enforce creating a strictly-typed client in it. But as I see the client methods just use `T: serde::Serialize` which is frustrating. The problem with this approach is that the API is so-called *stringy*, i.e. it is super-easy to mistype the `JSON` object keys, pass the `JSON` value of the wrong type or if the value is a string of a fixed set of possible values it is very easy to misspell the string enum. Besides that, you get poor developer experience from IDE, since you get no hints about the object shape that is expected, no completions and go-to-definitions to inspect the possible set of properties you can write, etc.. At the end of the day, such a *stringy* API just means that all the type-checks are moved from the compile-time to run-time, thus requiring extensive testing of your application, but it always happens that you forget to test some rare code-path where you e.g. misspelled the query object key and it gets to production and **boom**... I know you understand these concerns and the decision on using the *stringy* `JSON` API in Rust was deliberate. Maybe, because it allows you to bootstrap the client with much less time and effort. I agree that it is a good short-term decision, it did let you create the crate very rapidly, didn't it? So maybe it's time to do more long-term design improvements?... **Describe the solution you'd like** I don't have the ideal API proposal here. I'd like to hear your thoughts on that. I saw that [you were interested in `rs-es`](https://github.com/benashford/rs-es/issues/143) crate that does provide a good strongly-typed API, but unfortunately, this crate is likely unmaintained... Also, I'd like to note that it is **important** to not only define the input types to the client but also strongly type the response objects. One thing that I'd like to warn you is the downside of static typing, anyway. I noticed it in `diesel-rs` (which has a very cool strongly-typed API which I'd like this crate to aspire). E.g. If we implement the query builder it is necessary to ensure that it will allow for dynamic query building, i.e. let boxing the query builder like this is done in `diesel` in [`into_boxed()`](http://docs.diesel.rs/diesel/query_dsl/trait.QueryDsl.html#method.into_boxed) Example of the problem: ```rust impl BoolQueryBuilder { must() -> MustQueryBuilder; should() -> ShouldQueryBuilder; } let query = if cond { bool().must() } else { bool().should() // this will fail because the types of branches are different } ``` **Describe alternatives you've considered** As a crazy alternative, we can use macros for DSL so that we preserve the `JSON`-like syntax for building queries, but the macros will validate the query shape and raise a compile-time error if something invalid is encountered. However, as to me, the API should expose something like a document object model (`DOM`) or abstract syntax tree (`AST`) which lets you safely create your requests. By now this crate already uses an `AST`, but this is the `AST` of the `JSON` language as a whole. So at the high level, the goal is to narrow down the `JSON` language to `Elasticsearch DSL JSON subset`, which doesn't allow all the possible object shapes that are defined by `JSON`, but only the shapes that `Elasticsearch` server understands and works with. **Additional context** `Option::<AdditionalContext>::None`

I wouldn't say that request and response types are a necessary piece for the client becoming GA, though they are an important piece in providing a more ergonomic client in a statically typed language.

If you were to use the Rust client and come across issues, we'd love to hear about them on the GitHub repository, though as @stephenb says, there is no formal support for alpha software.

odyssey_2001 · June 27, 2021, 11:17pm

Thank you very much for this detailed presentation. I think, even in its alpha state, I'm going to give it a try. Anyway, one day it will ultimately become GA, so better to at least start learning how to use it now. Thanks for your time.

catzop · July 12, 2021, 12:17pm

The "GA" flag you are talking about, is it indicated on Github allowing to know whether the client is ready for production use. .

forloop · July 30, 2021, 2:10am

In the case of the Rust client, a GA version of the client would be a published crate version that does not have a prerelease suffix, such as -alpha.1.

system · August 27, 2021, 2:11am

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.