Hacker News new | past | comments | ask | show | jobs | submit | sidi's comments login

There currently isn't a way to filter docs alongside a KNN query, and the dimension support is limited to 1024 (a Lucene limitation) and OpenAI embeddings are 1536 dimensions - also indexing performance is not comparable. Wishing this changes, as they're a good stack for the reasons you state


True though I do think 2k dims is coming it 8.8


Are they forking Lucene or somehow getting the Lucene devs to increase that limit? Because this PR has been open for over a year now: https://github.com/apache/lucene/issues/11507


No - they just did something in Elasticsearch to make their own FieldType https://github.com/elastic/elasticsearch/pull/95257


Disclaimer: founder here

We offer a hosted/managed app search experience on top of Elastic or OpenSearch with appbase.io.

You can leverage the best of Elasticsearch (state-of-the-art) engine while getting Algolia like features like search relevance control plane, query rules, out-of-the-box analytics / insights, caching, UI components across all FE platforms (React, Vue, React Native, Flutter).


Hey HN'ers

We're really excited about this launch, as it has been some time in the making. Our goal with appbase.io is to offer a supercharged Elasticsearch experience - we do this by offering an advanced search relevance control plane that allows a user to create a relevant search with no code. Since this experience is powered under the hood with Elasticsearch - so you aren't limited in the future if you wish to build upon what appbase.io already offers. You can host with us, or run it alongside your existing Elasticsearch cluster.

What can you can do with appbase.io: - Build Auto suggestions (powered by n-grams, edge n-grams), - Highlighting support, - Support for 39 languages as well as support for multi-language search, - Popular suggestions based on analytics, - Set synonyms, - Use rank feature in addition to text relevance to optimize relevance tuning, - Advanced query rules to extend search relevance.

In addition to our no code control plane, one can use our JS UI components (4,000+ Github stars, 1MM+ downloads, actively used by more than 1,000 projects) to design the search experience for web and mobile. We offer these components for React, Vue, React Native and Vanilla JS. You can read more about it over here: https://appbase.io/product/search-ui/

When a search experience is powered with appbase.io, we additionally support collecting telemetry on search and click data and provide analytics/insights on areas to improve search engagement and conversion metrics. Read more over here: https://www.appbase.io/product/analytics/.


Hey HN'ers :wave:

Searchbox is designed with the goal of being a lightweight (16KB to 35KB when minified + gzipped), performance focused library for building search UIs declaratively. We have variants for React, Vue and a headless library that can be used with any framework.

Direct Github link: https://github.com/appbaseio/searchbox

With this release version, Searchbox assumes the backend to be an appbase.io/Elasticsearch server. While there are other libraries that are backend agnostic, making this assumption allows the library to support tracking search analytics, displaying popular suggestions, and configuring advanced search relevance options. Searchbox comes from 3 years of learnings we've had in maintaining ReactiveSearch - one of the most popular search UI libraries out there.

Key benefits of using it:

- Searchbox lets you create versatile search experiences. Think auto suggestions, highlighting, incorporating fuzzy search, voice search, setting search relevance (fields to search on, weights to apply), showing default suggestions, rendering your own UIs.

- In addition, it lets you measure search/click analytics, set query rules, show popular suggestions. Most other searchbox libraries don't offer these capabilities.

- It's built with the open web in mind. Search is designed to work with any design system (Bootstrap/Material/Antd/your own), and it can integrate with any kind of UI components. See a demo here for an integration with React Table: https://codesandbox.io/embed/github/appbaseio/searchbox/tree....

- It supports tree shaking. If the built-in searchbox component were not used, the size of the library comes down to 10KB when minified + gzipped.

Read more over here: https://medium.appbase.io/searchbox-1-0-a-javascript-library...


This pricing change from Algolia makes it easier for low-volume search users or someone who is just getting started to use their enterprise features, but at the same time as the parent mentions, makes it an order of magnitude more expensive for mid-to-high volume users. Imo, this is a mismatch as there is already a trial in place for someone who's just getting started to try those features out.

For anyone interested in creating a search at scale, I would recommend checking us out at appbase.io (founder here :wave:) - we provide relevant search, analytics, and access control for search and are built transparently on top of Elasticsearch. It also doesn't hurt that we author some of the most popular open-source search UI libraries: https://github.com/appbaseio/reactivesearch


It is also less expensive and more accessible for mid/large volumes. We have built-in volume discount in the pricing that reduce significantly the price at scale


Does Insomnia offer hosted documentation of the API collections? That's the feature which keeps me using Postman.


There's a nice community project that generates documentation that can be hosted https://github.com/jozsefsallai/insomnia-documenter


Not remotely the same, but we use Swagger on the test servers.


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.


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.


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.

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


Thanks for the compliment. :-) The UI components would always remain open-source.

We offer a hosted search service at appbase.io which funds this and have very recently started offering it more broadly as a managed platform for any ElasticSearch upstream. It offers a better search development experience, out-of-the-box search/click analytics and more fine-grained security features: https://medium.appbase.io/appbase-io-clusters-a-supercharged....


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


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


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.


This is good feedback, thanks :-)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: