> - 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.