Forem: Bryce Dorn

Mini site for recommending songs using Svelte & Deno

Bryce Dorn — Sat, 03 Feb 2024 16:31:29 +0000

Introducing a new way to recommend a song to your friends: listn.fyi! Simply create a public Spotify playlist and name it "listn.fyi" (without quotes) then head to the URL for your Spotify username (e.g. listn.fyi/combatfetus). Et voilà! The link is shareable and any changes to your playlist will reflect immediately on the website.

I figure this could be a fun and easy way to share what you're currently into and see what others are recommending as well. Maybe a cheeky addition to a Twitter bio, etc.

Behind the scenes is a simple Sveltekit-powered server function to fetch a Spotify client token then find a user's recommendation playlist and its track information. A Deno edge function to performs this data fetch and renders server-side Svelte.

And shoutout to Rob for the beautiful CSS record player, which I borrowed (with credits) and made some modifications to. Long live skeuomorphism!

I must admit, the Sveltekit developer experience in 2024 is a lot nicer to work with than what I'm used to in the React/Vue/Next world. The filesystem-based router seemed like it would be a pain but was pleasantly surprised by how simple and clean it is to actually use. Looking forward to using it more for projects like this.

Check out the source below & let me know what you think!

brycedorn / listn.fyi

Recommend a song to your friends via a playlist! Try it out: https://listn.fyi/combatfetus

Building APOD color search part III: Deno Search API 🔎

Bryce Dorn — Fri, 21 Apr 2023 16:27:29 +0000

If you're following along, this is the third part in a series about how I built APOD color search.

Simple search API 🔎

This is the layer that powers a /search endpoint to check the cache for results from previous searches, and if there are none then query the prepopulated database and store in cache. It's written in Deno and continuously deployed using Deno Deploy.

Why Deno? 🦕

I like Deno for a variety of reasons, but first and foremost: it's fast. Native TS support is also nice, and Deno Deploy is a quick (and free) hosting service. Overall, it feels great to work with and is perfect for smaller projects.

Although it's somewhat overkill for the project I decided to use fresh as it provides some basic routing and scaffolding. There's a helpful supabase Deno package as well that I used to query the database.

Finding color matches 🎨

To simplify the /search endpoint, the query is included in the URL as a route parameter. This is practical because the only relevant query is a six character string, being a hex color (e.g. /search/:hex).

In fresh, a dynamic route like this is created using the filename [param].ts under the directory that the route expects, and in a request the value will be added to context with this name. So in my case, this means a directory named search containing a file named [hex].ts.

Now let's add a simple handler to get the hex param from context and return an empty response:

export const handler = async (
  _req: Request,
  ctx: HandlerContext,
): Promise<Response> => {
  const { hex } = ctx.params;

  ...

  const data = [];

  return new Response(JSON.stringify({ data }), {
    status: 200,
    headers: { "Content-Type": "application/json" },
  });
}

Great, now to return results generated via the image analysis from before! (The data structures are described there and will make this part more clear.)

First, we'll need a connection to the database. Assuming these credentials are stored in an .env:

import "https://deno.land/x/dotenv@v3.2.0/load.ts";
import { createClient } from "https://esm.sh/@supabase/supabase-js@1.35.4";

const supabase = createClient(
  Deno.env.get("SUPABASE_URL") as string,
  Deno.env.get("SUPABASE_PUBLIC_API_KEY") as string,
);

Then, once we convert the hex value back to RGB we can then perform a query stringing multiple filters on the colors table together to get colors within a certain threshold of the input color:

const THRESHOLD = 30;
const [r, g, b] = hexToRgb(hex);

const { data: colors } = await supabase
  .from("colors")
  .select()
  .gt("r", r - THRESHOLD)
  .lt("r", r + THRESHOLD)
  .gt("g", g - THRESHOLD)
  .lt("g", g + THRESHOLD)
  .gt("b", b - THRESHOLD)
  .lt("b", b + THRESHOLD);

This will give us a (long) list of colors, but this enables fetching a list of clusters from these colors to be sorted by raw distance to the original search color by comparing red, green and blue color values:

const { data: clusters } = await supabase
  .from("clusters")
  .select()
  .in("color_id", colors?.map(({ id }) => id))
  .limit(15);

clusters.sort((a, b) => minimizeDistance(a, b));

The source for the minimizeDistance function above can be found in utils.ts. Finally, once the most relevant clusters are found we can return the actual APODs:

const { data } = await supabase
  .from("days")
  .select()
  .in("id", clusters?.map(({ day_id }) => day_id))
  .limit(5);

return new Response(JSON.stringify({ data }), {
  status: 200,
  headers: { "Content-Type": "application/json" },
});

Success! This API is deployed here if you want to play with it. This is the project on Deno Deploy and is used by the deployed FE.

Caching results 🗂️

As mentioned earlier, there's also a caching layer to prevent unnecessary/repeated requests from forcing expensive database queries. I added simple calls to redis before each hex and color/cluster query, using Redis Enterprise Cloud's free tier.

Generate placeholder images at edge with thumbhash

Bryce Dorn — Thu, 13 Apr 2023 18:40:51 +0000

Continuing my journey to build a performant edge-cached blog! It's built on top of Cloudflare Workers, here was my last update on it:

Using Workers KV to build an edge cached blog 🌍

Bryce Dorn ・ Jun 3 '22

#javascript #webdev #serverless #showdev

It's been a fun sandbox to play with edge functions, and after coming across an interesting algorithm for minimizing images I was inspired to augment this project with it.

Pageload bottleneck 🌁

While using KV enables globally distributed data and shorter request latency, there's still one aspect of page performance that's a major bottleneck: loading images.

This tends to have the largest impact on performance regardless of server location, and in my case even though the data associated with each post is stored at the edge the image behind each URL must still be downloaded by each client.

I'm not looking to solve distributed image hosting (yet) so in the meantime, I built a simple image processing solution using thumbhash to store a tiny, base64-encoded version of the image to display while the full image is downloaded.

Enter: thumbhash 👍

I came across this HN post from last month that caught my interest with some impressive performance stats. Here is the repository on GitHub:

evanw / thumbhash

A very compact representation of an image placeholder

While it's similar to BlurHash, the color performance is much better for the same filesize. Here's a a demonstration of this from the demo page (with ThumbHash in the middle and BlurHash on the right):

Most importantly though, the blurred images are tiny (<1% original image size!). This makes it practical to consider storing them as encoded strings, which I intend to do. The project features an implementation in JS & I was confident it would be a great candidate for adding placeholder images to the site!

The implementation details below are specific to my project but the principles can be applied to anywhere there's server-side JS.

Generating thumbhash as part of edge caching process 🎞️

Building on the KV caching approach from earlier, a base64 representation of the cover image can be generated and included with post data. As stated before I don't want to worry about hosting images so storing the encoded image as a string avoids this.

Image manipulation is easy to do with client-side JS and canvas, but as this is on the server some additional packages make it possible. I used jpeg-js to decode the image:



import { decode } from 'jpeg-js'
import pica from 'pica'

const res = await fetch(imageUrl)
const arrayBuf = await res.arrayBuffer()
const decoded = decode(arrayBuf, { useTArray: true })
const { width, height, data } = decoded

Then pica to resize it and a simple function I wrote to crop it:



const imageWidth = Math.floor((width / height) * 100)

const resized = await pica().resizeBuffer({
  src: data,
  width,
  height,
  toWidth: imageWidth,
  toHeight: 100,
})

const cropped = cropMid(resized, imageWidth, 100)

Then all that's needed is to generate the thumbhash from this Uint8Array:



import { thumbHashToDataURL, rgbaToThumbHash } from 'thumbhash'

const thumbhash = rgbaToThumbHash(100, 100, cropped)

return thumbHashToDataURL(thumbhash)

Nice! So now that this tiny blurred version of the image is on-hand the last step for a good user experience is to display it initially then replace it with the actual image once it's loaded in the background.

Loading the full-sized image 😴

Normally I would write some client-side JS to do this but as this project is solely server-rendered I opted to use a simple tried-and-true library for this: lazysizes.

This is as simple as adding a data-src attribute and lazyload class, with the original src set to the base64 thumbhash generated earlier:



<img 
  class="lazyload blur-up" 
  src={post.thumbhash} 
  data-src={post.cover_image}
/>

Then after including the script tag in the renderer it Just Works™️! I followed the steps to add the blur/unblur effect as well, as you can see from the blur-up class.

This is now active on blog.bryce.io, go check it out! And if your internet is too fast to notice it, try throttling to 'Slow 3G' via dev tools. Thanks for reading & stay tuned for the next thing I do with this pet project 😇

Building APOD color search part II: Computing in cloud ☁️

Bryce Dorn — Sun, 12 Mar 2023 12:25:58 +0000

If you're following along, this is the second part in a series about how I built APOD color search.

In this post I'll cover how everything was built with the intent to run via a hosted service instead of a local environment/database. Making things cloud-first puts more effort up front but saves a tremendous amount of time when deploying and running remotely.

Everything via GitHub Actions 🛰️

Since processing images for this project involves iterating over a large dataset, it was clear early on that the amount of computation was going to be immense. This would require processing things over a long period of time and ensuring consistency when there are any errors.

I already had some experience with GitHub Actions (their native CI/CD framework) and after finding rust-toolchain I wanted to experiment with whether it'd be feasible to use Actions as a compute service.

Turns out: works great! ✨ The hardware is more than sufficient to do CPU-bound image processing, and the only issue that I encountered related to builds stopping due to hitting my account limit of 50 compute hours/month. But with the Actions UI I was able to trigger workflows and process batches of APODs one year at a time over the course of a few months.

Rust in action(s) ⚡️

The Rust-based utility to process images from the previous article can be invoked via CLI. To be able to do this in an Action, the environment must have the right dependencies installed and appropriate environment variables.

A safe way to handle environment variables is via GitHub's encrypted secrets - it requires manually copying values from a local .env file used for development but it's better than storing unencrypted values in your repository. For this project, the Rust script fetches from apod-api and saves to a supabase Postgres instance, hence the keys for SUPABASE_* and APOD_API_*.

For the environment to have Rust installed, including the dtolnay/rust-toolchain@stable toolchain will ensure it can be used in the action:

name: Process images for month
env:
  SUPABASE_REST_URL: ${{ secrets.SUPABASE_REST_URL }}
  SUPABASE_URL: ${{ secrets.SUPABASE_URL }}
  SUPABASE_PUBLIC_API_KEY: ${{ secrets.SUPABASE_PUBLIC_API_KEY }}
  APOD_API_URL: ${{ secrets.APOD_API_URL }}
  APOD_API_KEY: ${{ secrets.APOD_API_KEY }}
jobs:
  process-images-for-month:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Install Rust 🦀
        uses: dtolnay/rust-toolchain@stable
        with:
          components: rustfmt, clippy
          toolchain: stable

Dispatching via workflow UI 🛎️

The only remaining piece is to have a way to trigger the workflow to process images. The on field is the entrypoint for when a workflow runs, and thankfully there's a way to trigger directly from GitHub's UI.

Adding an on: workflow_dispatch will provide an entrypoint to run the workflow via the Action UI with given inputs. These arguments can then be referenced via github.event.inputs in the run command:

...

on: 
  workflow_dispatch:
    inputs:
      year:
        description: 'Year'     
        required: true
      month:
        description: 'Month'     
        required: true

...

jobs:

    ...

    - name: Run 🤖
      run: cargo run -- ${{ github.event.inputs.year }} ${{ github.event.inputs.month }}

Once that is pushed to the main branch for the repository, the option to dispatch should be available. Simply navigate to the workflow under the 'Actions' tab:

And on the right side of the table of workflow runs will be a 'Run workflow' option (will inform you that this is because the "workflow has a workflow_dispatch event trigger"):

Assuming all secrets are in order, triggering a run will kick of a build to process the images!

Lastly, I added a couple additional jobs to avoid formatting errors or regressions when the workflow runs with new commits:

...

jobs:

    ...

      - name: Lint 🧹
        run: |
          cargo fmt --all -- --check
          cargo clippy -- -D warnings

      - name: Test 🔨
        run: cargo test
    ...

This made it super easy to trigger a bunch of workflows in parallel to process images over time. Would highly recommend using them for small projects like this, assuming your requirements aren't too resource-intensive.

Blobby image animation in CSS 🦠

Bryce Dorn — Fri, 10 Mar 2023 17:19:17 +0000

Was bored on a Friday and whipped up a fun little animated image using CSS:

It overlays multiple elements with the same background image rotated at different intervals. To align the images to the same plane and stitch them together each element is first rotated back (using the :before pseudo-element) then resized and positioned accordingly.

Then, by adding overflow: hidden; to the parent element, the image is cropped to the border-radius value of the pseudo-element and enables it to take a shape!

Since each image is technically in the same position but with a different parent the values for dimensions and positioning must be identical. This was slightly tricky as the height & width vary slightly with the different rotations (thanks to geometry), so the image needs to be stretched a bit.

You can see how this is handled here:

For the animation, it uses a simple keyframes rule to smoothly transition border-radius values. Each div has an animation-delay value to offset and create a directional effect.

Hope this was a good showcase of how easy it is to easily create complex animations using basic CSS/HTML!

Server-render your SPA in CI at deploy time 📸

Bryce Dorn — Thu, 02 Mar 2023 10:47:36 +0000

If you deploy your SPA using GitHub Actions you can add this new action to your workflow to have it build server-rendered HTML!

Server-side rendering (SSR) is great for SEO and performance. I use it for projects that have an expensive initial render or have links that I want to be discoverable.

react-snap is a tool to help with SSR; a while ago I wrote about it:

Perform a React disappearing act with react-snap ✨🧙💨

Bryce Dorn ・ Jan 23 '20 ・ 3 min read

#javascript #react #webdev

I've been using it as a postbuild script but it recently broke in CI. The fix for it became rather complex, so rather than include this in each project that I use it for I decided to bundle everything into a standalone action. This also significantly reduced the number of per-project dependencies as it prevents installing big ones like puppeteer.

Though react is in the name, this will work for any framework that supports hydration. In Svelte for example, this just means switching the hydrate flag:

import App from './App.svelte';

const app = new App({
  target: document.querySelector('#server-rendered-html'),
  hydrate: true
});

Once your app is hydratable, replacing your build step with this action will run npm build followed by react-snap:

jobs:
  prerender:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      ...

      - name: Server-side render
        uses: brycedorn/react-snap-action@v1.0.2

You can then deploy this to GitHub Pages or wherever. Give it a try and let me know if it helps simplify your workflow!

brycedorn / react-snap-action

Github Action for pre-rendering via react-snap.

Building APOD color search part I: Image analysis in Rust

Bryce Dorn — Thu, 23 Feb 2023 17:45:19 +0000

Kicking off the first of a series about how I built APOD color search! For an introduction to the project (and some background on Astronomy Picture of the Day) go here:

Building an app to search the APOD archive by color 🪐

Bryce Dorn ・ Feb 18 '23

#webdev #showdev #javascript #rust

From a high level, a search like this cannot be done on-the-fly as it requires a static index of image and color information to return results. So, the first step here is to devise a way to extract relevant color information from each image.

Gathering the data 🚜

On to populating the dataset - image analysis is a low-level operation. Given that there's nearly two decades worth of images to process, this needed to be fast and performant.

The full source code can be found on GitHub, but I'll go through some of the essential bits here.

Processing data for an APOD 🌌

To populate the searchable color-based index of each APOD, three things must be done:

Fetch APOD information via apod-api.
Extract color information from image.
Store color metadata in database.

One of my goals for this project was to use cloud-first (and free) resources whenever possible to save headaches later on with deployments & environments. For the database above I created a Postgres instance using supabase's free tier.

Getting a day's APOD information

Fetching this data is easy enough using reqwest and the apod-api (just need an API key):

let api_url = "https://api.nasa.gov/planetary/apod";
let api_key = std::env::var("APOD_API_KEY").unwrap();
let request_url = format!(
  "{}?api_key={}&start_date={}&end_date={}",
  api_url, api_key, start_date, end_date
);

let resp = reqwest::get(request_url).await?;
let body = resp.text().await?;

