Scope Question #112
-
|
Hey, great project! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Hey @SeanPedersen - thanks for writing in. Stork likely won't fit this use case -- the indexer isn't built to run in the browser (it's pretty dependent on loading files from a filesystem) and the client-side bit depends on being able to Stork also doesn't support incremental index updates today -- you'd have to re-index everything when users added a new document, which might be prohibitively long. The indexing part is meant to be "heavy" while the searching is "light," and running the "heavy" part in the browser wasn't something I designed it for. Can you tell me more about your project? I think there would need to be some changes to Stork in order to support this, but I'm intrigued by what you're building. :) James |
Beta Was this translation helpful? Give feedback.
-
|
I am asking because CryptPad (end-to-end encrypted Google Docs alternative) lacks a full-text search right now and I thought stork might be a good fit. Ok I see that it is currently out of scope. But yeah IMO that would be a cool use case for stork if feature creep is no concern for you. Incremental index updates and client side storage using IndexedDB could make the use case work. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like an interesting use case! Like James said, Stork probably isn't a good fit for this, but if you do already have all of the information loaded client side and aren't collecting it from a backend, then lunr looks like a project that might fit for this. If you have a mix of server-side and client-side data though, something like Solr might be a better option for incremental indexing, although it's a much more mature project (and thus is a pretty big dependency to set up). |
Beta Was this translation helpful? Give feedback.
-
|
It's all client side, thans for the hints! |
Beta Was this translation helpful? Give feedback.
Hey @SeanPedersen - thanks for writing in.
Stork likely won't fit this use case -- the indexer isn't built to run in the browser (it's pretty dependent on loading files from a filesystem) and the client-side bit depends on being able to
fetch()an index file from the web, rather than having it loaded in from a buffer or something.Stork also doesn't support incremental index updates today -- you'd have to re-index everything when users added a new document, which might be prohibitively long. The indexing part is meant to be "heavy" while the searching is "light," and running the "heavy" part in the browser wasn't something I designed it for.
Can you tell me more about your project? I thin…