Native client is a dynamic var, rather than managed by user

[jonpither]

Hi,

Wondering why there is a difference between the way the client var is handled for rest vs native.

For rest the developer using elastisch has to manage the client object. For native is stored inside the client dynamic var.

The latter has issues, for example if a service/app wants to talk to two different ES instances this is unmanageable right? As a user of elastisch I also want to lifecycle manage the connection myself.

A change would probably be breaking to existing lib users, so I can see a downside in switching. Interested to know why the dynamic var approach was originally taken...

thanks,

Jon.

[michaelklishin]

The goal was to provide the same API as the HTTP client. With HTTP client you have another var (the endpoint) that has the same upsides and trade-offs as *client* in the native one. Having one less argument to pass is convenient and most people do not interact with more than one cluster/database/etc.

In Monger, this is mitigated by having another namespace (monger.multi) that has a set of key functions that have
the db (client) argument added. I'm afraid Elastisch API is much larger to do the same thing.

In the native client specifically you can connect to multiple ES nodes in the same cluster. Joining multiple clusters is not supported as far as I know.