Enhance Search bar with autosuggestion and pagination from client based to server based

[Hayat4144]

Is this a unique feature?

• I have checked "open" AND "closed" issues and this is not a duplicate

Is your feature request related to a problem/unavailable functionality? Please describe.

The current implementation of the search bar employs a client-side pagination strategy, leading to suboptimal performance, especially when dealing with large datasets. One major concern is that the entire document is loaded into the client's memory, resulting in increased latency and potential performance bottlenecks.

The current approach may cause delays in rendering search results, leading to a suboptimal user experience. Users may experience laggy interactions and slower page loads, affecting the usability of the search functionality.

Proposed Solution

I propose enhancing the current search functionality by adding an autosuggestion feature to the existing search bar and optimizing pagination from client-based to backend-based for improved performance.

Feature 1: Autosuggestion in Search Bar

Implementing autosuggestion in the search bar can significantly improve the user experience by providing real-time suggestions as users type. This feature can help users refine their search queries, discover relevant content faster, and reduce the likelihood of typos or errors in their input.

Feature 2: Backend Pagination for Improved Performance

Currently, pagination is handled on the client side, which may lead to suboptimal performance, especially when dealing with a large dataset. By transitioning to backend pagination, we can improve the efficiency of data retrieval and reduce the load on the client. This change can result in faster page load times and a smoother overall user experience.

Proposed Changes:

Autosuggestion in Search Bar

1. Implement a mechanism for real-time autosuggestions as users type in the search bar.
2. Provide an option for users to easily select and apply suggested queries.

Backend Pagination:

1. Refactor the pagination logic to be handled on the server side.
2. Introduce API endpoints that support paginated data retrieval, allowing clients to request specific subsets of data.
3. Update the client-side implementation to make use of the new backend pagination endpoints.

Screenshots

Here is the some of the screen shot how the ui will looks after the changes.

Do you want to work on this issue?

Yes

If "yes" to above, please explain how you would technically implement this

I already solve this problem with mongodb search index and aggregation . if you agree with this features i will make a pull request.

[github-actions]

To reduce notifications, issues are locked until they are 🏁 status: ready for dev You can asked for this issue to be assigned (if not already assigned) and to be assigned. You can learn more in our contributing guide https://github.com/EddieHubCommunity/BioDrop/blob/main/CONTRIBUTING.md

[sital002]

@Hayat4144 Thanks that's a great description on the issue. Can you explain how the auto suggestions work will it make network request to the server on every onChange
event.

@eddiejaoude What are your thought on this.

[Hayat4144]

Let me explain the how we achieve it .

When we building features like auto suggestion, one thing makes into mind is performance and I am agree with it. The search page is combination of different components, we will create a separate components for search which will prevents re-render of the parent component.We will not making server request on every onChange event ,instead we will use debouce concept . It means when the user stop typing then we will make a server request and instead of using useState hook for managing input tag value we use search params and set it default value of input tag.

And on the Backend side , we will create two index in mongodb atlas first one is for search and second one is for autosuggestion . we will create a new api route for autosuggestion called /api/search/autosuggestion , this endpoint handle the autosuggestion functionality with mongodb aggregation pipeline with limit to 7-10 suggestion at a time . In existing api routes called /api/search we will make some changes we will receive the tags or username in search query and create unique aggregation pipeline for both scenario . The existing code will read the whole model documents and use client side pagination which is inefficient and time consuming process. we ensure to use aggregation pipeline with pagination and limit the data to read.

[eddiejaoude]

This sounds great 👍 awesome collaboration 💪

I have a question, will this also working on a local version of mongo? So dev (local) will be the same as prod (Atlas)? I heard this is now possible with recent changes by mongo

[Hayat4144]

According to my current knowledge ,the autosuggestion and full text search is only available in Cloud Atlas . I don't know autosuggestion and full text search feature exist or not in recent version of mongodb . I will check it and informed you if I get any information related to it.

[Hayat4144]

I don't think so the autosuggestion is available in mongodb in Os. It is only exist in cloud.

[eddiejaoude]

I don't think so the autosuggestion is available in mongodb in Os. It is only exist in cloud.

How would this affect developing locally? Would it break or return no results or something else?

[Hayat4144]

