appwrite
🚀 Enhancement: Built-in extensive search functionality like Algolia and alike
đź”– Enhancement description
Add a first-party, built-in full-text search service to Appwrite, similar in functionality to Algolia, Meilisearch, or Typesense. This feature would allow developers to perform fast, powerful, and customizable search queries directly on their Appwrite data collections without relying on third-party services.
🎤 Pitch
Search is a key feature in most modern apps, finding blog posts, products, users, or support tickets should be easy. Right now, Appwrite users need to rely on third-party tools like Algolia or Meilisearch to get that functionality. While those work, they add complexity, cost, and external dependencies.
A built-in Appwrite search tool would make it easier for developers to add search systems without leaving the Appwrite ecosystem. It could support indexing specific fields, filtering, ranking, and full-text queries. This would save time, improve performance, and make Appwrite feel even more like a true all-in-one backend.
đź‘€ Have you spent some time to check if this issue has been raised before?
- [x] I checked and didn't find similar issue
🏢 Have you read the Code of Conduct?
- [x] I have read the Code of Conduct
@xMrAfonso, thanks for creating this issue! 🙏 Have you tried using the contains or search queries? Where do they fall short for you?
@stnguyen90 , @xMrAfonso I tested the "search" query functionality and observed the following behavior:
- Searching "run" returns "Running Shoes", which works as expected.
- Searching "runner" does not return "Running Shoes", indicating a lack of support for word variations. X
- Searching "headphone" returns "Bluetooth Headphone", which is correct.
- Searching "hedphone" does not return "Bluetooth Headphone", typo not handled. X
This suggests that Appwriter current "search" implementation doesn’t support stemming (like “run”, “runner”, “running”) or fuzzy matching (handling typos like “hedphone” vs. “headphone”). These are important for a user-friendly and resilient search experience. Supporting these features would greatly improve Appwriter native search capabilities without relying on third-party services.
Hey @stnguyen90, sorry for the very late response, I think @Khizarshah01 essentially pointed out several points, where as I also have a concern regarding performance, I am not sure doing db queries for search in an auto completion basis (even if done every 0.25 or similar) is performant and scalable.
Related: https://github.com/appwrite/appwrite/issues/6838
Damn, 2 year old issue and nothing yet