# Is Rust client for Elasticsearch safe for corporation/production use?
**URL:** https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138
**Category:** Elasticsearch
**Tags:** language-clients
**Created:** [June 26, 2021, 9:55pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138 "2021-06-26T21:55:12Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@odyssey\_2001](https://discuss.elastic.co/u/odyssey_2001)
#### Post date: [June 26, 2021, 9:55pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/1 "2021-06-26T21:55:12Z")
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](https://github.com/elastic/elasticsearch-rs).
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.
---
### Author:  [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [June 27, 2021, 5:04am UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/2 "2021-06-27T05:04:36Z")
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.
---
### Author:  [@odyssey\_2001](https://discuss.elastic.co/u/odyssey_2001)
#### Post date: [June 27, 2021, 8:27am UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/3 "2021-06-27T08:27:58Z")
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](https://github.com/elastic/elasticsearch-py) but I didn't find it.
---
### Author:  [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [June 27, 2021, 3:48pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/4 "2021-06-27T15:48:50Z")
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
```auto
Rust client Elasticsearch Status
7.x 7.x alpha
```
Where as on the Python there is no indicator.
And you can always ask here ๐
---
### Author:  [@odyssey\_2001](https://discuss.elastic.co/u/odyssey_2001)
#### Post date: [June 27, 2021, 6:28pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/5 "2021-06-27T18:28:42Z")
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)?
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [June 27, 2021, 10:33pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/6 "2021-06-27T22:33:26Z")
We don't provide timelines for that sort of thing sorry to say.
---
### Author:  [@odyssey\_2001](https://discuss.elastic.co/u/odyssey_2001)
#### Post date: [June 27, 2021, 10:38pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/7 "2021-06-27T22:38:19Z")
I understand. Thanks.
---
### Author:  [@forloop](https://discuss.elastic.co/u/forloop)
#### Post date: [June 27, 2021, 11:10pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/8 "2021-06-27T23:10:57Z")
Hi @odyssey_2001,
The Rust client is currently still marked as alpha, primarily due to
1. Maturity/Confidence in the design of the client API
2. 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](https://clients-benchmarks.elastic.co/).
The biggest missing piece are request and response types, which I would expect to come out of the effort going into [the Elasticsearch specification](https://github.com/elastic/elasticsearch-specification). This issue is being tracked at
>
>
> \*\*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::\::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.
---
### Author:  [@odyssey\_2001](https://discuss.elastic.co/u/odyssey_2001)
#### Post date: [June 27, 2021, 11:17pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/9 "2021-06-27T23:17:12Z")
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. ๐
---
### Author:  [@catzop](https://discuss.elastic.co/u/catzop)
#### Post date: [July 12, 2021, 12:17pm UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/10 "2021-07-12T12:17:46Z")
The "GA" flag you are talking about, is it indicated on Github allowing to know whether the client is ready for production use[.](https://tomzpot.com/) [.](https://mdro.fun/mobdro/)
---
### Author:  [@forloop](https://discuss.elastic.co/u/forloop)
#### Post date: [July 30, 2021, 2:10am UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/11 "2021-07-30T02:10:48Z")
In the case of the Rust client, a GA version of the client would be [a published crate version](https://crates.io/crates/elasticsearch) that does **not** have a prerelease suffix, such as `-alpha.1`.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [August 27, 2021, 2:11am UTC](https://discuss.elastic.co/t/is-rust-client-for-elasticsearch-safe-for-corporation-production-use/277138/12 "2021-08-27T02:11:16Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.