Clarification on Algolia design decision

BUGS-NYU / nyu-cs-wiki

The go-to guide for NYU CS students

https://nyucswiki.com

Creative Commons Attribution Share Alike 4.0 International

5 stars 19 forks source link

Clarification on Algolia design decision #64

Closed sachiniyer closed 1 year ago

sachiniyer commented 1 year ago

I was wondering why Algolia was chosen as a search provider instead of something open source.

There are a lot of alternatives:

Officially supported
1. Typesense which would probably be the most performant (but requires infrastructure). It is also very close to Algolia
Not officially supported - the docusaurus page
- with indexer
  1. Lunr
  2. docusaurus-search-local
- without indexer
  1. Offline Lunr
  2. docusaurus-search-local
  3. docusaurus-search-local fork - more stars than original

These are just the best I saw. If I had to choose one I would try the docusaurus-search-local fork. I also don't think that we have the documents necessary to warrant a dedicated indexer.

nedjulius commented 1 year ago

https://github.com/algolia/docsearch I thought Algolia docsearch was open-source? it was the most straight forward search integration anyways, very little effort and best support out of the box. of course we can switch if we have issues with docsearch

sachiniyer commented 1 year ago

I think the client is open source, but the actual service is not. Please correct me if I'm wrong.

I think the argument is that if it is an open source club, the software should trend hard to open source.

I am happy to start on a PR.

nedjulius commented 1 year ago

that's true, algolia engine is not open-source. however, they do contribute a lot to open-source -- their cloud service is free and unlimited for all OS projects. maybe that's something that we are ok with? @calvinatian @aminoa thoughts?

sachiniyer commented 1 year ago

I think that the amount of data that is contained in the wiki does not warrant an external search cluster, and ultimately there is not a need to make calls to external third party service. I think we could even do a performance analysis if necessary. Also, there does not need to be a UI change (most of the options I suggested use the same UI).

I will wait for input from @calvinatian and @aminoa before starting a PR.

calvinatian commented 1 year ago

I don't have a strong opinion either way. The local search fork looks good to me.

aminoa commented 1 year ago

I do prefer having our projects attempting to use open source services (at least when feasible); since you highlighted a couple of alternatives, we should try to make the switch.