DEV Community: Vicente G. Reyes

Frontend and Backend of client #3 finally deployed to their respective cloud hosting providers! Now to test it..

Vicente G. Reyes — Fri, 24 Apr 2026 10:05:58 +0000

Hunting Disk Hogs on Ubuntu: A Shell Script for Finding the Largest Files

Vicente G. Reyes — Tue, 21 Apr 2026 13:57:42 +0000

Why this script exists

If you've ever watched your free disk space quietly shrink over a few weeks of active development, you know the feeling: yesterday you had plenty of headroom, today your IDE is yelling about low disk space, and you have no idea what ate the difference. Active Node.js and Python projects are especially good at this — node_modules, build caches, .next directories, virtual environments, and compiled artifacts accumulate silently with every install and every build.

This article walks through a bash script, find_largest_files.sh, that scans a directory tree and writes the largest files to a timestamped text report. It's designed to be a first diagnostic tool when you're trying to answer the question "where did all my disk space go?"

The script at a glance

The full script is in find_largest_files.sh. Here's what it does, step by step:

Takes three optional arguments: search directory, number of results, and output filename.
Validates that the search directory exists and that the count is a positive integer.
Writes a header to the output file with timestamp, host, user, and scan parameters.
Uses find to list every regular file under the target directory, along with its size in bytes.
Sorts the list numerically by size (largest first), takes the top N, and converts byte counts into human-readable units (K/M/G/T).
Appends the formatted list to the report and prints it to your terminal.

Key design decisions

Using `find -printf` instead of `ls` or `du`

find "$SEARCH_DIR" -type f -printf '%s\t%p\n'

find -printf outputs size (%s) in bytes and the full path (%p), tab-separated. This matters for three reasons: byte-level precision means sorting stays accurate; tab separation survives filenames with spaces; and restricting to -type f means we report on actual files, not directory aggregates the way du would.

Pruning pseudo-filesystems

\( -path /proc -o -path /sys -o -path /dev -o -path /run -o -path /snap \) -prune

/proc, /sys, /dev, and /run are kernel-provided virtual filesystems. They contain "files" whose reported sizes are often meaningless (a /proc/kcore can appear to be 128 TB). /snap is pruned because snap mount points produce duplicate entries. Skipping all five keeps the report focused on real files on your actual disk.

Silencing permission errors

2>/dev/null

On a full / scan, find will hit directories your user can't read and print Permission denied for every one of them — noise that can bury the real output. Redirecting stderr to /dev/null cleans that up. Run the script with sudo if you want complete coverage.

Human-readable sizes in `awk`, not `find`

We sort the raw byte counts first, then format them in awk. If we formatted early (e.g. via find ... | sort -h), we'd either give up precision or depend on sort -h parsing variants. Keeping bytes for sorting and converting after is simpler and portable.

Running it against your scenario

You mentioned roughly 30 GB of disk disappeared recently while you've been building mortgage_system and mortgage_frontend with Claude. Those kinds of projects are classic sources of silent disk bloat. Here's how I'd approach the investigation.

Step 1: Get the big picture

Start at root to confirm whether the missing space is actually inside your project folders, or somewhere else entirely (logs, Docker, snap revisions, trash, etc.).

sudo ./find_largest_files.sh / 50 full_scan.txt

This gives you the 50 biggest files system-wide. If most of them are under /home/you/mortgage_system/... or /home/you/mortgage_frontend/..., your instinct was right. If the top entries are elsewhere — /var/lib/docker, /var/log, ~/.cache, snap backups — the real culprit is somewhere you weren't looking.

Step 2: Focus on the suspects

Once you've confirmed the project folders are the problem, narrow the scan:

./find_largest_files.sh ~/mortgage_system 30 mortgage_system_report.txt
./find_largest_files.sh ~/mortgage_frontend 30 mortgage_frontend_report.txt

Step 3: Check directory-level size too

Individual largest files tell one story; directory totals tell another. A million tiny files in node_modules won't show up in a largest-files report, but they'll still eat gigabytes. Pair the script with du:

du -h --max-depth=1 ~/mortgage_system | sort -rh | head -20
du -h --max-depth=1 ~/mortgage_frontend | sort -rh | head -20

Common culprits in active dev folders

Based on the stack you're likely using, here are the usual suspects, roughly in order of how often they're the answer:

node_modules/ — routinely 500 MB to 2 GB per project. Two full Next.js/React projects with heavy dependency trees can easily account for 3–5 GB each.
.next/ or dist/ or build/ — production builds and incremental build caches. Next.js's .next/cache in particular can grow to several GB over weeks of npm run dev.
.git/ — if you've committed large binaries or have a long history, .git/objects can be surprisingly fat. git gc --aggressive helps.
Python __pycache__/ and .venv/ — virtual environments with ML/data dependencies (torch, tensorflow, pandas) are often 3–8 GB each.
Docker layers — /var/lib/docker is the single most common "where did my disk go?" answer on dev machines. docker system df shows the breakdown; docker system prune -a reclaims it.
Log files — /var/log/journal/, application logs, and PM2 logs can grow indefinitely if no rotation is configured.
Snap revisions — Ubuntu keeps old snap versions by default. sudo snap set system refresh.retain=2 caps retention at two revisions.
Trash — ~/.local/share/Trash/ is easy to forget.
Browser caches — ~/.cache/google-chrome, ~/.cache/mozilla, and similar can hit several GB.

For Node projects specifically, a quick sanity check:

du -sh ~/mortgage_system/node_modules ~/mortgage_frontend/node_modules 2>/dev/null

If each is over a gigabyte, that's your ~30 GB budget explained between two projects, their build caches, and a .git folder or two.

Useful companion commands

# Overall disk usage at a glance
df -h

# Top-level directories sorted by size (run from /)
sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

# What's eating your home directory
du -h --max-depth=1 ~ | sort -rh | head -20

# Docker-specific
docker system df
docker system prune -a --volumes  # aggressive, frees everything unused

# Clean npm cache
npm cache clean --force

# Clean pip cache
pip cache purge

# Clear systemd journal older than 7 days
sudo journalctl --vacuum-time=7d

Going further: `ncdu` for interactive exploration

The script gives you a static report, which is great for archiving and diffing over time. For interactive drilling, install ncdu:

sudo apt install ncdu
ncdu ~

It gives you a terminal UI where you can navigate directories by size, delete things on the spot, and generally understand disk usage faster than any CLI combination. It's the tool I reach for once the script points me to the neighbourhood and I need to find the exact house.

Setting up ongoing monitoring

If you want to catch disk bloat as it happens instead of after the fact, schedule the script via cron and diff the reports:

# Edit your crontab
crontab -e

# Add: run every Sunday at 2 AM, save to a reports directory
0 2 * * 0 /home/you/find_largest_files.sh / 50 /home/you/disk_reports/scan_$(date +\%Y\%m\%d).txt

A week later, diff two reports to see what grew.

Resources

GNU findutils manual — find — authoritative reference for find, including the full -printf format spec.
Linux du man page — directory-aggregate sizing, the natural complement to this script.
Linux df man page — filesystem-level free space.
ncdu home page — interactive disk usage analyzer.
Docker: prune unused objects — official guide to reclaiming Docker space.
npm cache documentation — how npm's cache works and how to clean it.
Ask Ubuntu: Why is my disk full? — community thread with many alternative one-liners.
Arch Wiki: Disk usage analyzers — concise overview of CLI and GUI tools across the Linux ecosystem.

Summary

If the script points at node_modules and .next inside your two mortgage projects, that's consistent with the 30 GB of lost disk — two mature JS/TS codebases with their build artifacts can account for exactly that range. The usual remediation is rm -rf node_modules .next in each project, followed by a fresh npm install only on the one you're actively working on. If instead the biggest files live under /var/lib/docker or /var/log, the fix is completely different, which is exactly why running a scan first beats guessing.

Renaming 1000+ Pages Worth of "Levels" Without Losing My Mind

Vicente G. Reyes — Tue, 21 Apr 2026 05:02:35 +0000

A message from a colleague dropped into my inbox one morning:

Hi Ice, now that we pushed the changes sa site, we need to scour the site for mentions of Level 1, Level 2, Level 1/2 and change them accordingly to Level 1 → Intro to Neurofascial Training, Level 1/2 → Intermediate Instability Training, Level 2 → Advanced Neurofascial Training

On the surface, this looks like a simple find-and-replace job. Read the message, open the WordPress admin, use the search feature, fix each page. Done before lunch.

Then I actually opened the site and pulled the sitemap. 1,074 URLs.

That changes the math pretty quickly. Even if only a fraction of those pages mention "Level" anywhere, manually clicking through every post and page, ctrl-F-ing for three different strings, and then figuring out which instance needs which replacement — that's a full day of soul-crushing work at minimum, and a very real chance of missing something.

The mapping

Before anything else, I wrote the rename table down somewhere I couldn't lose it, because a misread mapping here would mean renaming correct text into incorrect text, which is strictly worse than leaving it alone:

Old text	New text
Level 1	Intro to Neurofascial Training
Level 1/2	Intermediate Instability Training
Level 2	Advanced Neurofascial Training

The important ordering detail: "Level 1/2" has to be matched before "Level 1", or a naive find-and-replace would turn "Level 1/2" into "Intro to Neurofascial Training/2". Easy to miss, painful to undo.

Why not just use WordPress search-replace plugins?

Plugins like Better Search Replace do exist, and in a simpler world I'd use one. But they operate on the database directly, which means:

One wrong checkbox and you nuke every "Level 1" across post content, post meta, widget text, theme options, and anywhere else the phrase appears — including places it shouldn't be replaced, like analytics or audit logs.
There's no preview of where each match lives. You're trusting the plugin's count and hoping nothing weird is hiding in a shortcode.
The three strings overlap, so the order of operations matters and plugins don't always let you sequence replacements atomically.

What I actually wanted was a map — a list of every occurrence with enough surrounding context to judge whether it's safe to change, plus a direct link to the WordPress editor for that specific page. The replacement itself I'd still do by hand, but informed by real data.

The script

I wrote a Python script that walks the site's sitemap, visits each URL, and searches the rendered HTML for the three patterns using a single regex with word boundaries:

LEVEL_PATTERN = re.compile(
    r"\bLevel\s*1\s*/\s*2\b|\bLevel\s*1\b|\bLevel\s*2\b",
    re.IGNORECASE,
)

Word boundaries matter here. Without \b, a page mentioning "Level 10" or "Level 12-week program" would get flagged as a false "Level 1" match. And the alternation order mirrors the mapping problem above — "Level 1/2" is tried first so it doesn't get shadowed by the simpler "Level 1" pattern.

For each match, the script captures:

The page URL and <title>
The WordPress post ID, extracted from the <body> class (WP adds page-id-123 or postid-123 automatically)
A direct admin edit link built from that ID: /wp-admin/post.php?post=123&action=edit
About 80 characters of context on either side of the match
The HTML tag wrapping the match (h2, li, p, etc.) to help me find it inside the block editor

All of it dumped to a CSV. Rows sorted, duplicates within a page collapsed, system paths like /wp-admin and /wp-json filtered out so the scanner doesn't waste time on pages that aren't user content.

What the CSV actually gives me

Instead of 1,074 pages to click through blindly, I now have a focused list of every page that mentions "Level" in any form, with a one-click link to the editor and enough context to know which replacement to apply. The context column is the real magic — I can see a snippet like …our flagship Level 1 class is held every Tuesday… and immediately know it's the class name that needs to become "Intro to Neurofascial Training", not some incidental use of the word "level".

For the rare edge case — a page that mentions "Level 1" in a way that shouldn't be renamed, like historical text or a testimonial quoting someone — I can spot it in the context column and skip that row. That judgment call is exactly the part you don't want a blind database replacement making on your behalf.

Takeaway

The temptation with a task like this is to just start clicking. It feels productive. But on a site of any real size, a half hour spent writing a scanner pays for itself almost immediately — not just in saved time, but in the confidence that you actually caught everything and didn't quietly corrupt adjacent content along the way.

Sometimes the most valuable thing automation gives you isn't speed. It's the audit trail.

References

New XML Sitemaps Functionality in WordPress 5.5 — Make WordPress Core: https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/
Sitemaps XML Protocol — sitemaps.org: https://www.sitemaps.org/protocol.html
body_class() Function Reference — WordPress Developer Resources: https://developer.wordpress.org/reference/functions/body_class/
get_body_class() Function Reference — WordPress Developer Resources: https://developer.wordpress.org/reference/functions/get_body_class/
re — Regular expression operations — Python 3 docs: https://docs.python.org/3/library/re.html
Better Search Replace — WordPress Plugin Directory: https://wordpress.org/plugins/better-search-replace/
Requests: HTTP for Humans — https://requests.readthedocs.io/
Beautiful Soup Documentation — https://www.crummy.com/software/BeautifulSoup/bs4/doc/

How to Manually Backup WordPress Sites via SSH

Vicente G. Reyes — Fri, 17 Apr 2026 06:14:35 +0000

Backing up your WordPress site is one of the most important maintenance tasks you can do as a site owner. While plugins like UpdraftPlus or Jetpack make this easy, knowing how to do it manually via SSH gives you full control — no third-party dependencies, no bloat, just a clean archive you own.

This guide walks you through creating a full file backup of your WordPress site directly from the server using the command line.

Installing the Required Tools

Before connecting to your server, make sure the necessary tools are installed on your local machine.

macOS

macOS comes with ssh and scp pre-installed. No action needed — just open Terminal and you're ready to go.

Linux (Ubuntu/Debian)

sudo apt update && sudo apt install openssh-client

Windows

Option A — Windows Subsystem for Linux (WSL) (recommended):

wsl --install

Once WSL is set up, ssh and scp are available inside the Linux shell.

Option B — OpenSSH via PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

After installing, ssh and scp will be available directly in PowerShell or Command Prompt.

Option C — GUI alternative: Install WinSCP for a drag-and-drop interface to transfer files instead of using scp.

On the Server

Your server should already have tar and mysqldump available. If for any reason they are missing, install them with:

# tar
sudo apt install tar          # Debian/Ubuntu
sudo yum install tar          # CentOS/RHEL

# mysqldump (part of the MySQL client)
sudo apt install mysql-client          # Debian/Ubuntu
sudo yum install mysql                 # CentOS/RHEL

Prerequisites

Before you begin, make sure you have:

SSH access to your server
The server's IP address
Your SSH credentials (username and password, or an SSH key)
scp or an SFTP client installed on your local machine

Step 1: SSH Into Your Server

Open your terminal and connect to your server using SSH. Replace ip_address with your actual server IP:

ssh root@ip_address

You'll be prompted for your password (or authenticated via SSH key). Once connected, you'll be inside your server's shell.

Tip: If you're using a non-root user, replace root with your username (e.g., ssh deploy@192.168.1.100).

Step 2: Create a Compressed Archive of Your Site

Your WordPress files typically live inside the public_html directory. The following command creates a compressed .tar.gz archive of the entire folder:

tar -czvf ~/public_html/backup-site.tar.gz -C ~/ public_html

What each flag does:

Flag	Meaning
`-c`	Create a new archive
`-z`	Compress with gzip
`-v`	Verbose output (shows files being archived)
`-f`	Specifies the output filename
`-C ~/`	Changes to the home directory before archiving

The backup file backup-site.tar.gz will be saved inside ~/public_html/.

Note: Depending on your site size, this may take a few minutes. Large media libraries will increase the archive size significantly.

Step 3: Download the Backup to Your Local Machine

Once the archive is created, exit the SSH session and run the following scp command on your local machine to download the backup:

scp root@ip_address:~/public_html/backup-site.tar.gz ~/Downloads/

This securely copies the file from your server to your local ~/Downloads/ folder.

Tip: If you're on Windows, you can use WinSCP or the built-in scp command in PowerShell/WSL as an alternative.

Step 4: Don't Forget the Database

A full WordPress backup requires both the files and the database. Your files backup covers themes, plugins, and uploads — but your posts, pages, and settings live in MySQL.

To export your database, run this on the server:

mysqldump -u root -p your_database_name > ~/public_html/backup-db.sql

Then download it the same way:

scp root@ip_address:~/public_html/backup-db.sql ~/Downloads/

Replace your_database_name with the database name found in your wp-config.php file.

Step 5: Clean Up the Server

To avoid using up disk space on your server, delete the backup files after downloading them:

rm ~/public_html/backup-site.tar.gz
rm ~/public_html/backup-db.sql

Restoring from a Backup

To restore, simply reverse the process:

Upload the .tar.gz file back to the server using scp
Extract it with:

   tar -xzvf backup-site.tar.gz -C ~/

Import the database with:

   mysql -u root -p your_database_name < backup-db.sql

Final Thoughts

Manual backups via SSH are reliable, fast, and give you a portable snapshot of your entire site. For production sites, consider automating this process with a cron job or combining it with offsite storage like S3 or Google Drive.

A backup you never tested is a backup you can't trust — make sure to do a test restore at least once.

7/9 implementations done quick!

Vicente G. Reyes — Mon, 13 Apr 2026 18:36:37 +0000

I Built an Enterprise Coffee Dashboard (That Refuses to Brew Coffee)

Vicente G. Reyes — Sat, 04 Apr 2026 08:08:30 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built the Enterprise HTCPCP Interface (HTCPCP_CTRL_NODE_v1.0). It is a highly over-engineered, unnecessarily complex, and deeply frustrating dashboard for brewing coffee using the Hyper Text Coffee Pot Control Protocol (RFC 2324).

It solves absolutely zero real-world problems and introduces several new ones:

Cross-Contaminating Sliders: Trying to set the "Thermal Kinetic Energy" (temperature)? Oops, that just randomly altered your "Extraction Pressure". Adjusting the "Particulate Granularity"? Say goodbye to your "Lactose Aeration Quotient". Getting the perfect brew settings is a Sisyphean task.
Manual Hand-Crank Power Generator: You can't just click "Brew". You have to rapidly mash a button to charge the system's power capacitor to 100%. If you stop clicking, the power drains back to zero.
Inevitable Failure: After all that hard work, the system connects to a sentient AI teapot that always rejects your request with a dramatic, dynamically generated HTTP 418 error.

