DEV Community: Nathan

OG Images Without an Image CDN

Nathan — Fri, 10 Jul 2026 11:54:19 +0000

Link previews are the first thing anyone sees of a blog post. They're also the last thing most people think about. The usual answers are a Figma file you forget to update, or @vercel/og, or an image-CDN pipeline you stand up once and never touch again.

I do something dumber and more fun: my OG images are just screenshots of my own React routes.

Every page that needs an OG has a sibling route that renders the actual preview. The screenshot is taken at build time with Puppeteer. The result looks like my site because it is my site: same fonts, same dither shader, same Grid, same theme-aware icons.

The trick: render the OG, don't design it

I have three OG routes, each a normal TanStack Router file route returning a normal React component:

/og — the site-wide preview, used as default og:image.
/blog/og — the blog listing preview ("Nathan's Blog").
/blog/$slug/og — the per-post preview, with the post title, its date, and a small dither shader header.

You can even see it by yourself: e.g brodin.dev/og.

The component in each route is the same shape: a constrained div with id="og", sized exactly 1200 × 630, reusing my real UI primitives.

<div
  id="og"
  className="relative mt-2 flex h-full flex-col items-center justify-between overflow-hidden border p-14"
  style={{ width: 1200, height: 630 }}
>
  {/* ...PageTitle, PageDescription, tech-stack icons... */}
  <div className="pointer-events-none absolute inset-0 -z-1 h-full w-full overflow-hidden opacity-10">
    <Dithering
      width={1200}
      height={630}
      colorBack={resolvedTheme === 'dark' ? '#000000' : '#FFFFFF'}
      colorFront={resolvedTheme === 'dark' ? '#cbfbf1' : '#00786f'}
      shape="warp"
      type="4x4"
      size={1.0}
      speed={0}
      scale={1.84}
    />
  </div>
  <Grid />
</div>

That Paper Shaders dither is the same one I use on my section dividers. The PageTitleis the same component that renders the H1 on every real page. The Grid is the sameGrid from my home page. There is no separate design system for OG. The OG is the design system, just constrained to a poster.

Because the per-post route is a real route with a real loader, it pulls the post title and date from Content Collections just like the actual blog post page does. No drift. Update the post, the OG regenerates on the next build.

The screenshot script

scripts/generate-og.ts does the work:

async function captureOg(page: Page, url: string, outputPath: string) {
  await page.goto(url, { waitUntil: 'domcontentloaded' })
  await page.waitForSelector('#og', { timeout: 30_000 })
  const og = await page.$('#og')
  if (!og) {
    throw new Error(`OG element (#og) not found at ${url}`)
  }

  fs.mkdirSync(path.dirname(outputPath), { recursive: true })
  await og.screenshot({ path: outputPath, type: 'png' })

  const stats = fs.statSync(outputPath)
  const fileSizeMB = (stats.size / (1024 * 1024)).toFixed(2)
  if (stats.size > MAX_FILE_SIZE) {
    throw new Error(`OG file size (${fileSizeMB}MB) exceeds 8MB limit: ${outputPath}`)
  }

  console.log(`  ${outputPath} (${fileSizeMB}MB)`)
}

Two details matter here. First, waitUntil: 'domcontentloaded' instead of 'networkidle'. networkidle waits for quiet, which fonts and async chunks can delay by seconds. I don't need quiet. I need the #og element to be painted, so I waitForSelector('#og', { timeout: 30000 }). It's faster and more reliable than waiting for the network to settle.

Second, I screenshot the #og element, not the viewport. The Puppeteer page is set to 1920 × 1080, but the captured image is the element at exactly 1200 × 630. That means the OG box can live anywhere in the layout and I still get a clean crop. No pixel-counting in the script.

One image per blog post, automatically

The script crawls content/blog/*.md and screenshots each post's OG route, writing public/og/blog/<slug>.png:

function getBlogSlugs(): string[] {
  return fs
    .readdirSync(CONTENT_BLOG_DIR, { recursive: true })
    .filter((file) => String(file).endsWith('.md'))
    .map((file) => String(file).replace(/\.md$/, ''))
}

New post in content/blog/, run pnpm generate:og, get one new image. No manual step, no Figma export.

The blog post route then wires that image into its head():

const ogImage = `${siteConfig.url}/og/blog/${post.slug}.png`
// ...
{ property: 'og:image', content: ogImage },
{ name: 'twitter:image', content: ogImage },

So updating a post title or date updates the OG on the next build. The link preview always matches the post.

The 8 MB guardrail

After every capture, the script stats the output file and throws if it exceeds 8 MB. A single bloated OG would silently tank sharing-time LCP the moment a link gets pasted somewhere busy. I'd rather have the build fail. It's six lines of code and the cheapest insurance I ship.

Theme-aware icons, for free

The site-wide OG includes my tech-stack icons. Each one has light and dark variants, swapped with Tailwind's dark: variants:

<img
  src={`/tech-stack-icons/${tech.key}-light.svg`}
  alt={`${tech.title} light icon`}
  className="block dark:hidden"
/>
<img
  src={`/tech-stack-icons/${tech.key}-dark.svg`}
  alt={`${tech.title} dark icon`}
  className="hidden dark:block"
/>

The dither shader does the same thing at the color level: colorBack and colorFront switch on resolvedTheme. So a dark-mode screenshot and a light-mode screenshot look like genuinely different posters, not the same image with inverted colors. I run the script under whichever theme I want; usually dark, since that's my brand default.

The honest downsides

Build-time, not on-demand. New content needs a redeploy and a script run. If I wanted to ship a post and have its OG live in under a minute, I would reach for @vercel/og.
Puppeteer is heavy. It pulls Chromium into your CI. It adds seconds-per-image to the build. For a portfolio with a handful of routes it's a non-issue, but if I had thousands of pages I'd reconsider.
Single captures. One theme per run. If I wanted dark and light OGs I'd have to render the route twice. Right now I don't.

@vercel/og is the right answer once you have a real scale problem. The reason I don't use it here isn't that it's bad: it's that I don't have that problem, and og.screenshot() lets my OG reuse the components I've already built.

The OG route components, side by side, are in /src/routes/og/, /src/routes/blog/og/, and /src/routes/blog/$slug/og/. Worth reading in order: the per-post one is where most of the logic lives.

My Portfolio: brodin.dev
Source code: github.com/NathanBrodin/Portfolio
@vercel/og (when you do have the scale problem): vercel.com/docs/functions/og-image-generation
Paper Shaders (for the dither ones): shaders.paper.design

Every Optimization Behind a Perfect Lighthouse Score

Nathan — Fri, 03 Jul 2026 13:28:43 +0000

I run Lighthouse on brodin.dev the way some people refresh their GitHub contribution graph. It currently lands at 100 on every local run, and 100 in Vercel's Real Experience Score. These performances don't come from a "performance checklist", but rather from moving work from the browser to the build, in places where every generic guide tells you to just "lazy-load it."

So here's the actual list: no next/image worship, no advice I didn't personally ship.

1. Static prerendering

The single biggest win. In vite.config.ts:

tanstackStart({
  prerender: {
    enabled: true,
    crawlLinks: true,
  },
})

enabled: true turns the whole site into static HTML at build time. crawlLinks: true means TanStack Start follows every internal link it finds and prerenders those routes too, so I never have a route that ships zero hydration cost "by accident" because I forgot to list it somewhere.

The small tradeoff some could argue about would be slower build times. But dor a content site that deploys a few times a month, that's a non-issue. For an app that ships 30 times a day, I'd think harder. But the payoff is that there's almost no JavaScript execution between "user hits Enter" and "user sees a painted page": the HTML is already there.

Next.js does offer the same feature, so modern React static apps can all benefit from it.

2. The 1000ms nobody talks about: my dotted world map

This is the one I'm proudest of, because it's a fix for a specific third-party library doing a specific expensive thing.

My home page has a dotted world map with markers for the places I've lived. The naive version uses the svg-dotted-map library's createMap() at runtime. That function parses GeoJSON and runs point-in-polygon sampling for ~5000 dots. On my machine, that blocks the main thread for around 1000ms. On a throttled mid-tier Android, multiply that. Lighthouse's "Reduce JavaScript execution time" audit doesn't even know what hit it: it's a synthetic main-thread cliff.

You can't lazy-load your way out of this. The data is intrinsic to the visual. So I moved the entire computation to build time in scripts/generate-map-data.ts. It runs createMap() once in Node and writes three things to a generated file:

One SVG path string for all 5000 dots, collapsed into a single <path d="...">. One paint operation instead of 5000 <circle> elements. The browser renders this basically for free.
A linear longitude projection (x = LNG_ORIGIN_X + lng * LNG_SCALE_X). Trivial, extracted from two sample points.
A latitude interpolation lookup table. This is the non-obvious one: the map uses a Mercator-like projection, so latitude → Y is non-linear. I sample every degree from -70 to 85 at build time, store the [lat, y] pairs, and at runtime do a binary search + linear interpolation between the two nearest entries.

The runtime file the browser loads is just a big string and two lookup tables. The browser does zero parsing, zero sampling, zero point-in-polygon. The ~1000ms became "an SVG path, rendered."

That's the kind of optimization that doesn't show up in a checklist. You only find it by profiling and asking, "why is my main thread busy before I've even rendered anything?"

3. Font preloading

Three rel="preload" declarations in the root route's head:

{
  rel: 'preload',
  href: '/fonts/iAWriterQuattroV.woff2',
  as: 'font',
  type: 'font/woff2',
  crossOrigin: 'anonymous',
},
// ...and the same for Lora and iA Writer Mono

The gotcha that bit me once: if you self-host and forget crossOrigin: 'anonymous', the browser silently double-fetches the font. It's the kind of thing that doesn't break anything visibly but quietly wrecks your preload and shows up as a longer LCP. Three fonts is enough fonts so I'm not preloading everything, just the three that render above-the-fold text.

4. One paint, not five thousand (and SMIL for the pulses)

This is the SVG sibling of the map story. Splitting the dots into one <path> instead of thousands of <circle> nodes collapses the DOM size and gives one paint op. For the animated marker pulses on the map, I use declarative SMIL <animate> instead of a JS rAF loop:

<animate attributeName="r" from={String(markerSize)} to="2" dur="2s" repeatCount="indefinite" />
<animate attributeName="opacity" from="0.5" to="0" dur="2s" repeatCount="indefinite" />

SMIL gets a bad rap sometimes, but for an always-on pulse it's cheaper than driving it from React state and triggering re-renders. The honest caveat: it's not prefetchable the way a JS animation sometimes is, and on very low-end devices SMIL can be inconsistently throttled. For a portfolio it's fine.

5. Animations that respect the GPU

I use motion (framer-motion's successor) for the curved path draw-ins on the map, but I keep it boring: animate={{ pathLength: 1 }} once on mount, with a small stagger. No scroll-gated choreography, no parallax, nothing that requires listening to the scroll position. The dither shaders on the section dividers run on the GPU through @paper-design/shaders-react. And on the OG image route specifically, I set the dither's speed={0}, that one's actually about screenshot correctness (I capture it with Puppeteer), but it does mean the share-preview version of the shader is free.

The rule I follow: animate things the user can see, animate them once, and let the browser handle it on the compositor thread.

6. Vector where vector works

favicon.svg. Tech-stack icons as .svg with light/dark variants. The map dots are a single SVG path. The one raster I keep on the home page is the GitHub contribution screenshot, and that's .webp. Rasters are reserved for things that are genuinely photographic (a screenshot of an actual UI). If it's a logo or a shape, it's a vector. Less weight, infinitely scalable, no CLS from missing dimensions.

7. Build-time guardrails

Nothing runtime-clever here, just two cheap safety nets:

My OG image generation script (scripts/generate-og.ts) screenshots the OG routes with Puppeteer and throws if any captured image exceeds 8 MB. A single bloated OG would silently tank sharing-time LCP once a link gets pasted somewhere busy. I'd rather have the build fail.
vp check runs format, lint, and a real TypeScript typecheck on staged files. It won't catch every perf regression, but it catches the dumb ones: a fat dependency, a console-laden module, a mis-typed hot path, before they land in prod.

The honest "what I did not do"

This is the part most perf posts skip, and it's the most useful.

No image CDN / next/image-equivalent. I have one image that benefits from responsive sizing. One. A full image pipeline isn't worth the dependency.
No advanced code-splitting beyond route-level. The site is small. Route-level chunks from TanStack Start are enough. Anything more is over-engineering.
There's still ~130 KiB of "unused JavaScript" on initial load. That's framework runtime: React, TanStack, the small motion slice. It's the cost of SSR-with-hydration. On desktop it doesn't cost the score. On throttled mid-tier mobile, it's the ceiling I can't break without dropping the framework, and I'm not willing to do that for a portfolio.
A perfect Lighthouse score on a small site is a vanity metric. I'm not going to pretend it matters as much as it would for a media site with a million visitors. The point isn't the 100. The point is the lesson underneath it: measure, then move work to build time.

If you want to see how all of this hangs together, the source is open. Steal the map precompute especially: that one deserves to be more than a footnote in my repo.

My Portfolio: brodin.dev
Source code: github.com/NathanBrodin/Portfolio
TanStack Start prerendering: tanstack.com/start
Paper Shaders (the dither ones): shaders.paper.design

react-i18next Was Fine. Then I Found Paraglide.

Nathan — Mon, 04 May 2026 11:41:16 +0000

I have a confession: I used react-i18next for years and genuinely never questioned it. It worked. It was everywhere. Every project I joined during my internships at DNB had it set up. You install it, you configure it, you wrap your app in a provider, and you ship. Done.

But then I started building more things on my own, projects where I got to choose the stack from scratch, and I started noticing friction I had previously just accepted. So let me tell you what I was silently tolerating with react-i18next, and why Paraglide JS fixed basically all of it.

The react-i18next Era

To be clear: react-i18next is a solid library. It's been around forever, it has a massive community, and it handles a lot of edge cases out of the box. I'm not here to drag it through the mud.

But here are the three things that made me raise an eyebrow every single time. Worth noting: my hands-on react-i18next experience was back in 2024, so some of this may have improved since, but these were real pain points at the time, and the defaults still matter.

Quick reality check before I complain: I once set up internationalization in a Flutter app at uni. After that experience, anything in the React ecosystem is a luxury. So take my "rants" with the appropriate grain of salt.

1. No type safety (or not by default, at least)

This one was the most egregious for me back then. When you use react-i18next, your translation key is just... a string.

const { t } = useTranslation()

return <p>{t('dashboard.welcome.title')}</p>

TypeScript has absolutely no idea if dashboard.welcome.title is a real key or something you mistyped at 2am. You only find out at runtime, when your users see an empty string or the raw key rendered on screen. I love type safety. Coming from a TypeScript-first mindset, that kind of feedback loop gives me actual anxiety.

You can set up type augmentation manually and make it work. And to be fair, i18next has been actively improving here, v25 shipped a proper enableSelector option that makes keys fully typed, with plans to make it the default in v26. So this is becoming less of a valid complaint over time. But in 2024, none of that was there, it required extra configuration, and the fact that it was opt-in told you everything you needed to know about where it sat on the priority list. Paraglide just gives you this for free, from day one, no setup required.

2. Your entire translation file ships to the client

This is the quiet performance problem that nobody talks about enough. By default, react-i18next loads your full JSON translation file on the client, regardless of which keys are actually used on the current page.

If your app has been around for a while, that JSON file is probably enormous. Every abandoned feature, every old marketing copy, every screen the current user will never visit, it all gets shipped. Every time.
It also opens the door to accidental data leaks, shipping unreleased feature copy or internal admin strings to the client simply because they share a JSON file.

3. You need a hook. For everything.

// Server component? Utility function? Class? Doesn't matter.
// You need useTranslation() or you're not translating anything.
const { t } = useTranslation()

The useTranslation hook is fine in a standard React component tree. But the moment you step outside that, a utility function, a constant, a non-component file and you're stuck. You either restructure your code to work around it, or you do something hacky. Neither is great.

Enter Paraglide JS

Paraglide JS is an i18n library by the folks at inlang. I first heard about it from TanStack's own internationalization docs, where it's the officially recommended solution. Given that I use TanStack for everything at this point, that was enough of an endorsement for me to try it.

I've now used it in both personal projects and at work, and here is what actually changed.

Direct imports, no hook required

This is the one that immediately felt right. Paraglide generates your translation messages as real importable functions:

import { m } from '@/paraglide/messages'

// In a component
;<p>{m.dashboard_welcome_title()}</p>

// In a utility function
export function formatGreeting(name: string) {
  return m.welcome_user({ name })
}

// In a constant
const PAGE_TITLE = m.page_title()

No hook. No provider wrapping. No useTranslation() call at the top of every file. You just import and call. It works everywhere: components, utilities, server code, wherever. That simplicity compounds surprisingly fast when you're translating dozens of strings across a whole app.

Type safety out of the box

Because Paraglide generates actual TypeScript functions from your message files, you get full type safety for free. Autocomplete works. Typos are caught at compile time. If a message has parameters, TypeScript tells you exactly what you need to pass:

// m.welcome_user expects { name: string } — TypeScript knows this
m.welcome_user({ name: 'Nathan' }) // ✅
m.welcome_user() // ❌ TypeScript error
m.wellcome_user({ name: 'Nathan' }) // ❌ TypeScript error, key doesn't exist

This is the baseline I want from any typed language. The fact that it just works without extra setup is a big deal.

Tree shaking

Here's the quiet win: Paraglide only ships the messages that are actually used. Because translations are imported as individual functions, your bundler can tree shake everything else away. If a page only uses five translation keys, only those five keys end up in the bundle. Not your entire dictionary. Not every string from every screen your users will never visit.

For smaller projects it's a nice-to-have. For larger apps, this is genuinely meaningful.

Ultralight, and SSR-friendly

The runtime is tiny. We're talking a few hundred bytes. Compare that to react-i18next's runtime overhead and the JSON payload you're loading on top of it, and the difference is noticeable. It also works well with SSR, which was a concern before I tried it, TanStack Start's server rendering plays nicely with Paraglide's design, no hydration weirdness.

The Honest Downsides

I said I wasn't here to drag react-i18next, but I should be equally honest about Paraglide's rough edges.

A lot of files in your repo

Setting up Paraglide means you're going to have a project.inlang/ directory at the root, and a generated src/paraglide/ directory with all the output. It's not one config file you forget about, it's a handful of files you'll see every time you open your project tree. Nothing breaks, but it's visually noisier than what you'd get with other i18n setups.

The docs are scattered

This is my biggest complaint. The documentation lives across inlang.com, the Paraglide-specific pages, and the TanStack docs. None of them are bad on their own, but if you're trying to piece together a specific setup — say, Paraglide + TanStack Router + SSR, you'll end up jumping between multiple sites and cross-referencing. It works out eventually, but it's not the smooth onboarding you'd hope for.

So, Should You Switch?

If you're starting a new project with React and TanStack (you should), use Paraglide. It's the officially recommended solution, it's designed to match how modern React apps are structured, and the DX improvement is real.

If you're maintaining an existing app heavily invested in react-i18next, the migration cost is probably not worth it unless you're already hitting the pain points I described. It works fine. You'll just be quietly annoyed every time you need to translate something outside a component.

For me, the no-hook import alone was enough to never look back.

Paraglide JS: inlang.com/m/gerre34r/library-inlang-paraglideJs
TanStack i18n guide: tanstack.com/router/latest/docs/guide/internationalization-i18n
react-i18next TypeScript setup: i18next.com/overview/typescript
Portfolio: brodin.dev

A Totally Legitimate Way to Look More Productive on GitHub

Nathan — Fri, 17 Apr 2026 06:38:44 +0000

Yes, I have a repo whose sole purpose is to make my GitHub profile look busier than it is. No, I'm not ashamed. And here's how you can do it too.

It's quite easy to spot when I started it.

How It Works

Github's contribution graph tracks commits across all your repos, public and private, as long as they're on the default branch and the commit email matches your account. The whole system is activity-based: it doesn't care what you committed, just that you did. Which means it's trivially gameable.

The plan is simple: a private repo, a scheduled GitHub Action as the engine, and a Python script to make it look human.

GitHub Workflow

With a free GitHub Account, you have access to 2,000 minutes of free actions compute every month, so let's use that to run a 25s action.
A GitHub Workflow also allows you to define cron jobs, so we can simply define one to run every day.

Create a file at .github/workflows/contributor.yml:

First, define the trigger with a cron job:

on:
  schedule:
    # Runs at 08:00 UTC every day
    - cron: '0 8 * * *'

Define the job and give it permission to push commits:

jobs:
  daily-commits:
    runs-on: ubuntu-latest
    permissions:
      contents: write # Grants permission to push commits

Add the steps. First, checkout the repo:

steps:
  - name: Checkout repository
    uses: actions/checkout@v3

Set up Python and install dependencies:

- name: Set up Python
  uses: actions/setup-python@v4
  with:
    python-version: '3.9'

- name: Install dependencies
  run: pip install holidays

Configure git. Make sure to use the same email address as your GitHub account, else contributions will not be counted:

- name: Configure Git
  run: |
    git config --global user.name "Nathan Brodin"
    git config --global user.email "nathan@brodin.dev"

Run the auto-commit script:

- name: Run Auto-Commit Script
  run: python autocommit.py

Finally, push changes:

- name: Push changes
  run: git push

A Tiny Script To Make It Look Realistic

If you would make the exact same amount of commits, monday to sunday, even on Christmas day, you would easily be flagged as a faker. So to make it look natural, we'll write a tiny Python script to handle that. Create a file called autocommit.py:

First, add the imports:

import random
import subprocess
import datetime
import holidays

Define the git_commit function (must come before main()):

def git_commit(timestamp):
    with open("activity_log.txt", "a") as f:
        f.write(f"Commit made at {timestamp}\n")

    subprocess.run(["git", "add", "activity_log.txt"])

    message = f"Update activity log: {timestamp}"
    subprocess.run(["git", "commit", "-m", message])

Create the main() function. First, get today's date and check for weekends:

def main():
    today = datetime.date.today()

    if today.weekday() >= 5:
        print("Today is a weekend. Skipping.")
        return

You also skip public holidays, using the holidays package:

    country_code = "NO"  # Replace with your country code
    country_holidays = holidays.country_holidays(country_code)
    if today in country_holidays:
        print(f"Today is a holiday ({country_holidays.get(today)}). Skipping.")
        return

Remove days where you shouldn't be working (birthday, grandma's funeral...):

    quiet_days = {
        datetime.date(2026, 1, 1),
    }
    if today in quiet_days:
        print("Today is a quiet day. Skipping.")
        return

Randomize the count of commits, and weight them to make it more natural. Make sure the sum sums up to 100.

    # Randomize Commits: 0 commits has a 32% chance, max capped at 9
    num_commits = random.choices(
        range(10),
        weights=[32, 10, 8, 8, 8, 7, 8, 8, 6, 5],
        k=1
    )[0]
    print(f"Scheduled for {num_commits} commits today.")

Finally, call the commit function in a loop:

    for i in range(num_commits):
        current_time = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        git_commit(current_time)


if __name__ == "__main__":
    main()

Good job, You're now officially a 10x engineer (with a healthy work/life balance), at least visually.

Full code:

# .github/workflows/contributor.yml

name: Daily Contribution Automation

on:
  schedule:
    # Runs at 08:00 UTC every day
    - cron: '0 8 * * *'
  # Allows to run this workflow manually from the Actions tab for testing
  workflow_dispatch:

jobs:
  daily-commits:
    runs-on: ubuntu-latest
    permissions:
      contents: write # Grants permission to push commits

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.9'

      - name: Install dependencies
        run: pip install holidays

      - name: Configure Git
        run: |
          git config --global user.name "Nathan Brodin"
          git config --global user.email "nathan@brodin.dev"

      - name: Run Auto-Commit Script
        run: python autocommit.py

      - name: Push changes
        run: git push

# autocommit.py

import random
import subprocess
import datetime
import holidays

def git_commit(timestamp):
    with open("activity_log.txt", "a") as f:
        f.write(f"Commit made at {timestamp}\n")

    subprocess.run(["git", "add", "activity_log.txt"])

    message = f"Update activity log: {timestamp}"
    subprocess.run(["git", "commit", "-m", message])

def main():
    country_code = "NO"
    today = datetime.date.today()

    # Weekend Check
    if today.weekday() >= 5:
        print("Today is a weekend. Skipping.")
        return

    # Holiday Check
    country_holidays = holidays.country_holidays(country_code)
    if today in country_holidays:
        print(f"Today is a holiday ({country_holidays.get(today)}). Skipping.")
        return

    # Quiet Days Check
    quiet_days = {
        datetime.date(2026, 1, 1),
    }
    if today in quiet_days:
        print("Today is a quiet day. Skipping.")
        return

    # Randomize Commits — 0 commits has a 32% chance, max capped at 9
    num_commits = random.choices(
        range(10),
        weights=[32, 10, 8, 8, 8, 7, 8, 8, 6, 5],
        k=1
    )[0]
    print(f"Scheduled for {num_commits} commits today.")

    for i in range(num_commits):
        current_time = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        git_commit(current_time)
        print(f"Commit {i+1}/{num_commits} created.")

if __name__ == "__main__":
    main()

Between Tradition and Modernity: Building a Full Stack App with Django and React

Nathan — Mon, 13 Apr 2026 08:15:14 +0000

If I tell you I made a full-stack app with React 19 (+ Compiler), Tanstack Router, tailwindcss, Base UI, and pnpm, you would probably expect a Hono backend or Tanstack Start Server functions with Drizzle, or at least some cutting-edge TS solution. Well, I've built a Django backend, and it works pretty well!

The Constraints vs. The Freedom

When starting a new project, you always face constraints. Your job as the person designing the software architecture is to find the most elegant way to build around them.

Here are the constraints I was handed:

Django for the backend (to match the team's existing legacy projects).
Keycloak for authentication.
Dockerizing the entire stack for self-hosted deployment.

The freedom? I got to decide absolutely everything else.

If you’ve read my previous blog posts, you know I’ve fallen in love with the Tanstack ecosystem. I went with Tanstack Router, Query, Form, Table, and Pacer. Notice that I didn't go with Tanstack Start. Given the actual goals of this app, I couldn't justify the SSR overhead, and I absolutely did not want to spend a single second fixing hydration issues (I still have nightmares about them).

For the UI, I finally got to use TailwindCSS and shadcn/ui at work, freeing myself from plain CSS and the horrors of styled-components. I really love the pattern of creating headless, reusable components:

export function PageHeader({ className, children, ...props }: React.HTMLAttributes<HTMLElement>) {
  return (
    <header
      className={cn('grid auto-rows-min items-start gap-2', className)}
      data-slot="page-header"
      {...props}
    >
      {children}
    </header>
  )
}

(Yes, it kind of looks like styled-components in a way. Maybe time is a flat circle?)

A quick shoutout to two other bangers in the frontend stack:

Paraglide JS: After fighting with react-i18next (lack of type safety, fetching all keys client-side), I switched to Paraglide JS on Tanstack's recommendation. Zero downsides so far.
Knip: Analyzes your codebase for unused files, exports, and dependencies. Even with the strictest ESLint/Prettier setup, you’ll have dead code. Knip is a godsend for cleanup.

Bridging the Gap: The Auth Weirdness

Let's talk about the weird authentication layer in the app, that I am not a big fan of.

The client authenticates with Keycloak. This means I need to check auth on the frontend (using react-oidc-context and oidc-client-ts, which have pretty bad documentation) and store the auth context.

I then pass the key to the backend during API calls, where Django verifies it using jwt.decode against the public key. It doesn't sound that bad, except that Django has its own pre-built auth system with user tables, and Keycloak isn't designed to store app-specific user metadata. So, I had to build a weird, performant sync layer between the two (e.g., if a Keycloak email changes, reflecting it locally in the Postgres DB). It’s clunky, but it works.

Type Safety is still possible

I love type safety. Coming from TypeScript, and having played with C and Dart in school, dynamic typing gives me hives.

Out of the box, Python can feel a bit like the Wild West compared to a strict TypeScript setup. With standard dependencies often living in a simple .txt file and optional linting, it gives you a lot of freedom. But that freedom means you have to actively put in the work to enforce a strong Developer Experience, otherwise code quality can slip quickly.

However, having a Python backend and a TypeScript frontend doesn't mean you have to sacrifice end-to-end type safety. Here is how I forced the two to play nice:

Django properly defines the models with strict types and comments.
Backend views have full documentation on response types using those models.
drf-spectacular generates the OpenAPI specs.
Orval generates TS types and query hooks from those specs.
The frontend consumes the Tanstack Query Hooks to fetch data.

And just like that... End-to-end type safety. You know exactly what the endpoint needs, and exactly what it's going to return. When you make a change in a model, you get the feedback all the way to your frontend component.

DX: Making the Containers Bearable

After the users, my top priority is the developers (and code quality). Because of the strict constraints, I got to tear my hair out properly learning Docker. Setting up multiple services, ensuring they communicate, and managing deployment across two environments in a server full of existing apps was a massive headache.

But once it works, Docker is magic. Starting the project takes one command. You get fully reproducible environments between local dev and production. So now you can use the "But it works on my machine" excuse more confidently.

I also spent some time creating Make commands. These Docker commands are quite long and spending 5 minutes going up in the terminal history trying to find the specific command to run the tests can be quite annoying. So I wrote a Makefile. Now, a simple make codegen spins up the OpenAPI specs and frontend types:

COMPOSE_FILE := docker-compose.dev.yml
ENV_FILE     := .env.local
COMPOSE      := docker compose -f $(COMPOSE_FILE) --env-file $(ENV_FILE)

.PHONY: codegen
codegen: schema types ## Generate both Schema and Types

.PHONY: schema
schema: ## Generate Open API schema from Backend
    $(COMPOSE) exec backend python manage.py spectacular --file openapi.yml --validate

.PHONY: types
types: ## Generate TypeScript types from Open API schema
    $(COMPOSE) exec frontend pnpm run generate-types

I also built a strong CI pipeline. It handles backend linting and formatting, 800+ Django tests, migration checks, OpenAPI schema validation, Frontend Schema Types validation, frontend type checking, frontend build, and finally Playwright tests.

It sounds heavy, but it only takes ~7 minutes if all steps run, thanks to aggressive caching, sharding, and parallel jobs. If I only touch backend code, the pipeline finishes in 2 minutes. Stop the pipeline early, run only what changed. It’s worth the initial setup time.

Boring isn't bad

Django is not the most exciting tech, but it’s great for a CRUD app exposing APIs to Postgres. Yes, I still have to handle some complexity: RBAC, Redis caching, querying a Clickhouse DB with raw SQL, and WebSockets for live notifications, but I’m not building a crazy app for millions of users.

Django is simple, predictable, and LLMs understand it perfectly. Need a cache layer? Two lines of code. It’s fast enough that running 800+ tests (including DB writes) takes 10 seconds.
I still have some issues with it, like if there is an internal server error, an endpoint will return some html by default. So you need a custom middleware to formalize all kinds of errors. And of course, it has to be in Python. But overall: it just works.

The Silo Problem: Designing APIs in a Vacuum

Now, for a bit of a reality check regarding backend development.

In theory, backend engineers handle incredibly important tasks: complex business logic, rock-solid security, scaling, and database optimizations. This should put to shame frontend engineers like me who spend 2 hours changing the color of a button.

But in my early years of corporate experience, my reality has been quite different. I have only encountered codebases where basic software engineering practices, like mandatory PR reviews, automated testing, or even basic linting, just weren't part of the culture. When teams don't put effort into those foundations, you quickly end up with messy codebases, weak RBAC, major security oversights, and poor performance. More importantly, I’ve encountered the "Silo Problem."

It goes like this: the backend team designs their database models and endpoints in isolation, without involving the frontend or the designer. The result never maps to what the UI actually needs, data models that clash with the design system, endpoints structured in a way that require several workarounds on the client just to render a basic view, and OpenAPI specs handed down after the fact that rarely match the live responses. I've seen it more than once, and it never stops being painful.
If you are a backend developer adding a new endpoint, you aren't doing it for fun. You are doing it because the user interface needs that data. Designing APIs without consulting the client-side needs is like building a steering wheel without checking what kind of car it's going into.

Thankfully, on my current project, I am the frontend, backend, and DevOps engineer. Everything communicates nicely, because I actually talk to myself.

The Corporate Reality

I started this new grad job in mid-2025 at a small non-tech company, specifically because I wanted the freedom to build good products and actually care about software architecture.
And I did get that freedom. I spent hours refining small details, optimizing DX, and over-engineering the type safety.

But as the months go by, a weird realization has set in. This app will never scale to the hundreds of thousands of users I was used to handling in previous roles. Projects like this one are inherently temporary, business priorities shift, tools get replaced, and what matters today might be irrelevant in two years. The business goal is to ship a working solution, not to build a lasting technical marvel.

It's a strange feeling. You pour real craft into something and the honest answer is: it probably didn't need to be this good. But I think that's okay. The craftsmanship wasn't wasted: I learned a lot building it this way, and I'd rather over-engineer once and learn than ship something I'm not proud of.

And at the end of the day, I get to log off and live in one of the most beautiful places in the world. That counts for something.

"You Wouldn’t Steal a DIV": How I Built My Portfolio

Nathan — Thu, 12 Mar 2026 14:35:18 +0000

A story about how I built my portfolio and what went through my mind while building it

Hello, World! Here's my first ever blog.

I wanted to talk a bit about my portfolio, how I built it, why I made some of these architectural and design decisions, and why I shamelessly 'borrowed' my way to designs I love.

1 Stack, 2 Stack, Tech Stack, 4

(If you didn't read that header in Slim Shady's voice, I don't know what to tell you.)

First of all, let's talk tech stack. I used to have all of my personal projects (including my previous portfolio) built with Next.js. These were small side projects, without complicated logic, and with simple needs. Yet, I would always run into Next.js edge cases. Turbopack was failing my dev builds because it wouldn't play nice with Contentlayer, HMR was taking actual seconds to refresh, and production builds were taking 50 seconds for projects that barely scaled. When I got to choose a stack for a new project at my job, I couldn't justify the Next.js overhead for production apps, considering the friction I had with small personal projects.

At that time, everyone was talking about Tanstack Start: the "DX God." But even their starter app had linting and TS issues, so I wasn't fully impressed. I stuck with only Tanstack Router for that project, and as weeks passed by working with the entire Tanstack Ecosystem (except Start), I was really enjoying it. The documentation is well written and extensive (even too much sometimes), DX actually made sense, and I could find all of the features I liked about Next.js (file base routing for example) while still having great performance (15s builds).

So this led me to give a second chance to Tanstack Start, and I built this portfolio with it! I still love Vercel's UX, and wander around their dashboard to see how I should implement my stuff, but I think I'll leave Next.js behind for now. And personal projects are made to experiment with stuff. So I just want to try out different tech and see what I like or not, purely on feelings.

Then for the component library, I was really into coss ui. I stumbled upon it randomly one day and loved it so much. My Nathan's AI project already had a UI heavily inspired by cal.com: send button, message suggestions... So when I saw they had a shadcn/ui library with that kind of style, it was perfect for what I needed.

I can also consider myself a proud Open Source Contributor after getting two PRs merged into coss ui (a 2-line diff and I'm not even kidding, but quality over quantity, I guess...?).

Stealing...I Mean, Getting Inspired By Chanhdai and Zed

Now I'm not going to lie and say I designed and coded everything myself. I took large parts of the code and page layout from the open-source portfolio by Chanhdai and design inspiration from zed.dev, which I had previously attempted in unfinished side projects (https://trends.brodin.dev and https://ui.brodin.dev if they're still available).

I still went a different way than Chanhdai for the code implementation. For example, I chose to store my content in markdown files using Content Collections. I did this specifically so I could easily serve my portfolio's content in plain text, perfect for LLM consumption, which ties right back into the needs of my Nathan's AI project.
I also used Base-ui (because of coss ui) for components, and generally went with a different style. So this was not just a simple copy/paste or a fork, there was still a lot of work involved.

For Zed, I took the same fonts for the headings and text, and the grid layout with the "diamonds" at the intersections. It really adds personality to my portfolio (not my personality since I stole it, but some personality).

Also, by a great coincidence, Chanhdai had very basic sound design, like a sound when changing the theme, and I wanted to push things further by having different sounds around the entire app. I was looking around on the web for good sound libraries and all, but couldn't find anything interesting. Then the next day, I saw a tweet about the upcoming release of Soundcn, which was exactly what I was looking for. So now you get a bunch of sounds when clicking on stuff in my portfolio. It's a nice touch!

From good to WHOA

Lastly, the thing that elevated my portfolio from a good portfolio to a Whoa portfolio are the dither shaders (from Paper Shaders) that I have for page headings and section dividers. I had dither shaders in mind since the first day I saw them on React Bits, but couldn't find a good way to integrate them. So it ended up being a crossover between inspiration from the heading of zed.dev (open the dev console and see data-paper-shader on the headings) and Fumadocs, which had them as well.

To wrap things up

So in conclusion, I would say this portfolio is a cross between Chanhdai and Zed, with a better stack.

Go ahead, click around to hear the sound integration (it gets annoying after a while, be careful), check out the dither shaders on the headings, and check out the source code here if you want to steal from me like I did from everyone (but at least leave a star on the repo).

Blog Title reference: This classic: "You Wouldn't Steal a Car"
My Portfolio: brodin.dev
Initially posted on my blog