DEV Community: James O'Halloran

Validating your site's links in a world of SSR and server components

James O'Halloran — Sun, 13 Nov 2022 12:14:40 +0000

Over the last 5 years, I have loved working in the "Jamstack" movement, where static site generators (like Hugo, Jekyll, Gatsby, etc) pre-generated your HTML for you, and your pages were served from a CDN. Validating links before pull-requests were merged was easy, because all your checks could run against this pre-generated HTML

Lately though, with popular frameworks like NextJS, Remix, and the whole shift to Server Components, more of the modern web if shifting back to server-side rendering. It's becoming harder to do these checks BEFORE pull-requests are merged.

This is why I built LinkProofer, an extremely lightweight CLI tool for validating links stored in js or ts files.

Instead of proofing the links in the built-html, it proofs them before they are consumed.

✨ Features

Out-of-the-box Typescript support.
Customizable entry (Provide your own filepath glob, or store links in *.linkproof.<js | ts> files).
Support for absolute or relative links.
Run LinkProofer checks locally, or in CI.
Lightweight! (~50 kB).

You can learn more about the project by checking out the GitHub repository

Do "Future you" a favour and setup your "indie project boilerplate"

James O'Halloran — Fri, 26 Aug 2022 20:19:54 +0000

As a developer, how many times have you been asked:

"How long would it take to make ?".

I can't count the amount of times I relearned the lesson that these types of projects always take longer than expected to fully launch.

This recently happened to me when a friend brought up the idea of a "Fantasy Football Draft Order Generator", any my response was naively:

"A few hours or so".

(You can checkout the final product here. While it's very simple, I can promise it was more than a few hours.)

I usually get started creating these projects using a tool like create-next-app.

I'll add Typescript, Tailwind, a component library, wire up my site's layout, fiddle with flex-box in the footer, Figure out how external scripts should be loaded in Next JS , etc etc etc.

Many of these individual tasks are fairly trivial on their own, but it's often a death by 1000 cuts, where your "1 hour project" quickly turns into a whole ordeal. Before you know it, this trivial project starts eating into your evenings/weekends (or maybe you never get around to properly launching the project).

Do "future you" a favour...and create your own "Indie Boilerplate".

I've created mine here:
https://github.com/jamespohalloran/indie-boilerplate

On my next hobby project I'll be able to get started with:

npx create-next-app@latest -e https://github.com/jamespohalloran/indie-boilerplate

I won't need to worry about dealing with:

the site's layout (Let's face it, these usually aren't that unique)
Configuring SEO meta fields
Setting up Tailwind & my preferred component library (DaisyUI in my case)
Adding my personal links to the footer
Adding copyright info

I also even have my own "Indie Project Checklist" in the readme to keep me on track.

I hope this helps out "future you" on your next hobby project!

To follow along with more of my hobby projects, follow me on twitter & checkout my portfolio site

Let's make static sites dynamic again! ...sorta (with NextJS "preview-mode")

James O'Halloran — Tue, 10 Mar 2020 13:15:01 +0000

I've been working with static sites for several years now. Before that, Wordpress was my go-to... and I hope to never again dig through their source-code 🙃. The switch to developing with static site generators has made my sites:

Faster
Cheaper (free) to run
More secure
MUCH easier to manage

For these reasons... when I first heard about Next.js, I was a bit confused about their focus on "Server Rendering". I wasn't sure why I should care about server rendering for my use-case as most of my sites were pretty small. I was fully accustomed to my SSG's of choice building everything up front, and then deploying the static assets. The datasource was consumed at build-time, and I could just run the site locally in dev-mode as I made changes to my content.

Wait, I thought the title of this blog was "Let's make static sites dynamic again!"...

Well, I didn't realize it, but there were some definite drawbacks of having all my pages static.

When a site is built statically:

Content is consumed at build-time. If I want to see a new "preview" of an edit, I need to rebuild the site.
For each of these previews, the entire site needs to be completely rebuilt which can be sloooow. Note: Gatsby is currently working on a "Incremental Builds" to get around this, but it's not ready yet.
If I'm running a 'preview' server to rebuild when my datasource is updated, I need one server running per datasource. Why does this matter? What if me and a team of editors are making changes to 3 different branches of my site at once? I would need 3 servers running 3 different versions of my site.

Those might seem like minor qualms, but I think it's a huge part of the reason that static site CMS's haven't caught up to the editing/collaboration experience of services like Squarespace. Seeing a live preview of a site is a crucial step before publishing changes, and the above drawbacks make it challenging.

Next's "Preview Mode" to the rescue

With this latest NextJS release, Each page template can be designed to export statically, but can provide alternate behaviour for when they are run using SSR.

This has allowed us at TinaCMS to provide an "open authoring" solution where our site is static, but can be run in dynamic "edit" mode with custom content per-user.

So... back to our drawbacks of static-building mentioned above...

"Content is consumed at build-time. If I want to see a new "preview" of an edit, I need to rebuild the site."

With SSR, the data is consumed dynamically per-request. In the case of TinaCMS's open authoring, it lets each editor load dynamic data per-request from their own fork.

"For each of these previews, the entire site needs to be completely rebuilt which can be sloooow."

Nope! No rebuild is needed for preview mode. SSR renders each page on-the-fly as we need it.

"If I'm running a 'preview' server to rebuild when my datasource is updated, I need one server running per datasource."

Nope! Just one. With SSR, the data is dynamic, so each user's request can query a different dataset. Also, In the case of deploying with Zeit, they automatically set up serverless Lambda functions for each of my templates, so I don't have to deal with managing any servers 🎉!

Neat!

And of course, my live production site is still fully static. When I enter enter-mode, it switches to use SSR. It's the best of both worlds!

This (in my opinion) is going to be a gamechanger. Good work, Zeit team!

So... Let's make static sites dynamic again! (conditionally... in preview-mode 🙂)