-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search #26
Comments
If zinc is used (from my understanding) it looks like it'll need to be implemented on the server side (at least for the server which holds all the references to the objects/records). Also, of note it appears that zinc is still in beta (src):
So, it's possible they'll have major breaking changes before the 1.0 release, which means we'll need to make sure we pin the version and read the changelog before upgrading to see if anything's going to break. While it's not a self-hosted option (and will probably cost money because of how many episodes JB has), as a temporary solution, we could use algolia. I've used them before, and overall it was pretty easy. I've actually got a GH action for doing CI with hugo content as well: https://github.com/Climate-Refugee-Stories/crs-website/blob/c82f394a620b4631bb43de5ca4433d33a51bb292/.github/workflows/cd.yml#L91-L126 |
Meta: BTW, @gerbrent you might want to add a "JB - action needed" tag to this issue since it's discussing cost of running an extra service on a server specifically for search, and if that's something they want to contemplate (because that'll be another service to maintain). |
Typesense might be a good option |
@RealOrangeOne usually has some pretty strong opinions on search. |
I have opinions aswell, from a functionality and end-user perspective. The search results at notes.jupiterbroadcasting.com is not at all to my liking pretty much every single time I try to use it, which is generally answering a question like "I remember we mentioned that in the last few months, lets see which episode that was from" - This generally gives results sorted by "relevance" which never gets me what I want (and yet I keep trying.....) I would far prefer chronologically sorted search results. Also on a slow connection, the UX of that current search - the present-results-as-pop-up-in-search-bar behaviour isn't obvious for quite some time till the results load. An annoying UX experience, and slow enough to make me wonder more than once "is this working?" |
I'm willing to start putting some serious development work into this. Some clarifying questions:
|
See the search at |
see here why search via recency is not supported nor desired by mkdocs: |
I agree lunr probably isn't ideal, as the index will be huge. I've written client-side search with Hugo, and it's very simple, but the index may be large given the show history mkdocs's search is lunr-based. The issue with mkdocs is that the pages have no sense of date, as opposed to being a technological issue. Hugo however does have dates as a concept, so could be done. For search, I suspect we'd want want something server-side to do it. For ease (of local dev and hosting), scraping the content into sqlite and using its fulltext search would probably be very simple, very powerful and scalable. Elasticsearch etc are definitely options, but they're very heavy for what we need. As are hosted tools like Algolia, but given the name of one of our shows, that's a less desirable option. |
Could we run some mock ups with elastic and get a sense of just how heavy? We have the infra to do it I'd wager. |
It's not just heavy in terms of resource. It also makes local development much more of a pain, not to mention is more complex to setup and work with anyway. The container alone is ~550mb compressed. |
Unfortunately when it comes to search, I think it's the classic pick two between fast, good, and inexpensive. Though I do agree that full fat elastic is a bit too heavy-handed for our needs. |
So I just found a tool that might be worth using if search is still something we are after. Its called Pagefind and it is a single binary that indexes the site after it is built. There is a video on the home page of their site showing how it works and a basic example. Its also written in 🎉 Rust 🎉 |
That looks pretty awesome! It's nice that we could just bundle that in an artifact as well. It just comes with the new site build! 🥳 |
this DOES look fascinating! The demo at the top of the page at https://pagefind.app/ is fast - much faster than our current notes.jupiterbroadcasting.com for me on a low end internet connection and low-end hardware.
that sounds like us ; ) 🎯 Another lovely demo: https://xkcd.pagefind.app/ |
I don't see why not since it is content on the page. I wonder if we will need a piece of metadata for the date. But I found this tool about 15 minutes before I commented (Just long enough to watch the video) |
That can be very handy for the JB Archive (a distinct hugo instance):
https://pagefind.app/docs/multisite/
https://pagefind.app/docs/multisite/#changing-the-weighting-of-individual-indexes |
Hello all! Have you considered https://www.meilisearch.com/ ? It's also an open source project with a valid source of income (they have recently received 15M round o founding). It is very easy to deploy. I'd be more than happy to write backend RSS watcher and some mockups for front end. |
oh wow, very generous @FlakM !!! I'll be curious to hear what others think of MeiliSearch - def worth considering! |
I've been recently reviewing alternatives for more traditional ELK stack and hosted options for my employer. Meilisearch has come up on this week in rust so I have also looked into it. Here are some reasons why I think it would be a good fit here:
For your convenience, I've deployed a sample service and loaded the index with contents of all feeds RSS its available here (BTW it is a proper use of Linode credits) secret key is |
amazing again @FlakM !! Will look at this further in a few days.. thank you!! |
@kylepotts suggests start of convo & end of convo:
|
figure out a good way to integrate search. Clientside like Lunr.js will probably not perform due to index size.
@theZMC recommends:
The text was updated successfully, but these errors were encountered: