I've been working hard on a REST API client for the Rust language for a while now and thought it was time for an update.
I've implemented client functionality as a bunch of orthogonal 'crates' or libraries, which can be combined in various ways depending on what you need. I've essentially got the following:
elastic_hyper: A low-level, synchronous HTTP client generated from the API spec
elastic_types: A serialiser that constructs type mappings, index templates and deals with alternative formats for the core datatypes
elastic_rotor: An experimental asynchronous connection pooling HTTP client for high-throughput scenarios (not consumable yet)
In the last few months I've done:
- Minor updates to the synchronous client
- Brought the type serialisation up to rough parity with Elasticsearch's 5.0 branch
- Lots of work on documentation
- Split my codebase into a GitHub organisation, with better CI for testing and documentation
I still have a lot of work to do to start pulling these separate pieces together so they're useful for end users. The basic roadmap for the future looks like:
- Rebuild the code generation layer so I can be smarter about what ends up in the client
- Create a library for deserialising common Elasticsearch responses and errors called
- Get the async
elastic_rotorclient in a useful state
- Investigate a new async
elastic_tokioclient, but that might come for free in
- Figure out how to generate integration tests from the spec
There are a lot of rough edges in the current client layer, but I'm excited about the use cases a lightweight and superfast language like Rust can bring to Elasticsearch users IO in Rust is an interesting topic right now that's moving very quickly, I hope to be able to take full advantage of some of the awesome new frameworks when they're stabilised over the next few months.
Outside of waiting for IO, serialisation is probably where an API client will spend most of its time. Rust's main serialisation framework is awesome because it generates code at compile-time that's essentially as fast as a hand-written parser.
Any feedback would be really helpful in guiding this implementation towards something useful!