Objective C client for ElasticSearch ( iphone, ipad etc.)

Is there a client implementation for ElasticSearch written for Objective-C
(iPhone) users out there? I'm trying to roll my own but I don't want to
reinvent the wheel.

On Sun, Apr 15, 2012 at 03:35, pulkitsinghal pulkitsinghal@gmail.com wrote:

Is there a client implementation for Elasticsearch written for Objective-C
(iPhone) users out there? I'm trying to roll my own but I don't want to
reinvent the wheel.

Unless you plan to actually run Elasticsearch on the iOS device (which
is probably not such a good idea, since it's fairly resource hungry
for a phone/tablet) application this sounds like an inherently bad
idea unless this is an application distributed internally to your
organization.

Anyone could trivially discover the hostname that you're making
requests to and make arbitrary requests of their own, so if you wanted
to secure this you'd have to also write some really complex
server-side filtering layer that only accepted certain queries (even
GET queries could be troublesome, if they take a lot of resources).

I maintain the server-side of a system that amongst other things has
iOS applications making search requests, but they do so through a
custom JSON API. I.e. the iOS device will request
/search_for?name=Whatever, the server-side will make the actual ES
query, and a minimal custom response will be returned to the iOS
device.

Not only is that more secure, but it also relieves the mobile device
from having to do round-robin requests to the cluster and other things
that are needlessly expensive on network/CPU on a mobile device.

@avarab - Thank you for the "bigger picture," let me see if I can convince
you that the question is still relevant:

  1. In my question, I am approaching an ES client from the perspective of
    building out at least the "Query DSL" piece, there may be more that a full
    fledged client can do but this is the part I think is immediately useful on
    iOS (Objective-C) apps.
  2. I was under the impression that multiple solutions exist to secure
    the connection to an ES server:
    1. nginx
    2. sTunnel
    3. elasticsearch-jetty
    4. Am I mistaken about this?
  3. CPU wise, mobile phones today are powerful devices and I'd like to
    think that I can count on them.
  4. I understand the point about round trips but if user interaction is
    required than there is simply no way around getting results, then showing
    them and letting the user choose where to go next anyway.
  5. So, is there a client implementation for ElasticSearch written for
    Objective-C (iPhone) users out there? I'm trying to roll my own but I don't
    want to reinvent the wheel. Let me know.

On Sun, Apr 15, 2012 at 18:18, Pulkit Singhal pulkitsinghal@gmail.com wrote:

I was under the impression that multiple solutions exist to secure the
connection to an ES server:

nginx
sTunnel
elasticsearch-jetty

nginx would give you something like a http proxy, which you could use
to enforce that you can only make e.g. GET queries, but you could
still make harmful GET queries.

sTunnel wouldn't give you anything since the attack vector here is a
harmful client making bad requests, they can obviously use your tunnel
too since they can make requests in the first place.

I haven't looked much into elasticsearch-jetty, you might be able to
get it to do what you want.

But in the end I think this idea is about as bright as having an iOS
device connect to a remote SQL server. Sure you can maybe mitigate
the problem with grants and whatnot, but why not avoid the whole issue
in the first place and just make the iOS device make requests to a
limited custom API.

CPU wise, mobile phones today are powerful devices and I'd like to think
that I can count on them.

Sure, but needing overly smart clients might result in higher battery
use / latency if you have to make multiple requests etc.

So, is there a client implementation for Elasticsearch written for
Objective-C (iPhone) users out there? I'm trying to roll my own but I don't
want to reinvent the wheel. Let me know.

I have no idea, probably not.

But I thought it was more useful to point out that what you're looking
to is very hard if not almost impossible to do securely, and if you do
manage to do it securely it's probably going to be a lot more work
than just having a custom API you make requests to.