I was reading the codebase in search of something interesting to fix or improve. One thing that drew my attention is the search API. The current approach uses synchronous I/O to load the docs and in-memory caching. Whilst, considering the current amount of the data to load, cache and parse, this approach is perfectly adequate, it raises the question of whether you have an estimate of how much the amount data for docs/search content and traffic to the site is going to grow over time?
Sync I/O does not pose a bottleneck right now (it probably is even slightly faster than asynchronous approach at least for a trivial amount of concurrent requests.) But if there is a plan to scale the documentation and searchable content, or perhaps advertise it to more potential users of the docs, then the current implementation may not be the best choice.
Of course, it does not seem to be something urgent, but I think it's good to keep in mind that the current implementation is a bit brittle should the project scale up.
A few potential things to improve the API:
- Implement async file operations with a proper error boundaries for async ops
- Add search indexing with full text search. It would obviously remove the "stop word" like "a", "and" etc., introduce stemming, some kind of relevance scoring system (TF_IDF/BM25?) and allow for a fuzzy matching and typos
- Persistent caching (I think that is the most important thing). Currently in-memory cache is bounded only by the amount of the data that is currently searchable. Whilst it's obviously fast, it's even more brittle at scale, so some kind of persistent store like Redis would be a good idea.
Obviously there are open-source solutions like typesense that solve all of that (and more things that I don't even know of) for us. But again, these are valid concerns (at least in my opinion) if you expect the project to grow in the future.
I would love to hear your thoughts on that.
I was reading the codebase in search of something interesting to fix or improve. One thing that drew my attention is the search API. The current approach uses synchronous I/O to load the docs and in-memory caching. Whilst, considering the current amount of the data to load, cache and parse, this approach is perfectly adequate, it raises the question of whether you have an estimate of how much the amount data for docs/search content and traffic to the site is going to grow over time?
Sync I/O does not pose a bottleneck right now (it probably is even slightly faster than asynchronous approach at least for a trivial amount of concurrent requests.) But if there is a plan to scale the documentation and searchable content, or perhaps advertise it to more potential users of the docs, then the current implementation may not be the best choice.
Of course, it does not seem to be something urgent, but I think it's good to keep in mind that the current implementation is a bit brittle should the project scale up.
A few potential things to improve the API:
Obviously there are open-source solutions like typesense that solve all of that (and more things that I don't even know of) for us. But again, these are valid concerns (at least in my opinion) if you expect the project to grow in the future.
I would love to hear your thoughts on that.