Sense is JSON aware (and autocomplete is nice) but it still expects you to write the Elasticsearch DSL.
Mirage provides an alternative interface (GUI based) to compose the Elasticsearch queries that it transpiles on the fly to the Elasticsearch JSON syntax (and you're free to work with the latter as well).
Yet another separated tool. The Elasticsearch ecosystem is not going to became simpler with ES 5 removing the "site" plugins and everyone doing their own apps instead of building Kibana Apps (i.e. Cerebro, the new Kopf)...
Elasticsearch's plugin ecosystem has historically been fragmented. That's why we make the plugin available in multiple ways (hosted app, chrome extension and site plugin).
well-behaved site plugins (such as kopf) have always been able to run as a standalone app in the browser - either from a folder on your disk of from a stupid webserver. All it needed was a working CORS config on the ES cluster.
It's always been a good idea to deploy them in that way - no need to have the plugin on each node, easier version upgrades, access to multiple clusters etc. So basically, not much changed.
I agree with you wholeheartedly on the documentation, but having a full-featured HTTP ReST API from the beginning has been a powerful driver for ES, imho. Depending on your use case, this may or may not matter. Currently, I use/admin both - ES for logs, Solr for actual full-text document search.
In our use cases, where the search experience is modeled after google in terms of simplicity. There is simply no opportunity for end-user to configure a complex search criteria.
Solr has excellent documentation. The query documentation and examples could use some work, but a lot of basic functionality is quite intuitive. The pivoting engine is also really good and scalable.
Nice on first try, but this is just a subset of the query interface? Maybe I didn't understand it correctly, but I couldn't find any more advanced options like filters etc.?
If you're looking to build some advanced user-facing Elasticsearch functionality into your own webapp, SearchKit looks really nifty: http://www.searchkit.co/
It looks very cool. That said, When I looked a couple of weeks ago SearchKit was not yet compatiable with React v15. It also manages its own state making it slightly more challenging to integrate with anything like Redux.
Is there anything like ES or Solr "templates" (maybe combined with libs) for indexing and searching certain domains/verticals?
For instance, e-commerce is a common use case, but it seems that everyone must roll their own faceting/query analyzers, stop words, synonyms, substitutions, etc. in order to build a search engine that provides useful searches within the context of a product catalog.
22 comments
[ 3.1 ms ] story [ 49.6 ms ] threadStep 2 would be a saner output representation, something more readable and compact than JSON.
https://github.com/elastic/sense
EDIT: I watched the complete demo, seems more smart than sense. (in terms of query building)
Mirage provides an alternative interface (GUI based) to compose the Elasticsearch queries that it transpiles on the fly to the Elasticsearch JSON syntax (and you're free to work with the latter as well).
In case you would rather run this locally than grant access to your elasticsearch.
Links:
[1] Hosted app - http://appbaseio.github.io/mirage/
[2] Chrome extension - https://chrome.google.com/webstore/detail/mirage/dcnlpfmnpog...
[3] Site Plugin for Elasticsearch v2.x - plugin install appbaseio/mirage
It's always been a good idea to deploy them in that way - no need to have the plugin on each node, easier version upgrades, access to multiple clusters etc. So basically, not much changed.
I find solr's API much more intuitive, and documentation and out of the box toolset much more user friendly.
I suspect elastic is kept more obscure and difficult by design.
We welcome contributions for more queries.
https://github.com/searchkit/searchkit/issues/188
For instance, e-commerce is a common use case, but it seems that everyone must roll their own faceting/query analyzers, stop words, synonyms, substitutions, etc. in order to build a search engine that provides useful searches within the context of a product catalog.