Image search by keywords [4 days]

[jimcky]

Need #1
Needed by #7

• Support search by keywords / partial keywords (case insensitive)

• Support search by partial uploader name, case insensitive

• Paginated API that returns 15 images at a time

• API Status code / property that tells the client application it's the end page

• property that tells the client application how many results were returned by the query

• return basic metadata for each images (profile image link, uploader username, like count)

• keywords must be 2 - 64 characters, support unicode characters
  Error message:

  The keyword you entered is too long. Please try again with a keyword that's less than 64 characters long

• Shows loading indicator

• Shows end page indicator when no more results are returned

• Do not allow user to search with empty query

• order image by like count and upload time - if 2 images have the same like count, the one uploaded last will be shown first

Created from Aha! https://oursky.aha.io/features/PUT-3

[rickmak]

Implementation planning for backend

• Add ipld data to postgres for searching, i.e. description
• Call for confirm: for searching tag, assume it will start with #. For searching image from user , assume it start with @. Other string without prefix will regard to search the description.
• Paginated API, design pending. Initially will opt for cursor approach.
• Add LikeCount to DB. relating to the asset, will put at another table.

est 4.hrs

[jimcky]

👍

[inDream]

Paginated API:

Request

Example: /api/assets/search?q={keyword}&after=[curosr]&first=10

• q: keyword
• after: (Optional) return result after item referred by cursor
• first: (Optional) total number of result

Response

{
  data: [{ id: 1, ... }, { id: 2, ... }],
  page_info: {
    has_next_page: true,
    has_prev_page: true,
    start_cursor: '{base64 encoded string}',
    end_cursor: '{base64 encoded string}',
  }
}

Cursor:

For search result cursor should contain result index for SQL OFFSET
For basic user profile images could use timestamp for SQL WHERE createdAt > [ts]

[rickmak]

The above paginate API is inspired by https://facebook.github.io/relay/graphql/connections.htm#sec-undefined.PageInfo

Main objective to adopt cursor base API is to avoid back-end sorting knowledge leaked to front-end.

Example usage

// First call
GET /api/assets/search?q={keyword}
{
  data: [{ id: 1, ... }, { id: 2, ... }],
  pageInfo: {
    totalCount: 20,
    hasNextPage: true,
    hasPrevPage: false,
    startCursor: null,
    endCursor: '{base64EndCursor}',
  }
}
// Next call
GET /api/assets/search?cur={base64EndCursor}
{
  data: [{ id: 1, ... }, { id: 2, ... }],
  pageInfo: {
    totalCount: 20,
    hasNextPage: false,
    hasPrevPage: true,
    startCursor: '{base64StartCursor}',
    endCursor: null,
  }
}

i.e. the cursor is just a string for front-end. It should contain all information that backend required to query next page.

An initial list of info contains in the payload

1. keywords
2. id of last/first element
3. timestamp of last query make
4. page size

later may can have more condition, like exlcuding, like count limit, etc. But still the front-end scrolling don't need the knowledge what is inside the cursor.

[inDream]

Or could use this format https://developers.facebook.com/docs/graph-api/using-graph-api/#cursors
This contains url for next request and no need to check boolean has_next_page.

{
  "data": [],
  "paging": {
    "cursors": {
      "after": "MTAxNTExOTQ1MjAwNzI5NDE=",
      "before": "NDMyNzQyODI3OTQw"
    },
    "previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OTQw",
    "next": "https://graph.facebook.com/me/albums?limit=25&after=MTAxNTExOTQ1MjAwNzI5NDE="
  }
}