Increase diversity of homepage gallery

[dhruvkb]

Description

The Openverse.org homepage shuffles between 3 collections of images: pottery, universe and olympics. These collections represent a infinitesimal fraction of the 800M+ images in our collection.

pottery	universe	olympics

The goal is to surface the collection of images on the frontend via an API endpoint (that can be cached long-term) so that the list of images can be changed often. We can also use this endpoint to provide topical images based on events, holidays, feature launches etc.

These images can serve as entrypoints for a more exploratory approach to the collection (#2710) rather than one that revolves around search.

Documents

• Project Proposal
• Implementation Plan(s)

Milestones/Issues

Prior Art

There has been some discussion about this on Slack.

[madewithkode]

Hi @dhruvkb this looks like an interesting one, however I see a possibility of the full implementation spanning multiple tasks(between FE and BE/API). Is there a possibility of further breaking it down into smaller more actionable/approachable units? This would be very appreciated as it'd reduce the perceived complexity from a high level overview. Happy to try my hands on it regardless, just might require more time and handholding.

[dhruvkb]

@madewithkode since you have considerable experience with the architecture of the project, would you like to take a stab at breaking it down into smaller issues?

We'd be happy to help if you feel stuck or need assistance.

[madewithkode]

Haha...That was a good comeback! I guess I'd do it afraid then 😂

Would hit you with relevant questions as I proceed.

[madewithkode]

How I would go about this:

First Related Separate Issue - Stack: API

• Expose an API endpoint with support for long term response caching, this should return all(distinct) or specific collections(when specified) alongside relevant images. The number of images would be capped at a certain threshold(say 15/collection, in line with the current implementation).

API response shape might be somewhat like: frontend/src/assets/homepage_images.json

Second Related Separate Issue - Stack: Frontend

• Use new collections API for rendering Homepage Gallery

@dhruvkb Would this be a good starting point?

[dhruvkb]

That sounds good but let's think one step before the endpoint. We need a way to store these image collections, which brings us to the model layer. You should plan what the models for these image collections will look like.

[madewithkode]

Hmmm…it appears my understanding of the problem is limited.

Why would we need a separate data model/storage for just the returned collections?

My thinking is that “collections” in this context loosely refer to categories/tags associated with images/media already in the catalaog DB. Isn’t the endpoint basically meant to:

• extract distinct “collections” across the existing data(Catalog DB)
• for each distinct “collection”, aggregate x amount of images associated with the current collection.
• Cache and return the response.

With the cache above serving as hot storage for as long as it’s valid.
Theses are my current assumptions and I admit I might not have thought so hard about the problem. Happy to be wrong here.