Unexpected failures with logo/image

[rahulporuri]

See https://forklore.in/maintainers/anandbaburajan which use png logos that aren't showing up as expected.

[agriyakhetarpal]

This seems to be because the rest of the PNG logos are using raw links and thus work as expected, but the one on Anand Baburajan's page is not:

forklore/content/maintainers/anandbaburajan.json

Line 33 in 2413304

"logo": "https://github.com/anandbaburajan/cq2/blob/main/public/logos/cq2-social.png",

[agriyakhetarpal]

Additionally, since GitHub's raw links are not intended for serving static content over websites, consider using a dedicated CDN instead – GitHack is a suitable alternative. For example, the above URI then becomes

https://rawcdn.githack.com/anandbaburajan/cq2/837852f9484d8aa1c3bd3de636750f278f0138b7/public/logos/cq2-social.png

[rahulporuri]

Thank you for the suggestion @agriyakhetarpal - should be an easy fix. We'll try to address this soon

[rahulporuri]

This image file is larger than it needs to be (1000x1000) for its displayed dimensions (56x56). Use responsive images to reduce the image download size.

Images are the biggest performance painpoint for forklore.in at the moment, and it makes sense that we figure out a longer-term solution for this. A lot, if not all, images fall into the above category/warning, where the images we are using are far larger than what they need to be for our use case.

Here's what I propose - a simple Python utility that downloads the profile and project images, rescales them to a smaller size, and stores them in the codebase (public/ or assets/).

This way, we'll be able to future-proof the project as forklore.in grows, and remove the dependence on external providers.

The Python utility can operate on all available maintainers/ or a specific new maintainer - to ensure that we can migrate all of the existing resources.

NOTE: If we go this route, images that we display might be out of sync with images displayed on other platforms, but we can solve that problem also by adding two fields to the maintainer JSON - photo_url for maintainer image and logo_url for the project URLs. That way, the script can be run (manually or on a schedule) to sync the images we display with what the URLs point to.

@harshtandiya thoughts?

[idlip]

Hi,

So revisiting this back, should we consider getting all image assets to local repo?
Approx count of images might be ~120 at the time of writing.

We can script to store image data and sha256sum number to know if something changed.

[agriyakhetarpal]

Indeed, storing the images locally with their checksums makes the most sense; it's better to avoid querying the GitHub API every time, and it allows featured maintainers to edit their images without tying it with their GitHub profile pictures.