Oliver Nassar

Open Graph Image Redirect

Another simple experiment (which makes use of my URL Metadata API Endpoint experiment) is similar to how Gravatar works:

You can make a request to an endpoint, passing in a URL. The API will crawl that URL, and if an open graph image is found, simply redirect you to the image URL. If none is found, then the client will get redirect to a default image URL.

Below are some URLs for to to see how it works:

Note: The host og.imnosy.com is simply a 301 redirect to the endpoint https://aws-api.416.io/utils/v1/url/redirect/og

At the moment, the fallback image URL for a URL that doesn't have an open graph image is this cute graphic.

If you want to pass in your own fallback image URL (for example, the image URL https://i.imgur.com/ncMFymv.png), use an endpoint address like the following:

Note: Both the u and f params should be URL encoded.


Below you'll find a couple unexpected challenges I ran into while working on this experiment:

  1. Relative paths: Some sites (including onassar.github.com) don't use absolute URLs when referencing their open graph images. To address this, I wrote some basic URL resolving logic given the URL being requested.
  2. Caching: I didn't want to spend Lambda processing time to retrieve the same URL (and it's associated metadata) multiple times. Therefore, I needed to implement some basic HTTP caching (rather than data caching).

    Having CloudFront in front of the API Gateway resource (which points to the Lambda function) allows me to enforce the cache header without having to trust the user agent and/or client.

Why did I build this?

The initial intention behind building this was to make a lightweight and cachable endpoint to load open graph images for my Bookee extension. With Bookee, I'm trying to design and develop an open source bookmarks explorer.

I want it to be more visual and rather than have all bookmarks simply use a favicon or screenshot, I wanted to make use of open graph images (since those are often custom designed for visual identification).

How was it built?

I again used AWS to facilitate the backend of this tool. Three different services are used:

Cheerio is used for server-side HTML parsing.


If you'd like to use the above endpoints in a production environment, or have any feedback, you can reach me at: onassar@gmail.com.