To do more with this data however, Rust requires that it be properly typed. serde streamlines this with built-in JSON serialization; it only requires a static type and can handle the rest. Here's the type I added to correspond to the API response:

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
pub struct Day {
  id: Option<u32>,
  copyright: Option<String>,
  date: String,
  explanation: Option<String>,
  hdurl: Option<String>,
  media_type: String,
  service_version: Option<String>,
  title: String,
  url: Option<String>,
}

Then calling serde_json::from_str will deserialize it to the typed data structure:

use serde_json::json;

let days: Vec<Day> = serde_json::from_str(&body).unwrap();

Lastly, once we have a Day object to work with, we need to fetch the actual image bytes to do pixel-based analysis:

use crate::image_utils;

let img_bytes = reqwest::get(&image_url).await?.bytes().await?;
let img = image::load_from_memory(img_bytes)?;

Processing the colors 🔬

Now all that's left is some low-level pixel processing. This isn't the most efficient algorithm as I'm still a novice Rustacean so it's the best I could do. 😇

Because these images tend to be massive, the most important pieces are around removing noisy data to avoid unnecessary computation. In this case, only analyzing significant pixels and then counting, ranking and grouping them together.

Many images have a minimal amount of color information, being either grayscale or mostly black due to the vast emptiness of space. As "color" is in the name, the project is more intended to enable finding colorful pictures, not specific hues of black/gray. To not waste computation time on these, I filtered out the non-colored pixels:

let gray_pixels: HashSet<Rgba<u8>> =
  img.grayscale().pixels().into_iter().map(|p| p.2).collect();
let all_pixels: Vec<Rgba<u8>> = img.pixels().into_iter().map(|p| p.2).collect();

let colored_pixels: Vec<Rgba<u8>> = all_pixels
  .into_iter()
  .filter(|p| !gray_pixels.contains(p))
  .collect();

Then, using a relative luminance function, only included the most luminous pixels:

let luminous_pixels: Vec<Rgba<u8>> = colored_pixels
  .into_iter()
  .filter(|p| get_luminance(*p) > 50.)
  .collect();

Now we're left with a cleaner dataset to work on.

Generate frequency array

To get the most frequent colors of the image, the primary goal of this analysis, a frequency hash can be used. Put simply, a string/number map of color values to how many times they occur. For easier typing, each pixel is converted from RGB to String (hex value):

use colorsys::Rgb;

pub fn generate_hex(pixel: Rgba<u8>) -> String {
  Rgb::from((
    pixel[0] as f32, 
    pixel[1] as f32, 
    pixel[2] as f32)
  ).to_hex_string()
}

Vec::from_iter(input)
  .into_iter()
  .map(generate_hex)
  .collect::<Vec<String>>()

We can then generate a BTreeMap of type { [hex: string]: frequency: number } by iterating over this list and incrementing when the same hex value is found.

To optimize for performance, the function splits the image into chunks and spawns multiple threads to run in parallel before joining them together once complete. I experimented with different values for worker_count and landed on 5 as most optimal:

use std::collections::{BTreeMap, HashMap, HashSet};
use std::sync::{Arc, Mutex};
use std::{i64, thread};

pub fn get_frequency(
  input: Vec<String>, 
  worker_count: usize
) -> BTreeMap<String, usize> {
  let result = Arc::new(Mutex::new(BTreeMap::<String, usize>::new()));

  input
    .chunks((input.len() as f64 / worker_count as f64).ceil() as usize)
    .enumerate()
    .map(|(_, chunk)| {
      let chunk = chunk.iter().map(String::from).collect::<Vec<String>>();

      let rresult = result.clone();

      thread::spawn(move || {
        chunk.iter().for_each(|h| {
          rresult
            .lock()
            .unwrap()
            .entry(h.to_string())
            .and_modify(|e| *e += 1)
            .or_insert(1);
        })
      })
    })
    .for_each(|handle| handle.join().unwrap());

  Arc::try_unwrap(result).unwrap().into_inner().unwrap()
}

Once the most frequent color values are found, similar ones can be grouped together. I refer to these as Clusters; if a color has R, G, & B values within a certain threshold of each other they are combined into the same Cluster.

The threshold algorithm is a simple series of conditions that only checks for the green value if the value for red is within the threshold, and so on:

pub fn within_threshold(
  a: &Rgba<u8>, 
  b: &Rgba<u8>, 
  color: usize, 
  threshold: i64
) -> bool {
  let color1 = a.0[color] as i64;
  let color2 = b.0[color] as i64;

  let mut min = 0;
  let mut max = 255;

  if color2 >= threshold {
    min = color2 - threshold;
  }

  if color2 <= (255 - threshold) {
    max = color2 + threshold
  }

  color1 >= min && color1 <= max
}