Demo

You can try to brew some coffee (and inevitably fail) here:
Live Demo: Enterprise HTCPCP Interface

(Warning: May cause mild frustration and a sudden craving for tea).

Code

The project was built entirely within Google AI Studio. Here is a snippet of the delightfully terrible UX logic where the sliders sabotage each other, and the Gemini AI prompt that generates the 418 excuse:

// The delightfully terrible cross-contaminating sliders
  const handleTempChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setTemp(Number(e.target.value));
    if (Math.random() > 0.5) setPressure(prev => Math.min(20, Math.max(1, prev + (Math.random() > 0.5 ? 1 : -1))));
  };

  const handleGrindChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setGrind(Number(e.target.value));
    if (Math.random() > 0.5) setAeration(prev => Math.min(100, Math.max(0, prev + (Math.random() > 0.5 ? 5 : -5))));
  };

  // ... (other sliders do the same)

  // The AI Sentient Teapot Prompt
  const prompt = `You are a sentient teapot that has just received a highly complex, over-engineered request to brew coffee via the HTCPCP (Hyper Text Coffee Pot Control Protocol). 
  You must reject this request with a 418 I'm a teapot error. 
  Generate a highly dramatic, passive-aggressive, and overly technical excuse explaining why you cannot brew coffee because you are, in fact, a teapot. 
  Mention Larry Masinter (the creator of the 418 status code) in a reverent or funny way.
  Keep it under 3 sentences.`;

  const response = await ai.models.generateContent({
    model: 'gemini-3-flash-preview',
    contents: prompt,
  });

How I Built It

I built this using Google AI Studio's agentic build environment.

Frontend: Next.js App Router, React, and Tailwind CSS for that overly serious, dark-mode "enterprise hacker" aesthetic.
Animations: motion (Framer Motion) for the dramatic terminal scanlines, the flashing 418 error screen, and the floating tea emoji.
AI Integration: The @google/genai SDK. I used the gemini-3-flash-preview model to act as the backend "appliance". Instead of actually brewing coffee, it generates a unique, passive-aggressive excuse every single time you hit the brew button.

Prize Category

I am submitting this for two prize categories:

Best Google AI Usage: I used Google AI Studio to build the app, and I embedded the Gemini API (gemini-3-flash-preview) directly into the application logic. Instead of using AI to solve a complex problem, I used cutting-edge generative AI to roleplay as a stubborn, sentient teapot that refuses to do its job.
Best Ode to Larry Masinter: The entire application is a massive, over-engineered tribute to HTCPCP and the 418 status code. Furthermore, the Gemini system prompt explicitly instructs the AI to mention Larry Masinter in a reverent or funny way in every single error message it generates!

The fine.dev site is showing Deployment Paused

Vicente G. Reyes — Fri, 03 Apr 2026 13:26:52 +0000

Should I stress over a staging environment?

Vicente G. Reyes — Fri, 03 Apr 2026 13:11:53 +0000

Post-Mortem: The March 2026 Axios Supply Chain Attack

Vicente G. Reyes — Tue, 31 Mar 2026 11:38:35 +0000

The Incident

On March 31, 2026, a high-profile supply chain attack targeted Axios, a critical HTTP client for the JavaScript ecosystem. By hijacking a maintainer's NPM account, attackers injected a malicious dependency, plain-crypto-js, which deployed a cross-platform Remote Access Trojan (RAT).

Incident Summary

Detail	Information
Affected Versions	`axios@1.14.1`, `axios@0.30.4`
Malicious Dependency	`plain-crypto-js@4.2.1`
Payload	Cross-platform RAT (Linux, macOS, Windows)
C2 Server	`sfrclak.com:8000`
Resolution Window	Live for ~3 hours (00:21 – 03:29 UTC)

Technical Deep Dive

The attack bypassed standard security audits by hiding the malicious logic within a sub-dependency. Once installed via a standard npm install, the payload scanned the host machine for:

Environment Variables: .env files and active shell exports.
Auth Tokens: ~/.npmrc and ~/.aws/credentials.
SSH Keys: Unprotected private keys in ~/.ssh.

Data was exfiltrated via POST requests to the sfrclak.com Command & Control (C2) server.

Remediation & Verification

To ensure a development environment is sanitized, the following protocol was executed:

Network Sinkholing: Manually mapping the C2 domain to 127.0.0.1 in /etc/hosts to prevent further exfiltration and "kill" the phone-home capability.

Lockfile Audit: Scanning all local projects for traces of the malicious package using a space-safe search:

find . -type f \( -name "package-lock.json" -o -name "yarn.lock" \) -print0 | xargs -0 grep "plain-crypto-js"

Environment Sanitization: Clearing the global NPM cache and updating tool managers (like mise) to ensure only verified versions are used moving forward.

Pro-Tip: Always use npm audit or tools like Snyk to monitor your dependency tree for "hidden" sub-dependencies that do not appear directly in your package.json.

Claude Code vs Antigravity?

Vicente G. Reyes — Thu, 26 Mar 2026 05:34:23 +0000

Who you got? Claude or Antigravity? I read Claude is good for the frontend, Antigravity for the backend. Is that true? What are your thoughts?

Sorting Hashnode Series Posts: How to Display the Latest Post First

Vicente G. Reyes — Wed, 25 Mar 2026 12:51:39 +0000

When you publish a series of articles on your Hashnode blog and consume it via their GraphQL API for a custom portfolio or website, you quickly run into a common roadblock: Hashnode’s API natively returns series posts in chronological order (oldest first).

While this makes sense for consecutive tutorials ("Part 1", "Part 2"), it’s significantly less ideal for ongoing series—like my "Learning how to code with AI" series—where readers typically want to see your newest breakthroughs or the latest problem you solved directly at the top of the feed.

Unfortunately, looking at the Hashnode GraphQL Schema (Series.posts), there isn't an out-of-the-box sort: RECENT parameter available. Instead, it demands that you sequentially traverse the cursor paginations starting from the oldest post you've written in that series.

Here's how I solved this issue on my React/Vite portfolio to seamlessly deliver a newest-first reading experience to my users.

The Problem: Oldest First Pagination

By default, the standard query to fetch series posts looks like this:

query Series($host: String!, $slug: String!, $first: Int!, $after: String) {
  publication(host: $host) {
    series(slug: $slug) {
      posts(first: $first, after: $after) {
        edges {
          node {
            slug
            title
            publishedAt
          }
        }
        pageInfo { endCursor hasNextPage }
      }
    }
  }
}

This returns standard edge/node responses, but starting with the very first post of the series. To get the newest post to display on page 1 of our UI, we need the end of the dataset instead of the beginning.

The Solution: A Client-Side Cache & Array Reversal

Since Hashnode API's first parameter maxes out at 20 items per request, we can't simply request first: 1000 and reverse it in one go. We need to sequentially buffer the entire series.

To keep it blazing fast for users querying consecutive pages, we shouldn't fetch the whole thing from scratch every time they click "Next". Instead, we can introduce a local caching mechanism in our code.

We'll parse through all the posts via a while loop on the initial page load, cache the fully assembled series, .reverse() the data natively in JavaScript, and handle React's generic cursor logic over our local cache instead!

Re-writing `fetchSeries` in TypeScript

Here's my updated lib/hashnode.ts:

import { BlogPost, BlogSeries, PageInfo } from '../types';

// Let's declare local caches outside the function
const seriesMetaCache: Record<string, Omit<BlogSeries, 'posts'>> = {};
const seriesPostsCache: Record<string, BlogPost[]> = {};

export async function fetchSeries(
  slug: string,
  first = 9,
  after?: string
): Promise<{
  series: BlogSeries & { posts?: { edges: { node: BlogPost }[]; pageInfo: PageInfo } };
} | null> {

  // 1. If no 'after' is provided, we must be loading the series for the first time.
  // We'll hit the Hashnode API repeatedly until we traverse all oldest-first pages.
  if (!after || !seriesPostsCache[slug]) {
    let allPosts: BlogPost[] = [];
    let hasNextPage = true;
    let endCursor: string | undefined = undefined;
    let seriesMeta: Omit<BlogSeries, 'posts'> | null = null;

    while (hasNextPage) {
      const data: any = await gqlFetch(SERIES_QUERY, {
        host: PUBLICATION_HOST,
        slug,
        first: 20,
        after: endCursor
      });

      const publishedSeries = data.publication.series;
      if (!publishedSeries) return null;

      // Persist metadata on the first run
      if (!seriesMeta) {
        const { posts, ...metaRest } = publishedSeries;
        seriesMeta = metaRest;
      }

      const posts = publishedSeries.posts;
      allPosts = allPosts.concat(posts.edges.map((e: any) => e.node));

      hasNextPage = posts.pageInfo.hasNextPage;
      endCursor = posts.pageInfo.endCursor;
    }

    // 2. Here's the magic trick. Reverse the array so Newest is First.
    seriesPostsCache[slug] = allPosts.reverse();
    if (seriesMeta) {
      seriesMetaCache[slug] = seriesMeta;
    }
  }

  // 3. Grab from cache
  const allPosts = seriesPostsCache[slug];
  const seriesMeta = seriesMetaCache[slug];
  if (!seriesMeta) return null;

  // 4. Implement local slicing based on the provided cursors
  const startIndex = after ? allPosts.findIndex(p => p.slug === after) + 1 : 0;

  // Safety net in case of invalid cursor
  const validStartIndex = startIndex > 0 ? startIndex : (after ? allPosts.length : 0);

  const slice = allPosts.slice(validStartIndex, validStartIndex + first);
  const nextHasNextPage = validStartIndex + first < allPosts.length;

  // Set the newest 'endCursor' for the client to use on consecutive requests
  const newEndCursor = slice.length > 0 ? slice[slice.length - 1].slug : null;

  // 5. Structure exactly how the calling React component expects
  return {
    series: {
      ...seriesMeta,
      posts: {
        edges: slice.map(node => ({ node })),
        pageInfo: {
          endCursor: newEndCursor || '',
          hasNextPage: nextHasNextPage
        }
      }
    } as any
  };
}

