You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Personally (though my opinion matters the least here) I've considered zentity to have too simple of an API to warrant the effort of client libraries, each of which would need to be kept in sync with the latest versions of zentity and Elasticsearch. I envisioned using HTTP libraries directly. But I'm happy to have my assumptions on simplicity challenged -- and to hear what people would expect or want to see in a client library.
I think it's true about the simplicity of the API and HTTP libs are a low barrier-to-entry for getting started with Zentity. The benefit we've seen of a more integrated client is two-fold: Zentity types and Elasticsearch-client support.
Having a client that brings the type information of Zentity things like models, resolution parameters, and request/ response formats as code makes a huge difference when adding new features or passing projects off within teams.
Tighter integration with Elasticsearch clients might be even more important, though, as it brings support for things like connection pooling and standard authentication. If using just an HTTP lib, all of that would have to be re-implemented somewhere (either in the HTTP lib or in the user's code). It's also worth noting that people will likely be using an ES client already in the application if it deals with indexing the data Zentity is resolving against.
There has already been some discussion about talking with a Zentity-enabled cluster in Python, but I'm wondering what other languages people would like to see clients built for? We're currently using Node.js and can contribute our extension to the official client if others would find it useful.
The text was updated successfully, but these errors were encountered: