Details

    • Type: Story
    • Status: Closed
    • Priority: Unset
    • Resolution: Fixed
    • Affects versions: None
    • Fix versions: None
    • Labels:

      Description

      As a member of the product delivery team, I want our learners to have ordered cards for listing pages that show the most relevant offerings for them.

      As a member of the engineering team, I want our pages to be hosted in current technology that is easy to work with and well known by the engineering community at edX, so that we can deliver work in the short time to value.

      Backstory:

      See Epic

      Acceptance Criteria:

      1. A proposal for how to sort cards in listings based on the criteria provided by the existing Elasticsearch boosting and facets
        1. This does not need to be using Elasticsearch itself
        2. The sorting algorithm should be configurable going forward
      2. A ticket that will implement this proposal.

      Example search data:

      https://www.edx.org/api/v1/catalog/search?subject_uuids=9d5b5edb-254a-4d54-b430-776f1f00eaf0&do_not_retrieve_all=true&page_size=12

      Identified Approaches:

      1. Use existing search endpoints for each subject and organization
        1. Pros:
          1. Less engineering work
        2. Cons:
          1. Performance (on discovery and in prospectus)
          2. Duplicated data
      2. Create new search endpoint or additional field on subject/org endpoint that excludes serialized DB data (ordered UUIDs and content type only in results)
        1. Pros:
          1. Just the info we need
          2. Higher performance
        2. Cons:
          1. More engineering work
          2. Still a lot of json data if we deliver unpaginated results
      3. Reimplement existing search algorithm in prospectus build process (our custom plugins in gatsby)
        1. Pros
          1. Higher performance
        2. Cons:
          1. More engineering work (up front)
          2. More engineering work (ongoing)
      4. Direct API requests (client side rendered cards) using API gateway
        1. Pros:
          1. Highest performance for generation (no search loading of subject or org pages in gatsby)
          2. Approach reusable for search result page
        2. Cons:
          1. Client side rendered cards will be visibly delayed for users
          2. High engineering work (build cached API gateway)
      5. Prefetch search endpoint data in gatsby and lazy data load of JSON files, with paginated data.
        1. Pros:
          1. Very high performance
          2. Approach reusable for search results page (but not sufficient)
        2. Cons:
          1. Build cost
          2. Some Engineering work
      6. Combo of 2&4 (preload gatsby with initial 12 ordered results, search gateway for paginated lazy load)
        1. Pros:
          1. Very high performance
          2. Approach reusable for search result page
          3. No client side rendering of initial results
        2. Cons:
          1. Highest amount of Engineering work (build cached API gateway and new endpoint or field extension)
      7. Combo of 2&5 (preload gatsby with initial 12 ordered results, use prefetched data for paginated lazy load)
        1. Pros:
          1. Very high performance
          2. Approach reusable for search result page (but not sufficient)
          3. No client side rendering of initial results
        2. Cons:
          1. High amount of Engineering work (build cached API gateway and new JSON files)

        Attachments

          Activity

            People

            • Assignee:
              mdikan Mike Dikan
              Reporter:
              mdikan Mike Dikan
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: