Skip to content
This repository has been archived by the owner on Oct 17, 2020. It is now read-only.

[Feature] Extends search API request #970

Open
hemachandarv opened this issue Jul 21, 2020 · 9 comments
Open

[Feature] Extends search API request #970

hemachandarv opened this issue Jul 21, 2020 · 9 comments
Assignees
Labels
enhancement New feature or request

Comments

@hemachandarv
Copy link

What is frustrating you?
Clients of Search API cannot determine directly whether the returned link is matched for Short (or) Long link. Also, clients do not have control over the type of links searched for a particular request.

Your solution
Accept a match-type parameter (Short/Long/All) in the request and return the matched links in the response as separate arrays (ShortLinkMatches / LongLinkMatches).

Additional context
Explored as part of #866

@magicoder10
Copy link
Member

I thought this is by design so that the backend can change the algorithm at any time😲

@hemachandarv
Copy link
Author

I'm not sure I understand what you are saying. Do you think type filter shouldn't be exposed?

@magicoder10
Copy link
Member

@hemachandarv I see what you mean. I think it is exposed. Is it not?

@hemachandarv
Copy link
Author

@byliuyang I could see there is a param for the resource type. I don't see one for the match type (do we match the keywords in the short-links (or) the long-links?). Currently the app does both and ranks them accordingly.

I'm thinking this depends on the use-cases for which the Search is exposed. Do you think we should let the client provide the type of links to match the keywords on?

@magicoder10
Copy link
Member

My main concern is that each attribute has unique way to be ranked. If we exposed, how are we going to expose ranking logic? Or we can abstract out search layer into a library for additional use cases? Could you please draw some UMLs or explain sample exact use cases? I can't just imagine the use cases themselves without knowing what they are. Thanks!

@magicoder10
Copy link
Member

The ranking param & code are in pair.

@hemachandarv
Copy link
Author

I completely agree that each attribute has unique way to be ranked. For now, I see we allow link search only, based on the provided keywords. From what I see in the code, I could think of an use-case where a client wants to get links for the keywords that are matched only in short-link. However, the application returns matches from the long-links as well. This could become an issue if there are no matches in the short-links for the given keywords.

I do not know the current use-cases supported by Search. Would love to know them.

@magicoder10
Copy link
Member

magicoder10 commented Jul 23, 2020

@hemachandarv I am trying to not expose how order is calculated to the client. That's to be said, we are planning to make a generic search engine library for developers to integrate search feature into their own system.

@magicoder10
Copy link
Member

@hemachandarv How about this. Let's expose the API to allow the client to decide what fields we want to be sorted on. If nothing is specified, by default, we sort on both fields.

@magicoder10 magicoder10 changed the title [Refactor] Search API Request & Response [Feature] Extends search API request Jul 23, 2020
@magicoder10 magicoder10 added this to the As soon as possible milestone Jul 23, 2020
@magicoder10 magicoder10 added enhancement New feature or request and removed maintainability labels Jul 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants