Search is something that almost any site or app with more than a few pages can benefit from. It’s important that the user can find the information ...
For further actions, you may consider blocking this person and/or reporting abuse
I've used all three of these (albeit, not at the same time, and these products evolve over time)....
Algolia is incredibly easy to use and scalable by default. It's somewhat limited in what you can do as a north star, but it's incredibly powerful. But it's closed source and opinionated. Not the right choice for every project.
ElasticSearch is much harder to use than Algolia, but very powerful and extensible, and generally has a fairly intuitive API. It's well-supported and backed by a big successful company that focuses on its growth (albeit for enterprise first and foremost I think)...
I haven't used Solr in a while and generally migrated towards ES for cases where I would have used it, though I just don't remember all the specifics of my experience.
To add to this, ElasticSearch can also be installed on premise. In my case this is the only reason I use Elastic because I'm in a really strict intranet setting (government network). Spinning up a Docker container with Elastic running in it does take some time and tears of desperation when configuring everything yourself but it's still better than having no search engine at all :)
Yeah. I think Algolia would be so much cooler if it was open source and available on prem. I still think folks would use their excellent managed service, but it's a shame that's all they offer.
It still is the right tool for the job a lot of the time.
Awesome to hear from someone with broader experience 😉
Information based on comparison is twice as valuable as it lets us know where each tool stands in the bigger picture on what's out there 🙏❤
I'm currently experimenting with a search feature using Elasticsearch in a statically generated website (vimcolorschemes.com), and so far it's really good!
It's probably overkill for my needs, but the installation was seamless, and the search API is simple to use, not to mention fast!
Did you look at Fuse? That might be a better fit for that use case.
Hey Matthew, thanks for the suggestion!
vimcolorschemes has a pretty large dataset (couple of MBs) that I don't feel comfortable loading upfront. Using something like Elasticsearch gives me the flexibility of loading the search index only if the user uses the search feature, as well as only loading the results (not the whole index).
That said, the other option I'm looking into is creating a simple Express API that uses something like Fuse. I could upload the dataset at build time, and query it through the API on the client.
Fuse looks super intuitive, so I'll definitely consider it. Thanks Matthew!
I'm using Fuse in my static documentation site generator and I'm really pleased with it. Although I'm not using the fuzzy search which its supposed to be its strength
I used Fuse for a recent internal Laravel project at work. It's basically a portfolio site for showcasing projects we've worked on with various clients, and needed to support searching for projects by client name, project name, team member name and taxonomy.
I built a simple endpoint to get all the searchable data about the various projects, and return it as JSON. Fuse then uses that as a data source, and it works fantastically well.
In one of my previous jobs I was in charge of developing the whole search strategy for a company. We chose solr and was very happy with it. Solr and Elastin are Lucene based but Solr and Lucene are now one repo. Solr changed a lot in last few years and is very flexible in what you can do with it. But it's definitely hardest one to setup out of these (aldo they did a lot of work to make it easier for the most common usecaees).
I would go for solr for bigger complex projects with a lot of content types, etc..
For smaller sites and simple search on those I would go for something little bit eaiser.
I've worked at Algolia and am obviously biased but sold on the product. I use it when I need extensive search features and great performance on large datasets.
But 9 out of 10 times, I use Fuse.js because of its very limited footprint as an independent package, no infrastructure needed. Also, it can be executed on the back-end if you have performance limitations on the front-end.
What a coincidence! I literally just hit publish on a post announcing an open source search engine I've been working on: dev.to/kishorenc/announcing-typese...
If you are already familiar with Algolia and Elasticsearch, I think you will like Typesense. Take a look and do let me know what you think!
For now I'm using direct DB search 😅 in Taskord, but I have a plan to move to Elasticsearch!
Here is the video of how our search works: loom.com/share/e16d311d490346a39f1...
lunr.js - Only flat file CMS and serverless functions are enough for my needs
Actually, I asked about this a little earlier than yours, but nobody answered.
What's your favorite full-text search implementation?
Pacharapol Withayasakpunt ・ Oct 10 ・ 1 min read
Using django-haystack and a custom backend, we only successfully installed Solr.
I even created a small gist to install all the things to make it work :)
You can check meilisearch.com/ and crates.io/crates/sonic-server
For me, elasticsearch is really full featured, but sometimes it can be very costly. If you don't need really complex query or if you look for instant result feature then try out meili for example.
Rather, one would have to ask, what features do I really want?
For me, I would want
column_name:I don't currently need fuzzy search that much.
Thanks for the resources! 🙏❤ These look promising, as well 🔥
I used to create a static search engine many years ago as a pet project. It's called SCARV as in
Scavenger.Awesome job 👍😉
No engine will ever be as fit as a custom-built one based on the needs and specifics of the project 😉
I index all my posts on
db.jsonfor blogzen.js.org/cariI did an exercise on this topic recently for a project, and then wrote up my findings: deliciousreverie.co.uk/post/search...
ElasticSearch