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.