elastic / go-elasticsearch

The official Go client for Elasticsearch
https://github.com/elastic/go-elasticsearch#go-elasticsearch
Apache License 2.0
43 stars 617 forks source link

Support and/or contribute to olivere/elastic? #24

Closed bruth closed 5 years ago

bruth commented 5 years ago

I am all for an officially supported Go client, but https://github.com/olivere/elastic has been the library of choice for several years. Have you considered contributing or collaborating on this library? Have you reached out to the maintainer at all? It feels wasteful to create an alternative.

karmi commented 5 years ago

Hello @bruth, I've indeed reached out to @olivere early in the development stage, and we've had many conversations about the best design and approach. See the gophers.slack.com discussion during the announcement.

Regarding your other question, it's a bit more complex. The official Elasticsearch clients follow a certain design principle: to provide a strong foundation for other clients, extensions and addons to work with. This is what we sometimes refer to as a "low-level" client.

A concrete consequence of following this priniciple is that elastic/go-elasticsearch is completely hands-off the returned response: it just returns an io.Reader to the calling code. This allows the calling code, or any other library built on top of the package, to parse the response at will, using a custom JSON parser, etc. In this sense, olivere/elastic is more similar to what we sometimes refer to as a "high-level client", since it provides structures for working with a parsed response. (Note, providing these structures is on our roadmap, but not in the immediate future, since we need to come up with a proper specification and infastructure to generate them, similarly to the way we generate the REST API implementations.)

bruth commented 5 years ago

Thanks for the reply!

A concrete consequence of following this priniciple is that elastic/go-elasticsearch is completely hands-off the returned response: it just returns an io.Reader to the calling code. This allows the calling code, or any other library built on top of the package, to parse the response at will, using a custom JSON parser, etc.

Understood. So in theory olivere/elastic could be migrated to be built on top of the official client.

(Note, providing these structures is on our roadmap, but not in the immediate future, since we need to come up with a proper specification and infastructure to generate them, similarly to the way we generate the REST API implementations.)

I suppose at this point it could be considered a high-level client since it manages/interprets the full lifecycle of a given API request.

karmi commented 5 years ago

Yes, exactly, in theory olivere/elastic could use the low-level client as a foundation, so it doesn't have to re-implement all the mapping between ES REST API and Go types/functions, and all the transport logic. And yes, by the definition, olivere/elastic is definitely a "high-level client", since it provides typed responses, and manages the request/response bodies.

bruth commented 5 years ago

Understood, thanks for the response @karmi!