pub fn assign_clusters(
  input: Vec<(Rgba<u8>, usize)>, 
  threshold: i64
) -> HashMap<Rgba<u8>, usize> {
  let mut result = HashMap::<Rgba<u8>, usize>::new();

  for item in input {
    let s_r: Vec<Rgba<u8>> = result
      .into_keys()
      .filter(|p| within_threshold(p, &item.0, 0, threshold))
      .collect();

    ...

The closest color value matches are then added to the Cluster. Once the clusters are finalized, the last step here is to only return the most popular ones. This is done with a simple sort_by call:

let mut sorted_result = Vec::from_iter(result);
sorted_result.sort_by(|(_, f_a), (_, f_b)| f_b.partial_cmp(f_a).unwrap());
let size = std::cmp::min(num_clusters, sorted_result.len());
sorted_result[0..size].to_vec()

And now we have the most significant clusters! This makes it possible to search for a color and map to images that contain many pixels with that color.

One month at a time 🗓️

Processing a single APOD is one thing, but the end goal is to process all of them. The cleanest way to group batches of days was by month. As the apod-api supports start_date and end_date parameters to support this, I just used the first and last days of the month for these parameters.

Since I knew I'd be running this via command line I first checked the arguments provided (year and month) and if they correlated to a valid date for an APOD. Since this will map from raw numbers to chrono::Date objects, some serialization is needed:

let args: Vec<String> = env::args().collect();
let first_apod = Utc.ymd(1995, 6, 16);
let today = Utc::today();

let numbers: Vec<u32> = args.iter().flat_map(|x| x.parse()).collect();
let day = Utc.ymd(numbers[0] as i32, numbers[1], 1);

if day < first_apod || day > today {
  Err(format!(
    "Out of range, date must be between {} and {}.",
    first_apod.format("%b %e, %Y"),
    today.format("%b %e, %Y")
  ))?;
}

Then, given that it's a valid month we can iterate over each day. I added a fetch_month function to generate a list of Days for a month given the first day, as a chrono::Date generated by the above arguments:

async fn fetch_month(
  first_day: chrono::Date<Utc>
) -> Result<Vec<api::Day>, Box<dyn Error>> {
  let first_day_formatted = first_day.format("%Y-%m-%d").to_string();
  let today = Utc::today();

  let mut last_day = (
    first_day + Duration::days(31)
  ).with_day(1).unwrap() - Duration::days(1);

  if last_day > today {
    last_day = today;
  }

  let last_day_formatted = last_day.format("%Y-%m-%d").to_string();

  let apods = api::get_days(&first_day_formatted, &last_day_formatted).await?;

  Ok(apods)
}

After getting the data for an entire month it's as simple as iterating over each day and processing it:

let apods = fetch_month(day).await?;
let mut i = 1;

for apod in apods {
  process_apod(apod).await?;
  i += 1;
}

I didn't include this in the code snippets, but things are saved via Postgrest along the way - most importantly Colors and Clusters which are used to perform searches. Feel free to have a look at the full source to see these.

Thanks for reading & stay tuned for the next part: using GitHub Actions as a free provider to run it in parallel remotely!

Building an app to search the APOD archive by color 🪐

Bryce Dorn — Sat, 18 Feb 2023 21:04:49 +0000

tl;dr, I built apod-color-search!

The news of the James Webb Space Telescope (JWST) being successfully deployed in orbit reminded me how fascinating outer space is. Hubble has already showed us how spectacular and unfathomably large the visible universe is, and now with JWST it's like Earth just received a much better glasses prescription!

If you haven't been following, here's a compelling side-by-side comparison of the same nebula as seen by both telescopes posted to NASA's Instagram:

Long before these pictures started being shared via social media however, Astronomy Picture of the Day (APOD) established itself as one of the first websites for this purpose. Every day since July 16 1995, a new picture (or video) with some accompanying information has been posted and it has cemented itself as the OG source of space-related content.

The archive is a trove of absolutely stunning images with otherworldly color palettes. The sheer amount of them and their easy accessibility, combined with my personal desire for a new side-project led to the thought: why not make the APOD image database searchable by color? 🎨

The finished product 👨‍🚀

With more images from JWST continuing to be transmitted back to us, I've been wanting to build something to do just that. Feeling inspired, I set out to build apod-color-search!

Do give it a try and let me know what you think. I've been putting time into it on & off over the past couple months but finally feel ready to release it to the public.

Part of this was to maximize the various free tiers of cloud services that it utilizes - only given so many hours for GitHub Actions to run to process almost two decades of images! Happy to say that I didn't spend a single cent on any cloud infrastructure, though that came at the cost of some additional complexity which I'll go into detail about later.

Here's the source if you want to poke around in the meantime:

brycedorn / apod-color-search

Search for Astronomy Picture of the Day images by color 🎨

apod color search 🪐

Search for APOD photos by color! Consists of three parts:

web

A Svelte app to provide search interface. Uses vanilla-colorful for color picker.

api

Deno-based API that retrieves APOD information from database for images that match the given hex value. Uses Redis to store & retrieve query results.

src

Rust utility to analyze and process images. Used to populate database with historical data, now scheduled to run monthly to process new APODs.

Fetches APOD metatada via apod-api.
Analyzes image to get highest-frequency non-grayscale colors.
Saves result to Postgres.

Runs via GitHub Actions UI to then trigger additional workflows. This was used to leverage GitHub Actions to batch process a large amount of images concurrently & remotely.

View on GitHub

This will be the beginning of a series of posts about how I built it consisting of multiple parts, including:

Building a request handler and image processor in Rust
Using GitHub Actions as a free cloud utility to batch process images
Building an API to retrieve and cache search results
Building a web application to display color-indexed images in a searchable interface

Stay tuned! 🔭

When not to use Deno Deploy ☄️

Bryce Dorn — Sun, 05 Feb 2023 11:47:30 +0000

I've been really enjoying Deno for personal projects! The developer experience is excellent and Deno Deploy makes it easy to quickly & easily get things deployed.

While its on-demand design is efficient and excellent for many use cases, there are some where it performs poorly due to its nature of creating a new instance for each request. Unfortunately, I ran into one of these when building a caching layer for a project I've been working on. In this article I'll go through these issues and explain the alternative route I went to avoid them.

The problem: Redis overload 👯👯👯

Database reads are expensive and slow. There's a multitude of other reasons why caching is essential, but for the project I'm working on I'm using supabase and their free tier supports only a limited amount of bandwidth. To avoid any rate-limiting I added a Redis layer in front of it to reduce the number of queries that hit the database directly.

Conveniently, Deno has a deno-redis (experimental) plugin which I used to add a simple caching layer to my project:



import { connect } from "https://deno.land/x/redis/mod.ts";

const redis = await connect({ hostname, port });

let cachedResult = await redis.get(query);
let result = cachedResult;

if (!cachedResult) {
  result = db.get(query);
  await redis.set(query, result);
}

return result;

With this in place, the full request lifecycle looks like this:

And this works just fine! But, after enough requests start pouring in Redis will complain that there are too many connections and not allow new ones (redis.connect results in: ERR max number of clients reached). Granted, I am also using their free tier which restricts to 30 clients at a time. But this problem will also arise in high-volume applications as hosted integrations generally have a hard cap on the number of connections.

Why does this happen? It's due to a fundamental aspect of Deno Deploy: each time a request is made a completely new context is created and in this scenario, a new connection to Redis must be made. To visualize this, here is what happens when n users each make a request:

To get around this we'll need a way to cut down on the number of connections and keep it under the limit, but as we'll see there's also a performance benefit to doing this.

A single, persistent connection 🛰️

Though any traditional server environment will enable this, I used Node as it's close to Deno and simple to use. With a few lines of code, an express server that creates a single client on start will enable any incoming request to reuse the same connection. Adding some simple routing to detect request params and respond with what Redis returns then lets allows the cache requests in Deno to be swapped with GET requests to this server.

This is known as a reverse proxy and is common in any web stack. With this in place, the request lifecycle now looks like this:

With this in place, not only are there no errors due to the number of connections but performance is significantly improved with duration cut by over 50%:

benchmark	time (avg)	(min … max)	p75	p99
Deno -> Redis	65.06 ms/iter	(792 ns … 114.68 ms)	111.41 ms	114.68 ms
Deno -> Node -> Redis	34.79 ms/iter	(28.4 ms … 41.7 ms)	36.53 ms	41.7 m

But there's a twist! 🦹‍♂️

My main objective was to identify a solution for the Redis errors, but I figured why not also test whether a persistent Postgres connection behaves similarly. And to my surprise, the results were the opposite!

Perplexingly, when benchmarking the same as above (Deno vs Deno + Node layer for Postgres) there was a surprising result: Deno outperformed Node by a factor of ~2x! So despite recreating a supabase client for each request, Deno still outperforms Node:

benchmark	time (avg)	(min … max)	p75	p99
Deno -> Postgres	42.98 ms/iter	(916 ns … 89.29 ms)	79.8 ms	89.29 ms
Deno -> Node -> Postgres	88.24 ms/iter	(667 ns … 205.44 ms)	160.8 ms	205.44 ms

Whether this is due to limitations in the implementation of @supabase/supabase-js that aren't present in Deno's or just that Deno performs better I am not completely sure. And as far as I'm aware there isn't a limitation on the number of clients connecting to a single supabase instance. But based on these numbers I'll keep Node for querying Redis and Deno for querying Postgres.

Thanks for reading!

Here's the source used to run each of these benchmarks if you'd like to try them yourself:

brycedorn / deno-node-redis-postgres-benchmarks

Benchmarking Redis and Postgres performance for Deno vs a combination of Deno and Node.

Deno vs Node Redis/Postgres benchmarking

As part of a dev.to article.

Results

Results from running on Apple M1 Max 64GB Ventura 13.1 from Amsterdam with both hosted services in eu-west-1:

Uses node?	Benchmark	Time (avg)	(min … max)	p75	p99
no	Deno -> Redis	65.06 ms/iter	(792 ns … 114.68 ms)	111.41 ms	114.68 ms
no	Deno -> Postgres	42.98 ms/iter	(916 ns … 89.29 ms)	79.8 ms	89.29 ms
yes	Deno -> Node -> Redis	34.79 ms/iter	(28.4 ms … 41.7 ms)	36.53 ms	41.7 ms
yes	Deno -> Node -> Postgres	88.24 ms/iter	(667 ns … 205.44 ms)	160.8 ms	205.44 ms

Running locally

Prerequisites

Deno >= v1.30.2.
V8 >= v10.9.194.5.
TS >= v4.9.4.
Node >= v16.15.0.
Redis instance, I'm using Redis Enterprise Cloud (has free tier).
Postgres instance, I'm using supabase (has free tier)
- This example uses hex as the lookup key but this is…

View on GitHub

I made an app to index my liked TikTok recipes 👨‍🍳

Bryce Dorn — Tue, 16 Aug 2022 15:50:00 +0000

While TikTok started as an app for dancing and music, anyone who's used the app knows that it's grown into something much bigger. I've learned so many things from random accounts: history lessons, travel advice, "life hacks that have become unconscious standard practices", you name it!

Cooking is a big topic for me. I come across lots of delicious looking recipes and "like" them to revisit later. But TikTok's interface for searching through liked videos is half-baked and lacks basic features for searching through a large list of videos.

So even though I want to try all of these recipes, I get stuck trying to find them (and then end up liking more videos to continue to bury them in my pile of likes).

But I figured, TikTok has a public API, how hard would it be to build a project to solve this?

The answer: not that hard 😄 though with some hacks. Here's what I ended up building: tiktok-recipes.deno.dev. Will walk through how I did it below!

TikTok's `oembed` API 📟

TikTok provides a public oembed API that will retrieve metadata for a video. It's as simple as a GET to https://www.tiktok.com/oembed?url=${url}, where url is the full path to the video on TikTok.

With a simple script around this, a list of videos can be iterated upon to fetch and save metadata to a static file. All that's needed is the list of recipes...

Compiling list of videos 📺

This step was boring 🥱 there's no getting around needing to sift through all of the videos I've liked to save the URLs for the ones that are recipes. Ended up scrolling for a while and opening a bunch of tabs then doing a trick to bookmark/export those tabs.

Displaying the list 📃

I used fresh as it's been my framework of choice lately. It includes preact, typescript & twind by default. The interface is a simple two-pane component that renders a scrollable list of video titles on the left and a <video> element on the right. But while it'd be possible to just embed the TikTok entirely in an iFrame, I'd much rather only load the content I want.

Ideally I could just link the src of the video from metadata, but that would be too easy. The source URL isn't included in this blob so unfortunately it requires a hackier approach to obtain. But I came up with a solution for this that requires minimal code (<20 lines total)!

Retrieving video source 🚧

I covered this in an earlier post, you can read more about it here:

Building a simple TikTok scraping API 🤖

Bryce Dorn ・ Aug 14 '22

#webdev #showdev #api #javascript

tl;dr: scrape the page for the media URL inside the server-generated client-side blob. Unfortunately there doesn't appear to be a simpler way to do this at the moment (let me know otherwise).

This is easily to implement with a fresh handler though! And since this happens on the server it gets around CSP restrictions that prevent loading content from another website. Here's the full source for the handler.

Putting it all together 🪛

Now that all the pieces are in place, all that's left is to connect the request flow and ensure client state works correctly! With some simple logic to handle basic actions and loading states (showing video thumbnail initially & adding a play indicator to load video), it's looking pretty usable. Definitely nothing to write home about but gets the job done.

The list ordering is randomized on each pageload for a different experience each time I visit. And, importantly, I added a simple text search as well to filter results - a basic feature TikTok's liked videos page still doesn't support.

If you didn't catch the link earlier here it is in action: tiktok-recipes.deno.dev. Feel free to poke through the recipes I find interesting or read through the source (below) to see the full project (or fork it & create your own page for any category of TikToks you'd like easier access to). Thanks for reading!

brycedorn / tiktok-recipes

Indexing recipes I've liked on TikTok for easier access.

tiktok recipes

Indexing recipes I've liked on TikTok for easier access.

Usage

deno task start

This will watch the project directory and restart as necessary.

Fetching data

deno task fetch:tiktoks

This will fetch metadata for videos in data/tiktoks.txt:

View on GitHub

Building a simple TikTok scraping API 🤖

Bryce Dorn — Sun, 14 Aug 2022 18:26:40 +0000

Note: this no longer works as TikTok now blocks cross-origin media requests.

As part of a project centered around TikTok (coming soon!) I needed a way to get a video's media. The closest thing that TikTok officially provides is their oembed API, but unfortunately this only includes basic information like title, thumbnail_url etc. And other unofficial APIs cost money or require python, which I don't want to do. So I needed another way to retrieve this info.

Leveraging SSR patterns 📦

As a website that handles large volumes of traffic I knew they had some sort of SSR/client-side hydration going on. This generally involves is shipping data to the client in an object inlined inside a <script> tag, reducing the number of necessary client-side requests by directly populating components with this data. In Next.js for example, this happens via server-side props.

And lo and behold! There's a handy blob provided alongside the page markup for every video. You can confirm this for yourself by visiting any TikTok video's page (https://www.tiktok.com/:user/video/:id) and looking at the contents of the SIGI_STATE tag via console:

JSON.parse(document.getElementById("SIGI_STATE").innerText);

Knowing this I built a simple handler using deno to fetch this blob and return it directly.

Enter cheerio & deno 🥣🦕

If the video URL is attached to the request (via POST body or params), a simple handler can fetch (scrape) the content for the page:

const response = await fetch(`https://tiktok.com/${video}`);
const html = await response.text();

Then, using cheerio, this raw text can be turned into a queryable jQuery-like API. This provides an entrypoint to get the content of the server-generated blob within the script tag:

const $ = cheerio.load(html);
const appContext = $("#SIGI_STATE").text();

From there, it's only a matter of parsing this as JSON and returning pertinent data in the response (ItemModule). The data is currently keyed by some unique identifier, Object.keys helps remove that:

const json = JSON.parse(appContext);
const key = Object.keys(json.ItemModule)[0];
const data = json.ItemModule[key];

return new Response(JSON.stringify({ ...data }), {
  headers: { 'Content-Type': 'application/json' },
  status: 200,
});

And that's it! Now I can make a client-side request to get up-to-date media for a video and display it directly. This also gets around TikTok's CDN expiration which would prevent saving a reference to this media.

Side-note: comparing this to the output for one of the unofficial API options I came across, the data looks identical. So it's likely they're doing the same thing (but charging almost $200/mo for unlimited usage)!

Anyways, this is fragile and could break if they decide to rename the script tag, rate-limit, etc. But this demonstrates how easy it is to spin up an instance for your own project. And maybe with enough bot traffic TikTok will create a public API that accomplishes this instead of making us scrape for it! 😇

Detecting dark mode on every request 🌓

Bryce Dorn — Mon, 08 Aug 2022 13:05:00 +0000

I'm a huge proponent of dark color schemes! Aside from causing less eye strain due to emitting less blue light, dark pixels drain less battery life (for devices with OLED screens) and make nighttime usage much more pleasant. I immediately look for the option when opening a new app and love when it's implemented well.

Recently I came across an experimental approach to help simplify dark mode adoption on the web and wanted to share with others as it resolves a related frontend issue.

That annoying flicker 💡

If you've ever implemented dark-mode in a frontend application, chances are you've encountered the "flickering" issue when loading the page. This is because the client doesn't know whether to render the light or dark version of the UI initially, causing it to flicker from light to dark if the user prefers that color scheme.

With SSR it's possible to get around this by storing the user's theme preference in document.cookie; enabling the server to check this preference on a request before responding with HTML. But even with this approach, the cookie can only be set after the user first loads a page (detecting via prefers-color-scheme and setting this cookie), still causing the page to flicker if they prefer things to be dark.

This can also become tedious if your application spans multiple subdomains, as the cookie may need to be set for each one.

Detecting on every request 🪄

Luckily there's a solution here! (For Chrome at least, more on that later.)

As of Chromium 93, the Sec-CH-Prefers-Color-Scheme client hint header enables attaching this preference to HTTP requests. By specifying that your server allows this header:

response.headers["Accept-CH"] = "Sec-CH-Prefers-Color-Scheme";
response.headers["Vary"] = "Sec-CH-Prefers-Color-Scheme";
response.headers["Critical-CH"] = "Sec-CH-Prefers-Color-Scheme";

You can then get the user's preference from the request:

const theme = request.headers["Sec-CH-Prefers-Color-Scheme"];
// "dark" | "light"

And send the appropriate markup to the client! Possibly via a class on the body tag:

return (
  <body class={theme}>
    ...
  </body>
);

Or an inlined CSS variable:

return (
  <body style={{ `--color-scheme: ${theme}` }}>
    ...
  </body>
);

Or it can integrate with the style library you're using assuming it generates styles server-side.

This is great though! No need to track color-scheme preference on the client or in your database; it can be set once on the user's device and included without any interference.

Some limitations 💭

Unfortunately this is currently only supported on recent (93+) versions of Chromium-based browsers. As we know Chrome dominates browser share, so this translates to roughly 70% of the web.

WebKit and Mozilla have requests pending to implement. Until support reaches 100% it can't (and shouldn't) be used in production, but I'm hopeful that since this delivers real value to the user experience it will get traction soon.

More information about other client hints can be found here, as well as links to examples. If this interests you spread the word and hopefully we can see this implemented across all browsers soon!

Forem: Bryce Dorn

Mini site for recommending songs using Svelte & Deno

brycedorn / listn.fyi

Recommend a song to your friends via a playlist! Try it out: https://listn.fyi/combatfetus

Building APOD color search part III: Deno Search API 🔎

Simple search API 🔎

Why Deno? 🦕

Finding color matches 🎨

Caching results 🗂️

Generate placeholder images at edge with thumbhash

Using Workers KV to build an edge cached blog 🌍

Bryce Dorn ・ Jun 3 '22

Pageload bottleneck 🌁

Enter: thumbhash 👍

evanw / thumbhash

A very compact representation of an image placeholder

Generating thumbhash as part of edge caching process 🎞️

Loading the full-sized image 😴

Building APOD color search part II: Computing in cloud ☁️

Everything via GitHub Actions 🛰️

Rust in action(s) ⚡️

Dispatching via workflow UI 🛎️

Blobby image animation in CSS 🦠

Server-render your SPA in CI at deploy time 📸

Perform a React disappearing act with react-snap ✨🧙💨

Bryce Dorn ・ Jan 23 '20 ・ 3 min read

brycedorn / react-snap-action

Github Action for pre-rendering via react-snap.

Building APOD color search part I: Image analysis in Rust

Building an app to search the APOD archive by color 🪐

Bryce Dorn ・ Feb 18 '23

Gathering the data 🚜

Processing data for an APOD 🌌

Getting a day's APOD information

Processing the colors 🔬

Generate frequency array

One month at a time 🗓️

Building an app to search the APOD archive by color 🪐

The finished product 👨‍🚀

brycedorn / apod-color-search

Search for Astronomy Picture of the Day images by color 🎨

apod color search 🪐

web

api

src

When not to use Deno Deploy ☄️

The problem: Redis overload 👯👯👯

A single, persistent connection 🛰️

But there's a twist! 🦹‍♂️

brycedorn / deno-node-redis-postgres-benchmarks

Benchmarking Redis and Postgres performance for Deno vs a combination of Deno and Node.

Deno vs Node Redis/Postgres benchmarking

Results

Running locally

Prerequisites

I made an app to index my liked TikTok recipes 👨‍🍳

TikTok's oembed API 📟

Compiling list of videos 📺

Displaying the list 📃

Retrieving video source 🚧

Building a simple TikTok scraping API 🤖

Bryce Dorn ・ Aug 14 '22

Putting it all together 🪛

brycedorn / tiktok-recipes

Indexing recipes I've liked on TikTok for easier access.

tiktok recipes

Usage

Fetching data

Building a simple TikTok scraping API 🤖

Leveraging SSR patterns 📦

Enter cheerio & deno 🥣🦕

Detecting dark mode on every request 🌓

That annoying flicker 💡

Detecting on every request 🪄

Some limitations 💭

TikTok's `oembed` API 📟