
Show HN: ReactiveSearch Vue – Build Search UIs in Record Time - reactivesearch
https://opensource.appbase.io/reactivesearch/vue
======
reactivesearch
Hi HN folks!

We're just putting out the 1.0 release of ReactiveSearch Vue -
[https://medium.appbase.io/reactivesearch-vue-1-0-ui-
componen...](https://medium.appbase.io/reactivesearch-vue-1-0-ui-components-
for-search-e17a953e72a6). It's a sister library to ReactiveSearch for React,
with a similar aim of removing the pain out of building search UIs.

It takes care of querying, managing search state and updating your UI. There
are 10 built-in components:
[https://docs.appbase.io/docs/reactivesearch/vue/overview/Sho...](https://docs.appbase.io/docs/reactivesearch/vue/overview/Showcase/)
which can help one get started in minutes. However, it's very much designed to
allow bringing in your own UI components and design systems.

Direct Github link:
[https://github.com/appbaseio/reactivesearch](https://github.com/appbaseio/reactivesearch).

~~~
iudqnolq
This is incredibly polished, so much that I kept looking for a pricing page.
How are you able to cover all this with support licenses?

~~~
iamunr
This is exactly how I felt. Scrolled up and down 3x wondering where the
pricing was hidden.

~~~
iudqnolq
When I got to the downloadable Sketch components, I started wondering if the
website was mining cryptocurrencies or something. It seemed too good to be
true.

------
Asparagirl
As someone who has built search interfaces for a decade now, these are so
gorgeous. Really, really nice.

But...do you think you might ever write an adaptor for people to use them with
Apache Solr, rather than ElasticSearch? _makes puppydog eyes_

~~~
sidi
We've been asked about this a couple of times. It's not a trivial undertaking
but it's definitely something on our mind.

~~~
Asparagirl
If you set up crowdfunding to cover the costs of the dev work, I know people
who would chip in.

~~~
sankumsek
Can confirm, I'd be one of these people. The amount of time that I spend
trying to configure UIs instead of working within the Big Data pipeline is
wild. This would probably save me about 20% of my current workload right off
the bat if it was ported over to Solr.

~~~
sidi
This is good feedback, thanks :-)

------
jillesvangurp
I recently worked on a project that involved reactive search. A few things you
should be aware off when using that:

\- client side query construction basically puts you in a position where you
are going to be thinking about opening up elasticsearch to the internet. There
have been a range of companies that have accidentally revealed quite a bit
more than they wanted. Unless you know what you are doing and how to prevent
bad things from happening, just don't even think about doing this. ES has lots
of features that can cause it to run out of memory, execute arbitrary code
(ranking scripts), etc. A lot of that has sane defaults of course but exposing
that to the internet gives a malicious person a lot of power. Just don't even
consider using this without a proxy that sanitizes whatever comes from the
browser.

\- it's extremely aggressive in sending lots of queries to elasticsearch and a
lot of these queries involve aggregations. That's great if you don't have a
lot of data and users but it's a performance problem waiting to happen. It
basically does an msearch (multiple searches in one request) of queries that
quite trivially could be reduced to just one query. It does that when you type
a single letter or interact with any of the react components. It's basically a
react DOS toolkit.

\- the queries it constructs are a bit convoluted and under-use such features
as filters which you'd use to speed things up (allows ES to utilize its query
cache). It's nice if you don't know much about ES but at some point you will
want to sit down and optimize and it just gets in the way of doing that.

I ended up implementing a proxy (in python) that basically completely rewrites
the query the client sends server side. That solves the security problem too
because there is just no way to trick the server into running whatever query.
Then I just completely faked the client side query just so I could get extract
the handful of parameters. The end result allowed me to optimize the query,
decouple the UI from server side logic (i.e. we can change the query without
touching the UI now), add some much needed integration and ranking tests, etc.

So, if you are considering reactive search, I recommend not using it or at the
very least doing something like I did (which is work around it as much as you
can). And if you are doing that, you might as well design a proper REST API
and some components that manipulate a query context instead of triggering
dozens of queries on every DOM event.

~~~
sidi
Hey, addressing some of the concerns raised here directly:

> \- client side query construction basically puts you in a position ..

We recommend using a proxy server for these cases. It's on our roadmap to add
first-class support for search templates which would completely prevent query
generation to happen client-side.

> \- it's extremely aggressive in sending lots of queries to elasticsearch ..

This is configurable by using the debounce prop. And the number of queries
depend on what components you would like to see updated based on a change in
the search query or a facet value, for example.

> \- the queries it constructs are a bit convoluted and under-use such
> features as filters ..

We would be happy to address specific scenarios if you're seeing, please raise
an issue. That said, I believe we already do this to the extent it's
generalizable. And since as a user, you can change the underlying query - it
should be addressable by users.

\---

To sum up, the DOS and querying part is completely configurable and just comes
down to usage. We would love to address any generalizable issues.

There are merits to your point about client-side query generation. They are
already addressed for users who are using: 1\. Appbase.io - as you can set
ACLs and rules (e.g. only allow search requests, max X requests per IP per
hour, set max size of Y), 2\. For users outside of appbase.io, we recommend
using a proxy server like you did to implement an authorization logic.

Once we have first-class support for search templates in ReactiveSearch, this
should be effectively addressed.

~~~
jillesvangurp
Debounce helps of course. I'm just responding to what I saw at my customer
which was dozens of queries happening for simple user actions. Also the
requests bloat quite a bit with all the query composition magic client side.
This is probably not very mobile friendly. Also raw es responses are a bit
heavy.

Templating is a good solution. I'd recommend making that the only way. Also, I
don't see a good reason for using msearch since you can simply do the search
once with multiple aggregations (and only for the first page of results).

A challenge with this client is that it is intended for people who are likely
to not have a full grasp of the Elastic stack and thus very likely to get
themselves in all sorts of trouble. That's exactly what I saw when I came in
with my customer. They'd done the minimum of work to get started. Thankfully
they had the good sense to setup a proxy but there must be loads of people who
just open up port 9200.

I'd recommend actually testing the connection for access to things that
definitely should be off limits (e.g. create and delete an index, if that
works stert screaming at ERROR level).

For scaling and for architectural sanity, I don't think UIs should query
directly. SQL support in react is also not a thing for the same reason. You
typically do that kind of thing server side.

------
byahya
This is really cool! I've been thinking about dabbling with Vue.js and having
just wrapped up a project using the react version, might be a fun opportunity
to play around with. I'm a big fan of Appbase having used the hosted service
and reactivesearch UI elements for react. Shout out to Siddharth and Yash;
customer service is awesome and they're really knowledgeable (disclaimer: I do
pay for the dev tier so I can't speak to what its normally like). The
documentation is pretty solid too. All around good work. I'm excited to see
what's next in the product roadmap for them. Definitely a nice alternative to
AWS ES if you're just looking to spin search + UI quickly.

------
findjashua
seems like it only performs the search on the last word instead of the entire
query. is that the expected behavior?

screenshot: [https://paste.pics/7FLK0](https://paste.pics/7FLK0)

~~~
sidi
Not really, just seems like the dataset didn't contain any match for the first
word there. Counter example:
[https://i.imgur.com/6Z1m1g1.png](https://i.imgur.com/6Z1m1g1.png).

The way a search would work is configurable via props and you might want to
set it differently than how we have with the demo. See the doc for this:
[https://docs.appbase.io/docs/reactivesearch/vue/search/DataS...](https://docs.appbase.io/docs/reactivesearch/vue/search/DataSearch/#usage-
with-all-props).

