Meh, it's a decent and properly commented implementation, but the interesting stuff is done by Redis, not in Go.
I wrote a similar service (JS+Go) 2 years or so ago using only the Go standard library (specifically the excellent index/suffixarray and gobs for persistence). It typically got ~3ms response timings (locally) with > 1 million records indexed.
I put together an autocomplete service using Ruby and Redis but rather than dealing with the network latency of a remote service I decided to package it up so it could be mounted along side my app: https://github.com/doomspork/autocomplete-me
The inclusion of a JS library is only a convenience. There more robust solutions for the UI like Twitter's Typeahead.js https://github.com/twitter/typeahead.js
Heh, I always feel a bit bad when people mention this since we're not using it ourselves anymore. Though it's a nice and easy way to get going quickly if you're already running redis (and especially if you've got a rails app).
We're using elasticsearch now which is definitely a bit more of an operational headache.
Curious... why use Elasticsearch over Redis? We're currently using Elasticsearch, but were considering switching to Redis, but now I'm thinking maybe we shouldn't. What's the downside?
It is fast because Redis, which provides the storage, is considerably fast at the tasks necessary to implement such a service. Go has last little to do with it.
Taglines are hard. I tried to make the tagline more "end-user friendly" instead of focusing on the tech. The people who implement it actually don't need to know how it's made. They just drop in the .js the .css and send their data to the REST API. They don't need to know that the database is Redis and that the server framework is Go.
Regarding the name, I just desperately needed to call it something when I started the git repo to build the prototype. Then it stuck and I decided to "brand" it as such.
I've found Apache Solr the best approach to building a flexible, fast auto-complete service. Solr can spit results back in json so it's dead easy to write a simple API wrapper in whatever language you're using (go, python, ruby).
You can then stick Varnish in front of the whole lot if the search space is relatively static and not ridiculously huge.
Also, I think it would be nice to be able to upload a list of synonyms. E.g "go==golang" so if someone types "golan" it could return "Go is a language" for example.
1. Why? That sample on autocompeter.com is just a sample. Consider the search widget on a page like www.peterbe.com instead. Then it shouldn't focus immediately on load.
2. I see. I think it only happens when the client-side cache is empty. And it only happens if you type very fast. I think the right solution would be to not hide too quickly. That's a very useful piece of feedback. Much appreciated!
It started as a side-project and still is. I'm the creator of the service and my day job is as a web developer at Mozilla.
If this service becomes surprisingly popular I'll look into ways to monetize but that's unlikely to be the case unless I'm really really lucky.
The origin of building this is that I found a cool prototype of the concept in a blog post, then threw that into my own site and later realized I want to re-use that for a (day)work site. So I though instead of copying it, I'll write a microservice.
49 comments
[ 3.4 ms ] story [ 51.1 ms ] threadI wrote a similar service (JS+Go) 2 years or so ago using only the Go standard library (specifically the excellent index/suffixarray and gobs for persistence). It typically got ~3ms response timings (locally) with > 1 million records indexed.
However, the hit ratio is too low to work. It only protects me from the stampeding herd problem at best.
Do you have a link to your implementation or comments on how this one could be improved?
Would you care to link to what you wrote?
We're using elasticsearch now which is definitely a bit more of an operational headache.
I actually re-wrote it once to switch out Redis for Postgres but it was way too slow.
FTFY
> Can find "Pär is naïve" by typing in "par naive"
Btw, I noticed a missing "c" in the "url -X POST" example on this page of your docs:
http://autocompeter.readthedocs.org/en/latest/api/#bulk-uplo...
https://github.com/peterbe/autocompeter/blob/master/server.g...
Also with `log` you don't need to add a `\n` at the end, it will do it for you.
You can then stick Varnish in front of the whole lot if the search space is relatively static and not ridiculously huge.
1. The focus should be on the search box when the page is loaded.
2. While typing the word "javascript", sometimes the amount of results shrinks and immediately increases, resulting in flickery behavior.
2. I see. I think it only happens when the client-side cache is empty. And it only happens if you type very fast. I think the right solution would be to not hide too quickly. That's a very useful piece of feedback. Much appreciated!
I investigated the problem and found a very good explanation for why it was happening.
Solved now: https://github.com/peterbe/autocompeter/commit/a31c919c1281d...
If this service becomes surprisingly popular I'll look into ways to monetize but that's unlikely to be the case unless I'm really really lucky.
The origin of building this is that I found a cool prototype of the concept in a blog post, then threw that into my own site and later realized I want to re-use that for a (day)work site. So I though instead of copying it, I'll write a microservice.