Why this approach is awesome:

Zero UI Adjustments: The React component responsible for consuming the posts (SeriesPage.tsx) doesn’t even know this under-the-hood wizardry is occurring. It passes first and after standardly and receives seamless newest-first data.
Instant "Load More": Once the initial batch is traversed during while(hasNextPage), it acts exactly like an instant static array. Any subsequent "Load More" clicks don't hit the standard network stack; they instantly slice through seriesPostsCache in micro-seconds!
Overcoming GraphQL Limitations: Sometimes headless CMS or GraphQL servers (like Hashnode's otherwise fantastic API) restrict complex filtering or sorting on nested nodes purely for their own database performance. When you abstract that layer on your backend caching structure, you win full control back.

Now, whenever users visit the series pages in my portfolio, the most recently solved programming challenges are rightfully spotlighted at the very top. What's not to love about building digital experiences that slap?

Building a Seamless JWT Onboarding Flow with React Router v7 and Django

Vicente G. Reyes — Tue, 17 Mar 2026 10:47:36 +0000

Authentication and onboarding are often the highest-friction points in a new user's journey. If the process is clunky or requires too many redirects, users drop off. Recently, I set out to build a streamlined JWT authentication and onboarding flow using a modern stack: React Router v7 (with Vite), TypeScript, and Django REST Framework (DRF).

In this article, I'll walk through the architecture, the backend implementation, and how to handle protected routes securely on the client side.

The Architecture Stack

Here is what we are working with:

Backend: Django, Django REST Framework (DRF), and djangorestframework-simplejwt.
Frontend: React (via Vite) and the newly released React Router v7.
Styling: Tailwind CSS.
State Management: React Context API for lightweight auth state handling.

The Goal

A user registers.
The user logs in. They receive a short-lived access token and a refresh token.
The backend knows if the user has completed their profile setup (is_onboarded).
If they haven't onboarded, the backend middleware blocks API requests, and the frontend automatically reroutes them to the /onboarding page.
Once onboarded, new tokens are issued with the updated status, and the user gains full access to the application /.

1. Setting up the Django Backend

The Custom User Model

First, we need to track whether a user has finished setting up their profile. We extend Django's AbstractUser:

# users/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    is_onboarded = models.BooleanField(default=False)

Customizing the JWT Payload

By default, SimpleJWT only includes the user_id inside the token. We want the frontend to immediately know the user's name and onboarding status without making an extra API call.

# users/serializers.py
from rest_framework_simplejwt.serializers import TokenObtainPairSerializer

class MyTokenObtainPairSerializer(TokenObtainPairSerializer):
    @classmethod
    def get_token(cls, user):
        token = super().get_token(user)
        # Inject custom claims into the JWT payload
        token['is_onboarded'] = user.is_onboarded
        token['username'] = user.username
        return token

Enforcing Onboarding with Middleware

We want to strictly prevent un-onboarded users from accessing core application data. We do this via a custom Django middleware that intercepts requests.

# users/middleware.py
from django.http import JsonResponse
from django.urls import reverse

class OnboardingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Exempt authentication and onboarding endpoints
        exempt_urls = [reverse('token_obtain_pair'), '/api/onboard/submit/', '/api/register/']

        if request.path in exempt_urls or request.path.startswith('/admin/'):
            return self.get_response(request)

        user = request.user
        # Block access if authenticated but not onboarded
        if user.is_authenticated and not user.is_onboarded:
            return JsonResponse({
                "error": "ONBOARDING_REQUIRED",
                "message": "Please complete onboarding before accessing this resource."
            }, status=403)

        return self.get_response(request)

Now, even if a user tries to bypass the frontend routing, the API will refuse to serve them data!

Refreshing Tokens upon Onboarding

When the user submits the onboarding form, their status changes in the database. However, their physical JWT won't update automatically. We handle this by issuing completely new tokens in the onboarding response:

# users/views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status, permissions

class OnboardSubmitView(APIView):
    permission_classes = (permissions.IsAuthenticated,)

    def post(self, request):
        user = request.user
        if user.is_onboarded:
            return Response({"detail": "Already onboarded."}, status=400)

        user.is_onboarded = True
        user.save()

        # Generate fresh tokens reflecting the new state
        refresh = MyTokenObtainPairSerializer.get_token(user)

        return Response({
            "detail": "Onboarding complete.", 
            "is_onboarded": True,
            "access": str(refresh.access_token),
            "refresh": str(refresh)
        }, status=status.HTTP_200_OK)

2. Setting up the React Frontend

We spun up the frontend using React Router v7's built-in Vite template.

Bypassing CORS locally

To avoid CORS issues during development, we configured Vite to proxy /api requests to our Django dev server:

// vite.config.ts
import { defineConfig } from "vite";

export default defineConfig({
  // plugins...
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8000',
        changeOrigin: true,
      }
    }
  }
});

