really x loco

Record Nerd, Part 2

Friday, September 18, 2020 · 11:37PM

Hey, a follow-up blog entry. Maybe you read the last one where I talked about a thing that I made. Since then, some things have changed about it.
First, on the backend, I added a delete service. My "local" Discogs collection is built using a pull system. A little restrictive, yes, but it's just my own thing. The main issue I didn't want to deal with was handling data when I updated my collection on the Discogs side. So, not worrying about this thing still being in my collection or that thing not being in my collection. I was initially just killing the table (DynamoDB does not have a TRUNCATE), but the way my infrastructure was set up, that required taking everything down. Since it's just me, not a big deal, but it was annoying. To alleviate that, I just added a lambda that will delete the contents of the table. Compared to tearing everything down, it's much faster.
Second, the frontend is now a Gatsby site. I thought this would be a bit of a challenge. Well, it was, but not as bad as I anticipated. I think mostly, it was nice that I already had everything built out, I just needed to "convert" some things and move stuff around.
The one thing I initially had trouble wrapping my head around was building the pages. This site is API driven, so how could that become static? The way Gatsby works is that basically SSRs (server-side renders) your React pages into a "static" HTML page. For the original version, I had a useEffect that would do the API call to pull in the data and populate the page. I could have just copied my components over as-is (mostly), and Gatsby would build it just fine, but it wouldn't be that nice, snappy, static page.
So, to make this work, using Gatsby's build system, I'm just fetching the first "page" of data that you see on the page at build time. Gatsby will build the page with that data, and it will still use the JavaScript (React) for the "dynamic" parts of the page (loading more things, etc). There are some pages that are not static—like viewing releases by year or records for an artist, mostly because I'm not building each possible page. So instead of building pages for /collection/releases/year/2001, /collection/releases/year/2002, etc., I just have a page that handles the /collection/:type/year/:year route and handles everything in the browser.
Another neat feature of Gatsby is its image handling. Loading a bunch of images on a page is typically not great. There a probably a lot of different "lazy loading" libraries out there, and Gatsby has their own image component that takes care of that. The catch is that the images have to be on the filesystem. All the images I'm using are hosted on Discogs. Remember how I said I'm fetching the first set of data needed to build the page? At the same time, I'm making use of another Gatsby plugin to download the associated images. With that, I can use the fancy image component, so it has that neat image blur thing when the page loads. When my pages fetch more data, it will refer to the images hosted on Discogs.
So overall, what did this get me? Not much apparently. I asked a couple people to do a side-by-side comparison, and the differences were not noted. :sad emoji: Even the Lighthouse scores aren't drastically different, but the Gatsby version is an improvement at least. Anyway, it was decently fun to work on, and I feel accomplished in a way.