It throw error in local development , but we can prevent it from error. Here is the solution for it.
We use Atlas cloud for production and local mongodb while in development mode. We write logic for handling search functionality based on the app environment in both in frontend and backend , if it is in development mode we use previous logic and if it is production mode we use atlas search logic same with frontend. we just changed ui nothing more than it.

Here is basic code how it will be done :

```js
const SeachLogic= ()=>{
   if(!development){
  // here is  production logic
  }else{
  // development login
   }
}

[akshat-khosya]

We can use concept of tries to autocomplete the words that user trying to enter, just like google search.

[eddiejaoude]

We write logic for handling search functionality based on the app environment in both in frontend and backend

I am not keen on this because it will create not only extra code but also when we get bugs and we won't know about them

[Hayat4144]

We have to just create the database in cloud add search index.

[eddiejaoude]

It looks like Atlas features are available locally now https://www.mongodb.com/blog/post/introducing-local-development-experience-atlas-search-vector-search-atlas-cli

ℹ️ eddiejaoude has some opened assigned issues: 🔧View assigned issues

[Hayat4144]

if Mongodb Atlas search is available in the local version it's good . we just need mongodbUrl connection which support atlas search either in cloud or locally. Now, Atlas search exist in local database, we should implement this feature.

[Abhishek-90]

We can also take it step by step, breaking it up more.

Firstly, let's create an api for auto suggestions as suggested by @Hayat4144 and test is rigorously on both local and production. If we are satisfied with the results, then we can integrate this api in frontend.

Coming to frontend, currently we are able to see the results after the user clicks on search button. So if we are to implement this feature how will the suggestions appear? Will are be a dropdown of suggestions like youtube and google or will we directly show the profile like we are currently doing?

[Hayat4144]

We can also take it step by step, breaking it up more.

Firstly, let's create an api for auto suggestions as suggested by @Hayat4144 and test is rigorously on both local and production. If we are satisfied with the results, then we can integrate this api in frontend.

Coming to frontend, currently we are able to see the results after the user clicks on search button. So if we are to implement this feature how will the suggestions appear? Will are be a dropdown of suggestions like youtube and google or will we directly show the profile like we are currently doing?

The suggestion will appear as users type in the search bar and a popover will be open just below the search bar. see the below image

[Abhishek-90]

We can also take it step by step, breaking it up more.
Firstly, let's create an api for auto suggestions as suggested by @Hayat4144 and test is rigorously on both local and production. If we are satisfied with the results, then we can integrate this api in frontend.
Coming to frontend, currently we are able to see the results after the user clicks on search button. So if we are to implement this feature how will the suggestions appear? Will are be a dropdown of suggestions like youtube and google or will we directly show the profile like we are currently doing?

The suggestion will appear as users type in the search bar and a popover will be open just below the search bar. see the below image

Ok and when we click on suggestions, we will be redirected to view the full information of the user, correct?

I have one other suggestion, instead of adding a new feature to get suggestions, how about we remove the search button all-together. What we can do is, merge this suggestion and search feature. As mentioned by @Hayat4144 we will use debounce pattern. When user types in search we will hit the api without clicking on search button. and directly populate the data to view the profiles. The benefit of this approuch would be:

1. Less UI changes, we don't need to create a new suggestion dropdown list to show the suggestion, we will be utilizing current view only.
2. No need to create a new api end-point, rather makes changes to existing to search api endpoint.

[Hayat4144]

The existing search functionality is something like the below steps:-

1. user give their input either tag or name and click on the button.
2. it will it hit the /api/search endpoint where the whole database users is fetched and then some logic to retrive the similar users based on the tag or name. This is silly thing. we don't need to fetch every user and then extract the related user.
3. the response will be send back with list of users .
4. it will shown in the ui.

Here is what i suggest

1. create one more endpoint for the autosuggestion , when the start typing we will hit this endpoint it will fetch the users based on search query and send it back to the client.
2. the autosuggestion api response will be shown just below the search bar with popover .
3. In third step we have two choice when the user click on one of the result we will either fetch by name or tags.
4. Response will be shown on the page

Using either Tag or Name have advantage and disadvantage
if we use tag for fetching the final users , we will fetch the all users have similar tag but 90% the user details we click on will be not shown in the top,we have to add some sort of scoring in mongodb similar to Rank we do int postgres Full text search.

if use name we will fetch the user having similar name, but not with similar tags.
Currently , I implemented with tags.