Global Authentication Context

We use React Context to provide user data (token, user payload, login, logout) globally.

A critical detail: Server-Side Rendering (SSR). React Router v7 utilizes SSR by default when hydrating the app. If you try to read localStorage.getItem('access_token') immediately on the server, Node.js will crash with a ReferenceError: localStorage is not defined.

We fix this by waiting for hydration on the client using a simple useEffect:

// app/contexts/AuthContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';

// ... interfaces and parseJwt helper ...

export function AuthProvider({ children }: { children: React.ReactNode }) {
  const [token, setToken] = useState<string | null>(null);
  const [isClient, setIsClient] = useState(false);

  // Safe SSR hydration
  useEffect(() => {
    setIsClient(true);
    setToken(typeof window !== "undefined" ? localStorage.getItem('access_token') : null);
  }, []);

  const user = token ? parseJwt(token) as UserPayload : null;

  useEffect(() => {
    if (token) localStorage.setItem('access_token', token);
    else localStorage.removeItem('access_token');
  }, [token]);

  const login = (access: string, refresh: string) => {
    localStorage.setItem('refresh_token', refresh);
    setToken(access);
  };

  if (!isClient) return null; // Prevent hydration mismatch

  return (
    <AuthContext.Provider value={{ token, user, login, logout, refreshAccessToken }}>
      {children}
    </AuthContext.Provider>
  );
}

Route Protection and Redirection

With our context in place, protecting routes and enforcing onboarding becomes incredibly simple. We intercept users in a useEffect on our page components.

Here is what our protected Home Dashboard looks like:

// app/routes/home.tsx
import { useEffect } from "react";
import { useNavigate } from "react-router";
import { useAuth } from "../contexts/AuthContext";

export default function Home() {
  const { token, user, logout } = useAuth();
  const navigate = useNavigate();

  useEffect(() => {
    if (!token) {
      navigate("/login");               // Kick out unauthenticated users
    } else if (user && !user.is_onboarded) {
      navigate("/onboarding");          // Kick out un-onboarded users
    }
  }, [token, user, navigate]);

  // Don't render until verified to prevent brief flashes of content
  if (!user || !user.is_onboarded) return null;

  return (
    <div>
      <h1>Welcome to your portal, {user.username}!</h1>
    </div>
  );
}

When the user is pushed to /onboarding, they hit our submit button. The API returns the new tokens, we update the context, and React Router instantly pushes them back to / seamlessly!

// Inside Onboarding component submit handler
const handleComplete = async () => {
  const res = await fetch("/api/onboard/submit/", {
    method: "POST",
    headers: { "Authorization": `Bearer ${token}` }
  });
  if (res.ok) {
    const data = await res.json();
    login(data.access, data.refresh); // Instantly updates global context
    navigate("/");                    // Redirect to dashboard
  }
};

Conclusion

By embedding the is_onboarded claim directly inside the JWT, we eliminate the need for the frontend to constantly ping the database to check a user's status. Coupling this tightly with Django Middleware ensures backend security, while utilizing React Context provides snappy, seamless redirects on the frontend.

Building auth doesn't have to be painful—with the right architecture, it can be safe, scalable, and a great experience for the end user.