Over the past few days, we noticed a strange spike in real-time traffic on <a target="_blank" rel="noopener noreferrer" href="https://swimstandards.com/">Swim Standards</a>. Most of it was coming from unusual locations — like Bayingolin Mongol Autonomous Prefecture and Jiaxing, China — places that aren’t exactly our core audience for U.S. swimming.<figure class="image"><img src="https://images.unsplash.com/photo-1485827404703-89b55fcc595e?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw0fHxib3R8ZW58MHx8fHwxNzU4ODI2NjIxfDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@agk42?utm_source=DNX&amp;utm_medium=referral">Alex Knight</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>At first, it looked like standard Google Analytics spam, but it turned out to be much more real — and much more annoying.<h2>🔍 Tracing the Source</h2>To investigate, I started by checking our Apache access logs directly on the server. I ran the logs through <code>iplocate</code> to get basic geoIP info to see just how much of our traffic was coming from &nbsp;different countries:<pre><code class="language-plaintext">#!/bin/bash

# Get timestamp 20 minutes ago
timestamp="$(date -d '20 minutes ago' '+%d/%b/%Y:%H:%M')"

# Temp file to hold filtered lines
TMP_LOG="/tmp/filtered_access.log.$$"
sudo awk -v d="$timestamp" '$0 ~ d,0' /var/log/apache2/other_vhosts_access.log &gt; "$TMP_LOG"

# Parse and classify
awk -F'"' '
function classify(ua) {
 if (ua ~ /Googlebot/) return "Googlebot"
 if (ua ~ /bingbot/) return "Bingbot"
 if (ua ~ /GPTBot/) return "GPTBot"
 if (ua ~ /MJ12bot/) return "MJ12bot"
 if (ua ~ /AhrefsBot/) return "AhrefsBot"
 if (ua ~ /MaxPointCrawler/) return "MaxPointCrawler"
 if (ua ~ /Cloudflare|cf-network/) return "Cloudflare"
 if (ua ~ /iPhone/) return "iPhone User"
 if (ua ~ /Android/) return "Android User"
 if (ua ~ /Macintosh|Windows NT|X11/) return "Browser"
 return "Unknown"
}
{
 split($1, a, " ")
 ip = a[2] # client IP is second column
 agent = $6
 label = classify(agent)
 print ip " | " label
}' "$TMP_LOG" | sort | uniq -c | sort -nr | head -50 | while read count ip pipe label; do
 country=$(geoiplookup "$ip" 2&gt;/dev/null | awk -F: '{print $2}' | xargs)
 echo "$count | $ip | $label | $country"
done

# Cleanup
rm -f "$TMP_LOG"</code></pre>It quickly became clear: a huge chunk of traffic was coming from Chinese IPs, and not from real users. They were hitting all types of pages — not just rankings — and many of the requests were being made by Sogou's bot, among others.<h2>🌐 Blocking at the Edge</h2>Once I confirmed it wasn’t ghost spam (it was hitting our actual server), I turned to Cloudflare. Since we’re using the free plan, I set up a basic firewall rule to block all traffic from China:<pre><code class="language-plaintext">Field: ip.geoip.country
Operator: equals
Value: CN
Action: Challenge</code></pre>After activating the rule, the impact was immediate:Real-time GA4 traffic droppedCities like Jiaxing and Bayingolin disappeared from the feedSuspicious pageviews and scroll events stopped firingThis confirmed what I suspected — it was non-human bot traffic, hammering the site and triggering engagement events in GA4.<h2>🤖 What Were These Bots Doing?</h2>From what I can tell, it wasn’t ad fraud or brute-force crawling of specific endpoints. It looked more like generic web scraping:Crawlers hitting public pages to index swimmer data, times, and resultsPossibly collecting full-page HTML to republish or analyze elsewhereIgnoring <code>robots.txt</code>, or at least not respecting itSogou’s crawler in particular is known for being overly aggressive, and it was responsible for a noticeable percentage of these requests.<h2>📉 Why It Matters</h2>Even though this traffic wasn’t actively attacking anything, it was:Skewing our analytics (engagement time, scroll depth, session count)Possibly inflating ad impressions (which can trigger invalid traffic flags)Wasting server resources on non-human visitsIn other words, it wasn’t malicious — but it wasn’t helpful either.<h2>✅ The Fix (So Far)</h2>Here’s what I’ve done:Blocked all traffic from China using Cloudflare firewall rulesIdentified Sogou bot as a major culpritVerified the drop in GA4 traffic after blockingThere’s no need to overcomplicate this with bot score thresholds or headless browser detection. In this case, a simple country block solved the problem.<h2>🧠 Takeaways</h2>If you’re seeing weird cities in GA4 Realtime (like Bayingolin or Jiaxing), it’s probably real bot traffic, not GA spoofing.Use your Apache/Nginx logs + geoIP lookup to confirm.Cloudflare’s free firewall rules are good enough for most bot filtering use cases.Don’t assume “page_view” and “scroll” in GA4 mean human — bots can trigger them too.I’ll keep monitoring for new patterns, but for now, blocking China has dramatically cleaned up our metrics and reduced unnecessary load on the server.If you're running a site and seeing similar anomalies, don’t ignore them — even if it’s just bots, they can mess with your data and slow down your site.

We discovered a spike in GA4 real-time traffic coming from unusual locations in China, including Jiaxing and Bayingolin. After checking Apache logs and running IP lookups, we confirmed that this was real bot traffic — mostly from Sogou — hitting all types of pages and triggering GA4 events. We blocked the traffic using a simple Cloudflare firewall rule by country (CN), which immediately cleaned up our analytics and reduced server load. No need for advanced detection — the country block was enough.

🕵️ Investigating Suspicious Bot Traffic

When you start adding SSO providers, JWTs, or large cookies to your web stack, you’ll eventually hit a frustrating error:<pre><code class="language-plaintext">400 Bad Request – Request Header Or Cookie Too Large
431 Request Header Fields Too Large
502 Bad Gateway – upstream sent too big header</code></pre>These errors are not random—they happen because web servers like Apache and Nginx enforce limits on HTTP header size. Let’s break down the defaults, how to tune them, and why you should resist the temptation to set them “infinitely large.”<figure class="image"><img src="https://images.unsplash.com/photo-1472289065668-ce650ac443d2?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxoZWFkZXJ8ZW58MHx8fHwxNzU3NzczODc5fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@joannakosinska?utm_source=DNX&amp;utm_medium=referral">Joanna Kosinska</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>Why header size matters</h2>Cookies: Each cookie can be up to ~4 KB. Multiply that by multiple cookies and you can easily exceed 8 KB.JWTs / OAuth tokens: A single token can be &gt;10 KB.Reverse proxies: You not only care about incoming request headers (from browsers) but also response headers (from your app), especially if your app sets big <code>Set-Cookie</code> values.If the server’s buffer is too small, it rejects the request/response with 400/431/502 errors.<h2>Nginx defaults vs tuning</h2>Defaults (64-bit builds):<pre><code class="language-plaintext">client_header_buffer_size 1k;
large_client_header_buffers 4 16k;
proxy_buffer_size 8k;
proxy_buffers 8 8k;
proxy_busy_buffers_size 16k;
http2_max_field_size 16k;
http2_max_header_size 64k;</code></pre>Request side: A single header line can only be 1k, and the total request headers 64 KB.Response side: A single upstream response header can’t exceed 8 KB.Common tuning (for Auth0, SSO, large cookies):<pre><code class="language-plaintext"># Requests (client → Nginx)
client_header_buffer_size 64k;
large_client_header_buffers 16 64k;

# Responses (upstream → Nginx)
proxy_buffer_size 16k;
proxy_buffers 8 16k;
proxy_busy_buffers_size 32k;

# HTTP/2 (mod_http2 in Nginx)
http2_max_field_size 32k;
http2_max_header_size 128k;
</code></pre>This raises both sides to handle bigger cookies and longer auth headers.<h2>Apache 2.4 defaults vs tuning</h2>HTTP/1.x defaults:<pre><code class="language-plaintext">LimitRequestFieldSize 8190 # ≈ 8 KB per header
LimitRequestLine 8190 # ≈ 8 KB for entire request line
LimitRequestFields 100 # max number of headers
</code></pre>HTTP/2 defaults (mod_http2):<pre><code class="language-plaintext">H2MaxHeaderListSize 65536 # 64 KB total headers</code></pre>Safe tuning for larger headers:<pre><code class="language-plaintext"># HTTP/1.x
LimitRequestFieldSize 16384
LimitRequestLine 16384

# HTTP/2
H2MaxHeaderListSize 131072 # 128 KB
</code></pre><h2>Why not set these “too large”?</h2>It might be tempting to set everything to 512 KB or 1 MB “just in case.” But that creates problems:Memory pressure: Apache and Nginx allocate buffers per connection. Large settings × many concurrent connections = wasted RAM.DoS surface: Attackers can exploit large headers to tie up server resources.Real-world limits: Browsers themselves rarely send &gt;16 KB per cookie header. Most apps don’t need more than ~128 KB total.The sweet spot is 16 KB per header and 128 KB total for HTTP/2—large enough for SSO tokens, but not so large that you waste memory.<h2>Troubleshooting checklist</h2>Seeing 400 Bad Request? → Raise <code>client_header_buffer_size</code> / <code>large_client_header_buffers</code> (Nginx) or <code>LimitRequestFieldSize</code> (Apache).Seeing 431 Request Header Fields Too Large (HTTP/2)? → Raise <code>http2_max_header_size</code> (Nginx) or <code>H2MaxHeaderListSize</code> (Apache).Seeing 502 upstream sent too big header? → Raise <code>proxy_buffer_size</code> (Nginx). Apache rarely needs this because it streams headers.<h2>TL;DR</h2>Nginx defaults are strict (1k per header line, 8k per response header). Tune both request and proxy buffers.Apache defaults are looser for HTTP/2 (64 KB), but still only 8 KB per header for HTTP/1.Don’t overshoot—large buffers eat memory and open DoS risks.Recommended safe values:16 KB per header128 KB total for HTTP/2That’s enough for real-world cookies, JWTs, and SSO without bloating your servers.

Both Apache and Nginx enforce limits on HTTP header sizes to prevent abuse, which can trigger confusing 400/431/502 errors when apps use large cookies or JWTs; by default, Apache allows ~8 KB per header in HTTP/1.x and 64 KB total in HTTP/2, while Nginx defaults are even tighter (1 KB per header line, 8 KB response headers), so tuning directives like LimitRequestFieldSize, H2MaxHeaderListSize, client_header_buffer_size, and proxy_buffer_size is often necessary—but keep values reasonable (≈16 KB per header, 128 KB total) to balance real-world needs with memory efficiency and DoS protection.

Understanding HTTP Header Size Limits in Apache and Nginx

<h2>The Mystery</h2>I recently ran into a baffling <code>next build</code> failure on a server where I colocated MongoDB, Next.js, and FeatherJS:<pre><code class="language-plaintext">EACCES: permission denied, scandir '/data/mongodb/diagnostic.data'</code></pre>At first, this made no sense. My code simply imported time standard files from:<pre><code class="language-plaintext">await import(`/data/${type}/${meet}-${year}.json`);</code></pre>This had worked flawlessly on other systems for years. So why the sudden failure?<figure class="image"><img src="https://images.unsplash.com/photo-1507139722691-cc2c94e3a2b2?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxNnx8cGF0aHxlbnwwfHx8fDE3NTcyMDM1MjF8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@adrientutinphoto?utm_source=DNX&amp;utm_medium=referral">Adrien Tutin</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>What Changed</h2>On the new server, I had installed MongoDB locally, and MongoDB had created this path:<pre><code class="language-plaintext">/data/mongodb/diagnostic.data
</code></pre>That was the difference. On all my previous systems, <code>/data/</code> didn't exist at all.<h2>The Illusion of Fallback</h2><blockquote>"If <code>/data</code> doesn't exist, does Node or Webpack fall back to <code>projectRoot/data</code>?"</blockquote>No, not officially. Node.js never does this.But Webpack (and therefore, Next.js) sometimes does something that looks like fallback, but is really its own path resolution logic:<blockquote>“Hmm, <code>/data/foo.json</code> — I don’t know that module, and it’s not in <code>node_modules</code>, and <code>/data</code> doesn’t exist on the host machine... But I see there's a <code>data/</code> folder in the project. Let me try that.”</blockquote>So Webpack resolves <code>/data/foo.json</code> as <code>projectRoot/data/foo.json</code>, and it just works — until you install something (like MongoDB) that creates a real <code>/data</code> directory on the OS.<h2>Why It Breaks</h2>Once <code>/data/</code> exists on the actual filesystem:Webpack tries to scan <code>/data/</code> as a real directoryIt hits <code>diagnostic.data/</code>, which is permission-protected<code>next build</code> crashes with <code>EACCES: permission denied</code><h2>The Correct Fix</h2>Always treat <code>/data/...</code> as off-limits unless you're intentionally targeting the root of the server. Use project-relative paths like this:<pre><code class="language-plaintext">import path from "path";
import fs from "fs/promises";

const filePath = path.resolve(
 process.cwd(),
 "data",
 type,
 `${meet}-${year}.json`
);

const fileContent = await fs.readFile(filePath, "utf-8");
const times = JSON.parse(fileContent);
</code></pre>This guarantees correct behavior regardless of what folders exist on the host system.<h2>Final Takeaway</h2>If you're using <code>/data/...</code> and it "works," it's likely only because:There's no real <code>/data/</code> directory on your OSWebpack defaulted to looking inside your project folderBut this is fragile behavior — and as soon as something like MongoDB creates a real <code>/data</code>, it breaks. Don't rely on this. Always resolve paths relative to your project.<blockquote>💡 Note to self: "Hmm, <code>/data/foo.json</code> — I don’t know that module, and it’s not in <code>node_modules</code>, and <code>/data</code> doesn’t exist on the host machine... But I see there’s a <code>data/</code> folder in the project. Let me try that."— That’s the mental model for how Webpack made this seem like it "just worked."</blockquote>

On systems without a real /data folder, using import('/data/xyz.json') in a Next.js project may appear to “just work” because Webpack quietly resolves the path to projectRoot/data/xyz.json during build, treating it as a module request rather than an absolute filesystem path. But this behavior is fragile — once a real /data directory exists on the server (e.g., from a MongoDB install), Webpack attempts to scan it, hits permission-protected system folders, and crashes the build with EACCES. The fix is to avoid absolute paths entirely and use path.resolve(process.cwd(), ...) to safely load project-local files.

⚡ Why /data/... Imports Worked on My Server — Until They Didn't

We refactored Favorites into a single, predictable React hook that works for both anonymous and verified users, avoids infinite re-renders, and keeps multiple tabs in sync — without peppering pages with ad-hoc effects.<figure class="image"><img src="https://images.unsplash.com/photo-1693575471707-be8bf2ccbc61?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw2MXx8ZmF2b3JpdGVzfGVufDB8fHx8MTc1NjUxMjI2Nnww&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@maryam_goli?utm_source=DNX&amp;utm_medium=referral">maryam Rad</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>What we needed</h2>Anonymous / unverified usersStore favorites in <code>localStorage</code> (limit 50)Cross-tab updates (changes in one tab appear in others)Verified usersStore favorites in the database (limit 200)Auto-fetch on login (once per user)Optimistic add/removeFirst-login one-way mergeLocal <code>localStorage</code> → account (handled elsewhere)Simple page APIPages shouldn’t do fetches or wire up listeners. They should just read <code>favorites</code> and render.<h2>The early issues</h2>Infinite re-render loop We initially wrote an effect like:<pre><code class="language-plaintext">useEffect(() =&gt; {
 (async () =&gt; {
 const list = await fetchRemoteFavorites(userSub);
 setRemoteFavs(list);
 })();
}, [userSub, remoteFavs]);
</code></pre>Including <code>remoteFavs</code> in the dependency array caused the effect to re-run every time we called <code>setRemoteFavs</code>, which called the effect again… → “Maximum update depth exceeded”.Overexposed API (<code>getFavorites</code>) We exported a <code>getFavorites()</code> function that sometimes fetched, sometimes read cache/local — and pages were calling it inside effects. That created dependency tangles and duplicated fetch logic.Cross-tab sync outside the hook We initially put a <code>storage</code> event listener in the page to refresh local favorites. That tied component code to storage mechanics and reintroduced dependency loops.<h2>The final design (simple + reliable)</h2><h3>1) Hook owns all side effects</h3>Fetch: The hook auto-fetches once per verified <code>userSub</code> inside <code>useEffect([userSub])</code>.Cross-tab sync: The hook listens to the <code>storage</code> event internally when not verified.Pages don’t fetch. They just read <code>favorites</code> and <code>loading</code>.<h3>2) Hide <code>getFavorites</code></h3>No more <code>getFavorites()</code>. Returning <code>favorites</code> directly from the hook makes the page a pure consumer — it just subscribes to updates by re-rendering.<h3>3) Use a “local count” to trigger re-renders</h3>For local users, writes to <code>localStorage</code> don’t automatically cause a React re-render. We increment a tiny state counter (<code>localVersion</code>) after local writes (and on <code>storage</code> events) to re-render the component tree. On the next render, the hook reads the latest <code>localStorage</code> and surfaces the new list.<blockquote>In other words, components subscribing to the hook’s state see updates without wiring their own listeners. (“Listening” in React is just re-rendering when the hook’s state changes.)</blockquote><h2>The hook (final)</h2><pre><code class="language-plaintext">/**
 * useFavorites
 * - Anonymous/unverified: localStorage (max 50), cross-tab via 'storage'
 * - Verified: DB, auto-fetch once per userSub, optimistic add/remove
 * - Returns: { favorites, loading, isFavorite, addFavorite, removeFavorite }
 */
import { useEffect, useState } from "react";
import { useUser } from "@auth0/nextjs-auth0/client";
import { queueAddFavorite, queueRemoveFavorite, fetchRemoteFavorites } from "../helpers/favoritesQueue";

const STORAGE_KEY = "SS-FAVORITES-V2";
const MAX_LOCAL = 50;

/* localStorage helpers */
function readLocal() {
 if (typeof window === "undefined") return [];
 try { return JSON.parse(localStorage.getItem(STORAGE_KEY) || "[]"); } catch { return []; }
}
function writeLocal(list) {
 if (typeof window === "undefined") return;
 try { localStorage.setItem(STORAGE_KEY, JSON.stringify(list)); } catch {}
}

export function useFavorites() {
 const { user } = useUser();
 const userSub = user?.email_verified ? user?.sub : null;

 // For verified users: null = loading, []|[...] = loaded
 const [remoteFavs, setRemoteFavs] = useState(null);
 // For local users: bump to force re-render after local writes or storage events
 const [localVersion, setLocalVersion] = useState(0);

 // Auto-fetch once per verified sub
 useEffect(() =&gt; {
 if (!userSub) {
 // Leaving verified state → clear once
 setRemoteFavs((prev) =&gt; (prev === null ? prev : null));
 return;
 }

 let alive = true;
 (async () =&gt; {
 try {
 const list = await fetchRemoteFavorites(userSub);
 if (alive) setRemoteFavs(Array.isArray(list) ? list : []);
 } catch {
 if (alive) setRemoteFavs([]);
 }
 })();

 return () =&gt; { alive = false; };
 }, [userSub]);

 // Cross-tab sync for local/unverified: bump to re-render and re-read localStorage
 useEffect(() =&gt; {
 if (userSub) return;
 const onStorage = (e) =&gt; {
 if (e.key === STORAGE_KEY) setLocalVersion((v) =&gt; v + 1);
 };
 window.addEventListener("storage", onStorage);
 return () =&gt; window.removeEventListener("storage", onStorage);
 }, [userSub]);

 // Derived outputs
 const loading = !!userSub &amp;&amp; remoteFavs === null;
 const favorites = userSub
 ? Array.isArray(remoteFavs) ? remoteFavs : []
 : readLocal(); // re-evaluated on each render; localVersion triggers re-render

 function isFavorite(id) {
 if (!id) return false;
 return Array.isArray(favorites) &amp;&amp; favorites.some((it) =&gt; it.id === id);
 }

 function addFavorite(item) {
 if (!item || !item.id) return;

 if (userSub) {
 // optimistic replace/prepend
 setRemoteFavs((prev) =&gt; {
 const base = Array.isArray(prev) ? prev : [];
 const filtered = base.filter((x) =&gt; x.id !== item.id);
 return [item, ...filtered];
 });
 queueAddFavorite(item, userSub); // fire-and-forget
 } else {
 const current = readLocal().filter((x) =&gt; x.id !== item.id);
 writeLocal([item, ...current].slice(0, MAX_LOCAL));
 setLocalVersion((v) =&gt; v + 1); // trigger re-render so subscribers update
 }
 }

 function removeFavorite(id) {
 if (!id) return;

 if (userSub) {
 setRemoteFavs((prev) =&gt; {
 const base = Array.isArray(prev) ? prev : [];
 return base.filter((x) =&gt; x.id !== id);
 });
 queueRemoveFavorite(id, userSub);
 } else {
 writeLocal(readLocal().filter((x) =&gt; x.id !== id));
 setLocalVersion((v) =&gt; v + 1); // trigger re-render so subscribers update
 }
 }

 return { favorites, loading, isFavorite, addFavorite, removeFavorite };
}
</code></pre><h2>Why this works</h2>No <code>getFavorites</code>: Pages don’t call into the hook to fetch or read snapshots. They just subscribe by destructuring <code>{ favorites, loading }</code>.No dependency loops: The only fetching effect depends solely on <code>userSub</code>, so <code>setRemoteFavs</code> doesn’t retrigger it.Cross-tab for free: The hook owns the <code>storage</code> listener; pages don’t wire up anything. When a change happens elsewhere, we bump <code>localVersion</code> to re-render and re-read <code>localStorage</code>.Optimistic UX: Adding/removing updates the in-memory state immediately for verified users, while the debounced queue writes to the server.<h2>Extra notes</h2>HTTP 201 vs 200: If your fetch endpoint is <code>POST /users/favorites</code>, a 201 Created response is expected. If you want read semantics, expose a <code>GET /users/favorites</code> that returns 200 OK.Alive guard: We keep a tiny <code>alive</code> flag to avoid “setState on unmounted” warnings if the user navigates away mid-fetch.Terminology: React components don’t “listen” in the traditional event sense — they re-render when the hook’s internal state changes. Thinking of it as “subscribing” to the hook’s state is a good mental model.

We built a unified useFavorites hook to handle both local and verified users: logged-out or unverified users store up to 50 favorites in localStorage (with cross-tab sync), while verified users get 200 favorites synced to the database with optimistic add/remove. Early versions had problems with infinite re-renders and over-complicated refs, but the fix was simple—limit the fetch effect to userSub changes and add a lightweight alive guard. The final hook is clean, predictable, and keeps UI updates instant while background queues handle persistence.

Building a Robust useFavorites Hook (and the bugs we fixed)

Over the course of implementing stricter API protection for a project using custom headers, Cloudflare, and Feathers.js, I went deep into how CORS, preflight requests, and custom headers work — and where performance can unexpectedly take a hit.This post summarizes what I learned.<figure class="image"><img src="https://images.unsplash.com/photo-1648461513491-c8dc79739211?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw3NHx8Y29yc3xlbnwwfHx8fDE3NTYzNDUwMDV8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@miguelalcantara?utm_source=DNX&amp;utm_medium=referral">Miguel Alcântara</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>✅ CORS and Preflight Basics</h2><h3>What triggers a preflight (OPTIONS) request?</h3>Any non-simple request will trigger a preflight. In my case:Cross-origin (main site calls a subdomain API)Uses <code>Content-Type: application/json</code>Uses custom headers like <code>ss-cleanup</code> or <code>x-dnxclient-id</code>Therefore, every request results in:An OPTIONS requestA full GET/POST request if preflight succeeds<h3>What’s a “simple request” (that avoids preflight)?</h3>Must satisfy:Method: <code>GET</code>, <code>POST</code>, or <code>HEAD</code>Content-Type: <code>application/x-www-form-urlencoded</code>, <code>multipart/form-data</code>, or <code>text/plain</code>No custom headers<h2>✅ Why My Requests Were Slower Than Expected</h2>My headers looked like this:<pre><code class="language-plaintext">headers: {
 "content-type": "application/json",
 "ss-cleanup": localStorage.getItem("SS-VENDOR_CLEANUP"),
 "x-dnxclient-id": generateNoise()
}
</code></pre>Which meant every fetch sent a preflight, costing ~100–300ms per request, even when calling between subdomains.<h2>✅ Cloudflare Rule to Block Bots</h2>To challenge non-browser bots, I used a custom header (<code>ss-cleanup</code>) that gets injected via real user interaction (mousedown, scroll, etc).Cloudflare rule:<pre><code class="language-plaintext">(starts_with(http.request.uri.path, "/dnxapi/meets")
 and not len(http.request.headers["ss-cleanup"]) &gt; 0
 and http.request.method ne "OPTIONS")
</code></pre><h3>✅ This works well:</h3>Does not block browser preflight requestsBlocks or challenges bots skipping JSCleanly integrates with your frontend<h2>✅ Safer CORS Setup in Feathers Backend (JUST IN CASE WE USE CORS)</h2><pre><code class="language-plaintext">const allowedOrigins = new Set([
 "https://example.com",
 "https://api.example.com",
 "https://community.example.com",
 "https://stg.example.com",
 "http://localhost:3000"
]);

app.use(cors({
 origin: function (origin, callback) {
 if (!origin || allowedOrigins.has(origin)) {
 callback(null, true);
 } else {
 callback(new Error("Not allowed by CORS"));
 }
 },
 credentials: true,
 allowedHeaders: [
 "Content-Type",
 "Authorization",
 "ss-cleanup", // Custom validation header
 "x-dnxclient-id" // Noise header to prevent silent failures
 ],
 maxAge: 600, // Cache preflight result for 10 minutes
}));</code></pre><h2>✅ Better Architecture: Proxy API Through Same Domain</h2>I migrated from:<pre><code class="language-plaintext">example.com (Next.js)
 ↘ fetch https://api.example.com</code></pre>To:<pre><code class="language-plaintext">example.com (Next.js + Apache)
 ↘ proxy /dnxapi/* → http://localhost:8888/*</code></pre><h3>🔥 Key Wins:</h3>✅ No more CORS preflight✅ No DNS lookup for subdomain✅ No cross-origin cookie issues✅ Faster + cleaner setup✅ Cloudflare security rules still work<pre><code class="language-plaintext">RewriteRule ^/dnxapi/(.*)$ http://localhost:8888/$1 [P,L]</code></pre><h2>📝 Notes &amp; Final Takeaways</h2>Access-Control-Max-Age is URL-specificPreflight result is cached per exact URL. Even a minor query change busts the cache.Changing to same-origin (via proxy) is the real fixRemoves CORS entirely – NO MORE PREFLIGHT!No DNS lookup.No cross-site concerns.Feels much faster.

Over the course of implementing stricter API protection for a project using custom headers, Cloudflare, and Feathers.js, I went deep into how CORS, preflight requests, and custom headers work — and where performance can unexpectedly take a hit.

🧠 Understanding CORS, Preflight, and Custom Headers in API Requests

<blockquote>CHECK OUT A BETTER SOLUTION: https://deniapps.com/blog/understanding-cors-preflight-and-custom-headers-in-api-requests</blockquote>For the longest time, I thought I understood how CORS worked — until I started building protections for my API (<code>api.swimstandards.com</code>) against scrapers, and everything broke.Turns out, I had some pretty common misconceptions about CORS, preflight, and what really happens when the browser talks to a backend. So here's what I learned — broken down simply, and hopefully useful for anyone building a secure API on a subdomain.<figure class="image"><img src="https://images.unsplash.com/photo-1609398852723-a2be68f9ac4c?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw0Nnx8Y29yc3xlbnwwfHx8fDE3NTYzMzg4MDh8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@cici9265?utm_source=DNX&amp;utm_medium=referral">Cici Hung</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>🔍 What Triggered It</h2>I wanted to block scrapers hitting my /protected-url<code>=...</code> API endpoint directly. So I added a custom header on real frontend clicks only, then used a Cloudflare rule to block any API calls that didn’t include this header.It worked — but then it broke for everyone else. Why?Because I didn't understand how CORS preflight works with custom headers and cross-origin requests.<h2>✅ What I Learned (and You Should Too)</h2><h3>1. CORS is required when origins differ — even on localhost</h3>If you're running:Frontend at <code>http://localhost:3000</code>API at <code>http://localhost:3333</code>Then even though it’s the same machine, the ports are different, so the origin is different, and CORS kicks in.<h3>2. Preflight happens when your request isn’t "simple"</h3>Browsers send a preflight <code>OPTIONS</code> request if:You set a custom header (like x-ss-header)You use <code>Content-Type: application/json</code>You use <code>credentials: include</code>You send any method other than <code>GET</code>, <code>POST</code>, <code>HEAD</code>And yes, even just setting <code>Content-Type: application/json</code> is enough to trigger preflight.<h3>3. Preflight can silently fail — and block your real request</h3>If the backend doesn't respond properly to the preflight, the browser will:Never send the real requestSilently fail with a CORS errorAnd Cloudflare will never even see that request, because it never left the browser.<h3>4. <code>app.use(cors())</code> allows everything by default</h3>When using the <code>cors</code> package in Express:<pre><code class="language-plaintext">app.use(cors());</code></pre>This allows:All origins (<code>*</code>)All headersAll methodsBut if you want control — or to use <code>credentials: true</code> — you need to specify origin(s) and headers explicitly.<h3>5. My actual working CORS config</h3>I now use this:<pre><code class="language-plaintext">const allowedOrigins = new Set([
 "https://mydomain.com",
 "https://api.mydomain.com",
 "http://localhost:3000", // local dev
]);

app.use(cors({
 origin: function (origin, callback) {
 if (!origin || allowedOrigins.has(origin)) {
 callback(null, true);
 } else {
 console.warn("❌ Blocked CORS origin:", origin);
 callback(new Error("Not allowed by CORS"));
 }
 },
 credentials: true,
 allowedHeaders: [
 "Content-Type",
 "Authorization",
 "x-my-token", 
 ],
 maxAge: 600, // ⏱️ cache preflight for 10 minutes
}));
</code></pre><h3>6. Cloudflare rules must skip <code>OPTIONS</code> requests</h3>I had a Cloudflare rule like this:<pre><code class="language-plaintext">starts_with(http.request.full_uri, "https://api.mydomain/protected") 
and not len(http.request.headers["x-my-token"]) &gt; 0</code></pre>But that triggered on preflight <code>OPTIONS</code> too — where no headers are sent yet!✅ The fix:<pre><code class="language-plaintext">http.request.method ne "OPTIONS" 
and starts_with(http.request.full_uri, "https://api.mydomain/protected") 
and not len(http.request.headers["x-my-token"]) &gt; 0</code></pre>This skips preflight, and only challenges real requests missing the custom header.<h3>7. I don’t need to whitelist browser headers</h3>I used to think I had to add <code>User-Agent</code>, <code>Accept</code>, <code>Sec-CH-UA</code>, etc. to <code>allowedHeaders</code>.❌ Not true.✅ You only need to list headers you manually set via JavaScript (<code>axios</code>, <code>fetch</code>, etc.)So in my case:<pre><code class="language-plaintext">options.headers = {
 "content-type": "application/json",
 "x-my-token": generateSecretToken(),
 ...(options.headers || {}),
};
</code></pre>Therefore my <code>allowedHeaders</code> only needs to match these.<h3>8. Preflight isn't free, but caching helps</h3>Every preflight request is an extra round trip, which slows down your app if done often.By setting:<pre><code class="language-plaintext">maxAge: 600</code></pre>the browser will cache the preflight for 10 minutes per origin/endpoint combo — which is a good balance.<h2>🧠 Final Thoughts</h2>Before this, I underestimated just how much cross-origin behavior is affected by headers, preflight, and server responses.Now I’ve:Secured my API with custom headersUsed Cloudflare rules to block scrapersLet real browsers through — smoothlyLearned how preflight works for realIf you’ve ever had your <code>fetch()</code> or <code>axios</code> request fail with weird CORS errors — I hope this post saves you hours of debugging.

After struggling with CORS and custom headers while trying to protect my API from scrapers, I finally learned how preflight requests work: any cross-origin request with a custom header or Content-Type: application/json triggers a preflight OPTIONS call. By default, app.use(cors()) allows everything, but to use custom headers and stricter origin checks, you need to configure origin, allowedHeaders, and optionally maxAge for better performance. Cloudflare rules must exclude OPTIONS requests, or they’ll break the preflight. Now, I use a custom header to verify real browser activity, and everything works reliably without blocking legitimate traffic.

How I Finally Understood CORS, Preflight, and Custom Headers (For Real)

Today I learned something important about how Apache and Nginx handle WebSocket upgrades.In Apache, it’s straightforward: you can use <code>RewriteCond %{HTTP:Upgrade} =websocket</code> to detect when a client is actually requesting a WebSocket. Only then do you forward with the <code>ws://</code> protocol and set the <code>Connection/Upgrade</code> headers. If the request is just plain HTTP, you skip all that and proxy normally. Clean separation.<figure class="image"><img src="https://images.unsplash.com/photo-1508920291026-c344bbfca1ab?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxzb2NrZXR8ZW58MHx8fHwxNzU1NzIyNTY3fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@nevenkrcmarek?utm_source=DNX&amp;utm_medium=referral">Neven Krcmarek</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>In Nginx, things work differently. If you follow common examples online, you’ll often see this in every location block:<pre><code class="language-plaintext">proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
</code></pre>The problem? That sends <code>Connection: upgrade</code> even for normal HTTP requests. If your upstream isn’t expecting it, you can end up with weird parsing issues. It’s like telling your backend “this is a WebSocket” when it really isn’t.The better approach in Nginx depends on your situation:If you don’t use WebSockets at all: Don’t set <code>Upgrade</code> or <code>Connection</code> headers anywhere. Just keep the proxy clean.If you use WebSockets only on a certain path: Put the <code>Upgrade/Connection</code> headers in a dedicated <code>location /ws/</code> block, and leave normal <code>location /</code> untouched.If you want to emulate Apache’s conditional logic everywhere: Use a <code>map</code> in <code>nginx.conf</code> to set <code>Connection</code> to <code>"upgrade"</code> only when <code>$http_upgrade</code> is present, otherwise <code>"close"</code>.Example:<pre><code class="language-plaintext">map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
}

location / {
 proxy_http_version 1.1;
 proxy_set_header Host $host;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 proxy_pass http://127.0.0.1:8082;
}
</code></pre><h3>Takeaway</h3>Apache makes it easy to branch on WebSocket vs. HTTP with <code>RewriteCond</code>. In Nginx, you either separate into different <code>location</code> blocks or use a <code>map</code>. And if you don’t need WebSockets at all, the cleanest solution is to drop the <code>Upgrade/Connection</code> headers entirely.Want me to also make a short one-paragraph version of this (like you did for the header-size blog)?

When handling WebSocket upgrades, Apache and Nginx take different approaches: Apache uses conditional rewrite rules to only send the Upgrade and Connection: upgrade headers when the client actually requests a WebSocket connection, keeping normal HTTP traffic clean and efficient. Nginx, on the other hand, often relies on always setting these headers in proxy configs, which can cause unnecessary overhead or even break normal requests if left unguarded. The key lesson is to handle upgrades conditionally—just like Apache does—so that WebSocket traffic is supported without polluting or disrupting standard HTTP traffic.

WebSocket Upgrade Handling: Apache vs. Nginx

Today I went down a rabbit hole chasing an error that only happened in one very specific setup:Desktop browsers → no issuesFirefox / Edge on mobile → no issuesChrome on mobile → constant 520 errors through CloudflareOn the surface, this looked random. Nginx logs weren’t showing the usual <code>request header too large</code> message, so it was easy to assume something else was broken (TLS key share, proxy headers, buffer settings, etc.). I tried changing proxy headers, adjusting Cloudflare rules, even toggling TLS quirks. Nothing fixed it.<figure class="image"><img src="https://images.unsplash.com/photo-1604307410297-081e0677d3fb?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxkZWJ1Z3xlbnwwfHx8fDE3NTU3MTQ3MzZ8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@nublson?utm_source=DNX&amp;utm_medium=referral">Nubelson Fernandes</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>What Was Really Happening</h2>It turned out to be huge HTTP request headers.Chrome mobile sends very fat headers after login redirects — especially with cookies + <code>sec-ch-ua</code> client hints. This combination was blowing past nginx’s default request header size.Why didn’t nginx log it? Because:With HTTP/1.1, nginx can return a 431 Request Header Fields Too Large and log it.With HTTP/2 (used by Cloudflare → origin), nginx sometimes drops the connection during header frame parsing, before it can even send a 431 or log an error. From my perspective it just showed up as <code>"-" 000</code> in access.log and a Cloudflare 520.That’s why I never saw a “too large header” error line, and why disabling the Cloudflare proxy (H1 direct) seemed to magically “fix” things.<h2>The Fix</h2>I raised the nginx header size limits:<pre><code class="language-plaintext">client_header_buffer_size 64k;
large_client_header_buffers 16 64k;
http2_max_field_size 32k;
http2_max_header_size 128k;
</code></pre>Once I did that, Chrome mobile + Cloudflare stopped failing.<h2>Key Lessons</h2>Modern web headers are big. Between tracking cookies, Auth0 state, and Chrome’s UA-Hints, it’s normal for requests to carry 10KB+ of headers.HTTP/2 hides the evidence. Oversized headers don’t always produce friendly nginx log messages. You may just see 000 status in access.log + Cloudflare 520.Incognito can behave differently. With fewer cookies, headers shrink, which explains why Chrome incognito “worked fine.”Cloudflare proxy can amplify issues. Direct-to-origin H1 requests might succeed, but Cloudflare’s H2 pipeline forces stricter frame parsing.Default limits are too small. Both nginx and Apache ship with conservative header limits that don’t always match the reality of modern apps.<h2>Takeaway</h2>If you ever run into Cloudflare 520s that happen only on Chrome mobile (but not desktop or other browsers), check your header sizes first. It might just be a “too big to log” header issue.

Ran into a weird issue where only Chrome on mobile (not desktop, Firefox, or Edge) kept throwing Cloudflare 520 errors after login redirects, with nginx logs showing nothing helpful. The root cause turned out to be oversized request headers (cookies + Chrome UA-Hints) that blew past nginx’s default limits; under HTTP/2 these just closed the connection silently, showing up as 000 in access.log. Fix was simply raising nginx’s header buffer limits, which solved it immediately. Lesson: modern apps produce very large headers, and if you see random 520s on Chrome mobile, check header sizes before chasing TLS or proxy ghosts.

Debugging a Chrome Mobile + Cloudflare 520 Mystery

Switching servers used to be one of my least favorite jobs.Every time I moved my website to a new machine, I had to:Reinstall or migrate Let’s Encrypt SSL certificatesUpdate DNS records in GoDaddy and wait for propagationHope I didn’t break something in the processIt was a headache.But now? I use Cloudflare, and server changes are painless.<figure class="image"><img src="https://images.unsplash.com/photo-1511013171551-dba2f391727a?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxMnx8Y2xvdWRmbGFyZXxlbnwwfHx8fDE3NTQ4Nzg5NTR8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@_visalliart?utm_source=DNX&amp;utm_medium=referral">Antonino Visalli</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>The Old Way: Painful &amp; Risky</h3>If you’ve ever done a server migration the “normal” way, you know the drill:Update your DNS A record at GoDaddy to point to the new IP.Wait for DNS propagation — which could take hours (or worse).Reinstall Let’s Encrypt SSL or move the cert over to the new server.Cross your fingers that nothing breaks in the middle of the change.<h3>The New Way: Cloudflare + Floating IPs</h3>Now, my setup looks like this:Visitor → Cloudflare → DigitalOcean Floating IP → Active ServerMy domain’s nameservers point to Cloudflare, not GoDaddy.Cloudflare proxies all traffic, so visitors never hit my server directly.I use a Floating IP from DigitalOcean (stable IP that can be reassigned to any server).When I move my site to a new droplet:I simply reassign the Floating IP in DigitalOcean.Cloudflare keeps pointing to the same IP.My SSL certificate is Cloudflare-managed, so I don’t have to reinstall anything.No DNS propagation delays. No SSL headaches. No downtime.<h3>Bonus: Cloudflare Handles SSL</h3>When you use Cloudflare’s proxy (orange cloud), they serve the SSL certificate. They might use Google Trust Services, Let’s Encrypt, or DigiCert — you don’t have to care. Browsers see Cloudflare’s certificate, and Cloudflare talks securely to your origin.Set SSL mode to Full (Strict) and install a free Cloudflare Origin Certificate on your server for end-to-end encryption.<h3>The Only Confusing Part: DNSSEC</h3>DNSSEC = DNS Security Extensions. It’s an extra layer of security at the DNS level, but here’s the catch: If your registrar (GoDaddy, in my case) has DNSSEC turned on, Cloudflare can’t take over your nameservers until you turn it off.At GoDaddy:DNSSEC is off by default (so you’re fine unless you manually enabled it).If you turn it on/off too many times, GoDaddy says you get a limited number of “credits” — I think they allow 5 free changes.<h3>TL;DR: Why I Love This Setup</h3>✅ No DNS propagation delays ✅ No SSL reinstall every time I move servers ✅ Easy failover with Floating IPs ✅ Better security (real server IP hidden) ✅ Free SSL with automatic renewalIf you manage multiple servers or like to experiment without risking downtime, Cloudflare + Floating IPs is the way to go.<h3>Updates (8/11/2025)</h3>Got it — here’s the updated blog post with your Cloudflare praise, but now including the origin SSL considerations and the two fix options we just discussed.<h2>How Cloudflare Made My Server Migrations a Breeze (Updated with SSL Notes)</h2>Adam C. | Aug 10, 2025Switching servers used to mean painful DNS changes, SSL reinstallations, and long propagation delays. But moving to Cloudflare has made the process nearly effortless. By pointing your domain to Cloudflare’s nameservers and enabling proxy mode, all traffic routes through Cloudflare before reaching your server—whether it’s a fixed IP or a DigitalOcean Floating IP—so you can swap servers without touching DNS at your registrar.The Hidden SSL Gotcha Cloudflare handles the public SSL certificate your visitors see, but it still needs to connect securely to your origin server. If you leave your origin with no valid SSL, Cloudflare’s “Full (Strict)” mode will fail, resulting in downtime. There are two good ways to fix this:Cloudflare Origin CertificatesFree, can last up to 15 years.Trusted by Cloudflare, not browsers.Perfect if your site is always proxied through Cloudflare.Let’s Encrypt Wildcard (DNS-01 validation)Free, fully browser-trusted, supports <code>*.yourdomain.com</code>.Works even if your A records still point to the old server (since validation uses TXT records in Cloudflare).Requires renewal every 90 days (can be automated).With one of these in place, you can migrate servers instantly — no SSL reinstall headaches, no DNS propagation delays, and no downtime.

Switching servers used to mean painful DNS changes, SSL reinstallations, and long propagation delays, but moving to Cloudflare has made the process nearly effortless. By pointing your domain to Cloudflare’s nameservers and enabling proxy mode, all traffic routes through Cloudflare before reaching your server—whether it’s a fixed IP or a DigitalOcean Floating IP—so you can swap servers without touching DNS at your registrar. SSL is handled automatically, and you avoid downtime or certificate headaches. 

How Cloudflare Made My Server Migrations a Breeze (Updated with SSL Notes)

When building a blog or content listing in Next.js, it's tempting to rely solely on client-side interactivity — such as a “Load More” button powered by JavaScript. But for Google SEO and crawlability, this alone isn't enough.<figure class="image"><img src="https://images.unsplash.com/photo-1716892001565-09a2d461982f?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxNXx8cGFnaW5hdGlvbiUyMGRlc2lnbnxlbnwwfHx8fDE3NTI4MDQ5MTl8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@unrealamol?utm_source=DNX&amp;utm_medium=referral">Amol Srivastava</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>In this post, we’ll walk through how to:Use a “Load More” button that saves posts to <code>localStorage</code> for better UX when navigating backFall back to traditional <code>&lt;Prev&gt;</code> / <code>&lt;Next&gt;</code> links when presenting a paginated view (e.g., <code>?page=3</code>)Ensure all links are visible to search engines by rendering <code>&lt;a href="..."&gt;</code> inside <code>&lt;Link&gt;</code><h3>💡 Why This Matters</h3>Search engines like Google don’t always execute JavaScript. So if your site loads more posts with just a button and no actual <code>&lt;a href&gt;</code> to another page, Google won’t crawl or index those additional pages.<blockquote>Good UX requires JavaScript. Good SEO requires HTML.</blockquote><h2>✅ Strategy Summary</h2>Page 1 starts with SSR-rendered initial posts.Clicking “Load More” loads more posts via API and appends them to the current list.All loaded posts are cached to <code>localStorage</code>.When viewing a post and hitting back, we restore from <code>localStorage</code> to avoid re-fetching.When visiting <code>?page=n</code> via a real URL, we show Prev / Next buttons as <code>&lt;a href&gt;</code> links.We render real <code>&lt;a&gt;</code> elements inside <code>&lt;Link&gt;</code>, so Google sees the next pages.<h2>🧱 Code Example (Blog Listing with SEO + UX)</h2><h3><code>pages/blog/index.js</code></h3><pre><code class="language-plaintext">import { useEffect, useState } from "react";
import { useRouter } from "next/router";
import Link from "next/link";
import { Segment, Button } from "semantic-ui-react";
import axios from "axios";

export default function BlogPage({ initialPosts, initialPage, initialShowMore }) {
 const router = useRouter();
 const [posts, setPosts] = useState(() =&gt; {
 if (typeof window !== "undefined") {
 const cached = localStorage.getItem("blogPosts");
 return cached ? JSON.parse(cached) : initialPosts;
 }
 return initialPosts;
 });
 const [currentPage, setCurrentPage] = useState(initialPage);
 const [showMore, setShowMore] = useState(initialShowMore);
 const [isLoading, setIsLoading] = useState(false);

 const isPaginatedView = !!router.query.page;

 useEffect(() =&gt; {
 // On mount, if paginated view, overwrite cache
 if (isPaginatedView) {
 localStorage.setItem("blogPosts", JSON.stringify(initialPosts));
 }
 }, [initialPosts, isPaginatedView]);

 const loadMore = async () =&gt; {
 setIsLoading(true);
 const nextPage = currentPage + 1;
 const res = await axios.get(`/api/posts?page=${nextPage}`);
 const newPosts = [...posts, ...res.data.posts];
 setPosts(newPosts);
 setCurrentPage(nextPage);
 setShowMore(res.data.hasMore);
 localStorage.setItem("blogPosts", JSON.stringify(newPosts));
 setIsLoading(false);
 router.replace("/blog"); // clean up ?page= after JS
 };

 const prevPage = currentPage &gt; 1 ? currentPage - 1 : null;
 const nextPage = currentPage + 1;

 return (
 &lt;div className="blog-wrapper"&gt;
 {posts.map((post) =&gt; (
 &lt;div key={post.id}&gt;
 &lt;h3&gt;
 &lt;Link href={`/blog/${post.slug}`}&gt;
 &lt;a&gt;{post.title}&lt;/a&gt;
 &lt;/Link&gt;
 &lt;/h3&gt;
 &lt;p&gt;{post.excerpt}&lt;/p&gt;
 &lt;/div&gt;
 ))}

 {!isPaginatedView &amp;&amp; showMore &amp;&amp; !isLoading &amp;&amp; (
 &lt;Segment textAlign="center"&gt;
 &lt;Link href={`/blog?page=${nextPage}`}&gt;
 &lt;a onClick={(e) =&gt; {
 e.preventDefault();
 loadMore();
 }}&gt;
 &lt;Button primary&gt;Load More&lt;/Button&gt;
 &lt;/a&gt;
 &lt;/Link&gt;
 &lt;/Segment&gt;
 )}

 {isPaginatedView &amp;&amp; (
 &lt;Segment textAlign="center"&gt;
 {prevPage &amp;&amp; (
 &lt;Link href={`/blog?page=${prevPage}`}&gt;
 &lt;a&gt;
 &lt;Button secondary&gt;Previous Page&lt;/Button&gt;
 &lt;/a&gt;
 &lt;/Link&gt;
 )}
 {showMore &amp;&amp; (
 &lt;Link href={`/blog?page=${nextPage}`}&gt;
 &lt;a&gt;
 &lt;Button secondary&gt;Next Page&lt;/Button&gt;
 &lt;/a&gt;
 &lt;/Link&gt;
 )}
 &lt;/Segment&gt;
 )}
 &lt;/div&gt;
 );
}
</code></pre><h3><code>getServerSideProps</code></h3><pre><code class="language-plaintext">export async function getServerSideProps(context) {
 const page = parseInt(context.query.page || "1", 10);
 const pageSize = 20;

 const res = await fetch(`https://yourdomain.com/api/posts?page=${page}`);
 const data = await res.json();

 return {
 props: {
 initialPosts: data.posts,
 initialPage: page,
 initialShowMore: data.hasMore,
 },
 };
}
</code></pre><h2>✅ Best Practices Summary</h2>✅ Use <code>&lt;Link&gt;&lt;a&gt;...&lt;/a&gt;&lt;/Link&gt;</code> for SEO — never wrap <code>&lt;Button&gt;</code> directly✅ Use <code>localStorage</code> to cache posts, improving the "Back" experience✅ SSR-render each page (<code>?page=n</code>) so crawlers can reach it✅ Avoid infinite loops in <code>useEffect</code> by keeping dependencies controlled✅ Use <code>router.replace('/blog')</code> to clean up query strings after <code>Load More</code><h2>🚫 A Common Mistake: Trusting Eslint Uncritically</h2>You might see a warning:<pre><code class="language-plaintext">React Hook useEffect has missing dependencies: 'initialPosts', 'currentPage', etc.</code></pre>Be careful: if you add all those as dependencies, you may accidentally cause infinite re-renders. It’s fine to intentionally ignore the warning in some scenarios where you’re controlling when updates should happen.<h2>Conclusion</h2>This hybrid approach gives you the best of both worlds:Instant “Load More” interactivity for usersCrawlable <code>&lt;Prev&gt;</code> / <code>&lt;Next&gt;</code> links for search enginesCached session state for great user experience when navigating backIt’s not magic — just careful balance between JavaScript UX and HTML SEO.Let me know if you want this packaged as a markdown post or published to your blog!

This pagination strategy combines great SEO and user experience by using real <a> links inside <Link> for Google to crawl paginated pages (?page=n), while also supporting a dynamic “Load More” button that appends posts via JavaScript and caches them in localStorage for fast navigation when users go back from a post. It ensures Google can discover all content through <Prev> and <Next> links, and users enjoy smooth interaction without losing previously loaded posts.

Building SEO-Friendly Blog Pagination with Load More and Next/Prev Links in Next.js

As someone who regularly juggles multiple branches and features, I thought I had a decent handle on Git. But today, I discovered a use case that blew my mind — and possibly saved my sanity.<figure class="image"><img src="https://images.unsplash.com/photo-1718936373260-ebf4346d0e62?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwyfHxzdGFzaHxlbnwwfHx8fDE3NTI4MDI3Mzl8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@jwing0220?utm_source=DNX&amp;utm_medium=referral">Amamiya Ryoichi</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>The Situation</h3>I was deep in the middle of building out an OAuth login flow on a feature branch (<code>with-auth0</code>). I had over 20 files either modified or untracked — not committed yet, because I was still experimenting and refining.Suddenly, I needed to jump to the <code>master</code> branch to apply a quick fix.But here’s the problem:I didn't want to commit my in-progress work (it wasn't ready).I didn't want to lose my visual diff in VSCode (or any editor).I definitely didn't want to copy files manually or reset anything.<h3>Enter: <code>git stash push -u -m "your message"</code></h3>I’d always thought of <code>git stash</code> as something for temporary experiments. But what I didn’t know was that you can safely stash everything — including untracked files — and then get it all back exactly as it was, diffs and all.Here’s the exact command that worked magic:<pre><code class="language-plaintext">git stash push -u -m "auth0 work-in-progress"</code></pre><code>-u</code> stashes untracked files (the new files I hadn’t added yet)<code>-m</code> lets me label the stash, so I know what it is laterAfter that, my working directory was clean. I could safely:<pre><code class="language-plaintext">git checkout master
# make my fix
git commit -am "Hotfix: ..."</code></pre>Then switch back:<pre><code class="language-plaintext">git checkout with-auth0
git stash pop</code></pre>And like magic — everything came back, exactly where I left off. My code editor still showed my in-progress changes, untracked files, and diffs. Nothing was lost, and I didn’t break my flow.<h3>Lesson Learned</h3>I used to think <code>git stash</code> was only for small tweaks or emergencies. But it turns out, it’s perfect for:Temporarily saving big, in-progress workKeeping track of both modified and untracked filesAvoiding commit noise or awkward “WIP” commitsPreserving your diffs so you don’t lose visual contextNow, I feel a lot more confident when switching between branches in the middle of messy development. This is one of those small Git tricks that’s going straight into my everyday toolkit.TL;DR: Need to jump branches but don't want to commit or lose untracked files and visual diffs? Use:<pre><code class="language-plaintext">git stash push -u -m "your work in progress"</code></pre>Then <code>stash pop</code> it back after you're done. It’s safe. It’s powerful. And I wish I’d known this sooner.

I recently discovered a powerful use case for git stash that completely changed how I handle mid-work context switching. While working on a large feature branch with over 20 modified and untracked files, I needed to switch to master to make a quick fix—without committing or losing my visual diffs. Using git stash push -u -m "message", I was able to safely stash everything, including untracked files, switch branches, make the fix, and then restore my exact working state with git stash pop. This simple Git trick preserved my flow, saved time, and is now part of my go-to workflow.

I Never Knew Git Stash Could Do This — A Game-Changer for Context Switching

If you're using a full-text search with MongoDB and filtering out soft-deleted or duplicate records using fields like <code>removed: { $exists: false }</code> and <code>dupSlug: { $exists: false }</code>, you might wonder: should I index those fields for performance?<figure class="image"><img src="https://images.unsplash.com/photo-1742975710558-1caf75cdbda2?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxMzJ8fGluZGV4fGVufDB8fHx8MTc1MTY2MDk0NXww&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@yanahd?utm_source=DNX&amp;utm_medium=referral">Allen Y</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>🚫 The Short Answer: No, you don't need to.</h3><h3>Why?</h3>MongoDB applies <code>$text</code> search first, using your defined text index (e.g., <code>SearchSwimmerByNameTeamLsc</code>). This is handled efficiently with <code>IXSCAN</code> and <code>TEXT_MATCH</code>.Filters like <code>removed</code> and <code>dupSlug</code> are applied later, during the <code>FETCH</code> stage. At that point:MongoDB has already narrowed down the candidates using the text index.It only needs to examine a small number of documents — for example, around ~2,865 in our case — which is very fast.Indexing <code>removed</code> or <code>dupSlug</code> won’t help, because:<code>$exists: false</code> conditions cannot use sparse indexes (they only work with <code>$exists: true</code>).MongoDB doesn't allow combining <code>$text</code> with other fields in compound indexes.You could create a partial index, but that only helps if you're querying those fields independently of text search.<h3>✅ Summary</h3>Your query is already efficient and does not require additional indexes on <code>removed</code> or <code>dupSlug</code>.Indexing them would add storage and write overhead with no gain in performance.Only consider indexing if:You start querying these fields without full-text search, orYou refactor your logic to use something like <code>isActive: true</code> (which is easier to index).Still seeing performance issues? You might benefit from replacing <code>$exists: false</code> with a flag field (<code>isDeleted</code>, <code>isDuplicate</code>) that defaults to <code>true</code> and can be indexed cleanly.Let me know if you want to explore that option or review your actual query plans.

If you're using a full-text search with MongoDB and filtering out soft-deleted or duplicate records using fields like removed: { $exists: false } and dupSlug: { $exists: false }, you might wonder: should I index those fields for performance?

🧠 Should You Index removed and dupSlug in MongoDB? Probably Not.

If you've ever worked with user-generated data (like swim meet names, usernames, or hashtags), you've likely run into this:<blockquote>A single long word with no spaces breaks your layout.</blockquote>For example:<pre><code class="language-plaintext">The2025NSCAgeGroupChampionshipsPresentedBySwimStandardsDotCom
</code></pre>This kind of string won't wrap naturally — and it might stretch your card, table, or even the entire mobile page.<figure class="image"><img src="https://images.unsplash.com/photo-1470241918028-bc2b588e1510?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxMDV8fGJyZWFrfGVufDB8fHx8MTc1MTY2MDc4NHww&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@elevatedtv?utm_source=DNX&amp;utm_medium=referral">Ryan Pohanic</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Let’s fix that.<h3>🧵 The Problem</h3>By default, browsers only break lines:at spaces,hyphens (<code>-</code>),or where language rules allow.So a long, space-free meet name inside a container like this:<pre><code class="language-html">&lt;div class="meet-name"&gt;
 The2025NSCAgeGroupChampionshipsPresentedBySwimStandardsDotCom
&lt;/div&gt;
</code></pre>...will overflow, stretch, or get clipped.<h3>✅ The Solution: <code>overflow-wrap: anywhere</code></h3>To make the string wrap even in the middle of a word, use:<pre><code class="language-css">.meet-name {
 overflow-wrap: anywhere;
 word-break: normal; /* optional, for clarity */
}
</code></pre><h3>🔍 Why This Works</h3><code>overflow-wrap: anywhere</code> tells the browser:<blockquote>"Wrap at normal places (like spaces) if possible, but if not, break wherever you must to avoid overflow."</blockquote>It won’t break every word unnecessarily — only when there's no good break point. So regular short names like <code>Summer Champs 2025</code> won’t be affected.<h3>🧪 Example</h3><h4>Before:</h4><pre><code class="language-css">.meet-name {
 overflow-wrap: normal;
}
</code></pre>Result: long name explodes the layout.<h4>After:</h4><pre><code class="language-css">.meet-name {
 overflow-wrap: anywhere;
}
</code></pre>Result: the long name breaks cleanly and respects the container width.<h3>📱 Mobile Friendly</h3>This is especially helpful for:mobile layouts with limited widthtables and cards where overflow ruins spacingsearch results with unpredictable meet names<h3>✨ Bonus Tip</h3>You can combine with:<pre><code class="language-css">white-space: pre-wrap;
</code></pre>If you want to respect line breaks (<code>\n</code>) and still wrap long text.<h3>🏁 Final Thoughts</h3>If your app handles swim meets, usernames, or imported data, you’re bound to hit long, space-free strings. Don’t let them break your UI — let CSS handle it smartly with:<pre><code class="language-css">overflow-wrap: anywhere;
</code></pre>It’s a small fix that saves big headaches.Let me know if you want this styled for your own site or turned into a reusable CSS class like <code>.wrap-anywhere</code>.

If you're dealing with long, unbreakable strings like swim meet names that have no spaces, overflow-wrap: anywhere is a simple CSS fix that ensures your layout stays intact. It tells the browser to break text at normal points first, but if no breaks are found, it will force a break anywhere to prevent overflow. This is especially useful for mobile layouts, tables, or cards where long names can otherwise stretch or break the design.

💥 How to Handle Long Meet Names with overflow-wrap: anywhere

For nearly three years, SwimStandards.com has quietly had a problem that I didn’t realize until recently: Googlebot was failing to crawl <code>www.swimstandards.com</code> due to an SSL error.<figure class="image"><img src="https://images.unsplash.com/photo-1614036417651-efe5912149d8?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw4NHx8Y2VydGlmaWNhdGV8ZW58MHx8fHwxNzUwNjMzNDUzfDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@brandsandpeople?utm_source=DNX&amp;utm_medium=referral">Brands&amp;People</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>I always assumed everything was working fine because:I only use <code>https://swimstandards.com</code>Google Search Console didn’t report any errors for the root domainI never intentionally promoted the <code>www</code> versionBut last week, I finally looked into a persistent “High fail rate” warning from Google Search Console — and I found the root cause.<h3>What Happened?</h3>When I first set up SSL using Let's Encrypt, I only issued a certificate for:<pre><code class="language-plaintext">swimstandards.com</code></pre>I didn’t realize that <code>www.swimstandards.com</code> was not included — and that matters.Googlebot (and some users) occasionally try the <code>www</code> version. Since the SSL certificate didn’t cover it, requests to <code>https://www.swimstandards.com</code> failed with a certificate mismatch, leading to crawl failures and potentially missed indexing.<h3>The Fix (Finally)</h3>I reissued the SSL certificate using Certbot with both domains:<pre><code class="language-plaintext">sudo certbot --apache -d swimstandards.com -d www.swimstandards.com</code></pre>This updated the certificate to include both:<pre><code class="language-plaintext">DNS:swimstandards.com
DNS:www.swimstandards.com</code></pre>I also added a redirect so that any requests to <code>www.swimstandards.com</code> get properly forwarded to the canonical root domain:<pre><code class="language-plaintext">https://swimstandards.com</code></pre><h3>Did This Affect SEO?</h3>Honestly — probably not much, but it's possible:Google favors a consistent, canonical domain structure.Failing SSL on <code>www</code> might have prevented some backlinks from being credited correctly.Googlebot crawl errors, even if minor, aren’t ideal over a long period.If there was any SEO impact, it was likely small, but avoidable.<h3>Lesson Learned</h3>If you're running a site:Always include both <code>domain.com</code> and <code>www.domain.com</code> when issuing your SSL certificate.Always set up proper redirects from the non-canonical domain.Use tools like <code>curl</code>, <code>openssl</code>, and <a target="_blank" rel="noopener noreferrer" href="https://www.ssllabs.com/ssltest/">SSL Labs</a> to test both versions.Check Search Console regularly — even warnings you think don’t matter.<h3>TL;DR</h3>For 3 years, <code>https://www.swimstandards.com</code> was broken due to an SSL oversight. I fixed it in 10 minutes — and I wish I had done it sooner.

For nearly three years, SwimStandards.com has quietly had a problem that I didn’t realize until recently: Googlebot was failing to crawl www.swimstandards.com due to an SSL error.
I always assumed everything was working fine because:
I only use https://swimstandards.com
Google Search Console didn’t report any errors for the root domain

Google Was Failing to Crawl My Site — Because My SSL Didn’t Cover www

To protect against server failure, data loss, or accidental changes, I’ve automated daily backups of my web app — including both the MongoDB database and NodeBB forum files — and synced them securely to Google Drive using <a target="_blank" rel="noopener noreferrer" href="https://rclone.org/"><code>rclone</code></a>.<figure class="image"><img src="https://images.unsplash.com/photo-1624895608078-e9f564cbe3fa?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw0fHxiYWNrJTIwdXB8ZW58MHx8fHwxNzQ5Nzc3Nzc4fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@siyuan_hu?utm_source=DNX&amp;utm_medium=referral">Siyuan Hu</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>🧰 Tools Used</h3>MongoDB for databaseNodeBB for forum data<code>mongodump</code> for database backup<code>rclone</code> to sync backups to Google Drive<code>cron</code> to automate the task<h3>📁 Backup Script</h3>Here’s the backup script I run every night at 2 AM:<pre><code class="language-plaintext">#!/bin/bash
source /home/adam/.mongodump.cnf # contains MONGODB_URI or credentials

BACKUP_DIR="/home/adam/backups"
TIMESTAMP=$(date +"%F-%H%M")
MONGO_BACKUP="$BACKUP_DIR/mongo/mongo-backup-$TIMESTAMP"
FILES_BACKUP="$BACKUP_DIR/nodebb-files/files-backup-$TIMESTAMP"

mkdir -p "$MONGO_BACKUP" "$FILES_BACKUP"

# Backup MongoDB
mongodump --out "$MONGO_BACKUP"

# Backup NodeBB uploads/configs/logs (customize as needed)
cp -r /home/adam/nodebb/public/uploads "$FILES_BACKUP/uploads"
cp -r /home/adam/nodebb/config.json "$FILES_BACKUP/config.json"
cp -r /home/adam/nodebb/logs "$FILES_BACKUP/logs"

# Clean up local backups older than 7 days
find "$BACKUP_DIR/mongo" -type d -mtime +7 -exec rm -rf {} \;
find "$BACKUP_DIR/nodebb-files" -type d -mtime +7 -exec rm -rf {} \;

# Sync to Google Drive
rclone sync "$BACKUP_DIR" gdrive:NodeBBBackups --delete-during</code></pre><h3>🔁 Set Up Cron Job</h3>To run the backup daily at 2:00 AM:<pre><code class="language-plaintext">crontab -e</code></pre>Add this line:<pre><code class="language-plaintext">0 2 * * * /home/adam/cron/backup.sh &gt;&gt; /home/adam/cron/backup.log 2&gt;&amp;1</code></pre><h3>☁️ Google Drive Setup with <code>rclone</code></h3>If you're starting from scratch:Install <code>rclone</code>:<pre><code class="language-plaintext">curl https://rclone.org/install.sh | sudo bash</code></pre>Configure a Google Drive remote:<pre><code class="language-plaintext">rclone config</code></pre>Choose <code>n</code> for new remoteName: <code>gdrive</code>Storage: <code>drive</code>Add your own client ID and secret from Google Cloud (optional but recommended)Use <code>rclone authorize</code> if configuring from a headless serverTest with:<pre><code class="language-plaintext">rclone lsd gdrive:</code></pre><h3>🔐 Tip: Keep Only the Latest Cloud Backup</h3>To avoid using excess space on Google Drive, the sync command:<pre><code class="language-plaintext">rclone sync "$BACKUP_DIR" gdrive:NodeBBBackups --delete-during</code></pre>ensures the remote backup mirrors your local backup folder — deleting outdated files automatically.<h3>✅ Automate It (Optional)</h3>You can create a cron job:<pre><code class="language-plaintext" id="PMqHxqcSi">0 2 * * * /usr/bin/rclone sync /home/adam/backups gdrive:NodeBBBackups --delete-during &gt;&gt; /var/log/rclone.log 2&gt;&amp;1
</code></pre>This syncs your backups daily at 2:00 AM.

To protect against server failure, data loss, or accidental changes, I’ve automated daily backups of my web app — including both the MongoDB database and NodeBB forum files — and synced them securely to Google Drive using rclone.

🔒 How I Back Up My Web App to Google Drive with rclone

If you're running a modern web app like Next.js, React, or Vue, you've probably noticed something strange in your AdSense dashboard:<blockquote>Page views are way lower than expected, but ad impressions seem fine.</blockquote>This isn’t a bug — it’s how AdSense works (or more accurately, how it doesn’t work with SPAs).<figure class="image"><img src="https://images.unsplash.com/photo-1451443700141-5ddb6d85a8fc?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw0N3x8U1BBfGVufDB8fHx8MTc0OTA4NzE1Mnww&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@shawneewilborn?utm_source=DNX&amp;utm_medium=referral">shawnee wilborn</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>What AdSense Actually Counts</h3><figure class="table"><table class="ui table celled"><thead><tr><th>Event</th><th>Counts AdSense Page View?</th><th>Counts Ad Impression?</th></tr></thead><tbody><tr><td>Full page reload (hard refresh)</td><td>✅ Yes</td><td>✅ Yes</td></tr><tr><td>SPA route change (no reload)</td><td>❌ No</td><td>✅ Yes (if ad is rendered with <code>push({})</code>)</td></tr></tbody></table></figure><h3>Why AdSense Page Views Are Misleading</h3>AdSense defines a page view as:<blockquote>A full page load where at least one ad is rendered.</blockquote>In SPAs, navigating between pages does not reload the page, so AdSense doesn't increment the page view counter — even if new content is shown and new ads appear.Meanwhile, each time an ad is rendered, it does count as an ad impression, whether or not the URL changed.<h3>The Real Mistake: Calling <code>adsbygoogle.push({})</code> After Route Change</h3>Many developers try this:<pre><code class="language-plaintext">router.events.on('routeChangeComplete', () =&gt; {
 (adsbygoogle = window.adsbygoogle || []).push({});
});
</code></pre>But this doesn't work reliably. Why?Because by the time that push runs, the <code>&lt;ins class="adsbygoogle"&gt;</code> tag might not yet be in the DOM. So nothing renders — no ad, no impression.<h3>✅ The Correct Way: Push Inside the Ad Unit</h3>You should call <code>adsbygoogle.push({})</code> inside your ad component, once it's mounted in the DOM.Here’s a React example:<pre><code class="language-plaintext">import { useEffect, useRef } from "react";

export default function AdUnit({ adClient, adSlot }) {
 const adRef = useRef(null);

 useEffect(() =&gt; {
 if (window.adsbygoogle &amp;&amp; adRef.current) {
 try {
 (window.adsbygoogle = window.adsbygoogle || []).push({});
 } catch (e) {
 console.error("AdSense push failed:", e);
 }
 }
 }, []);

 return (
 &lt;ins
 className="adsbygoogle"
 style={{ display: "block" }}
 data-ad-client={adClient}
 data-ad-slot={adSlot}
 data-ad-format="auto"
 data-full-width-responsive="true"
 ref={adRef}
 /&gt;
 );
}
</code></pre>This ensures:The container is in the DOMAdSense can properly render the unitAn ad impression is counted<h3>So What Should You Care About?</h3>If you're using a SPA, ignore AdSense page views. They are nearly meaningless.Focus on:Ad impressions (what actually earns you money)eCPM based on impressionsMaking sure your ads are visible and filledAnd yes — your AdSense page views will always be underreported unless the user refreshes the entire site.<h3>Final Thoughts</h3>SPAs broke the traditional pageview model years ago. Unfortunately, AdSense still hasn’t caught up. If you're relying on page view metrics to evaluate performance, you’re looking at a distorted picture.Use the metrics that matter: impressions and revenue. Just make sure your ad units mount correctly, push cleanly, and fill reliably.

If you're running a modern web app like Next.js, React, or Vue, you've probably noticed something strange in your AdSense dashboard:
Page views are way lower than expected, but ad impressions seem fine.
This isn’t a bug — it’s how AdSense works (or more accurately, how it doesn’t work with SPAs).

Why Google AdSense Page Views Are Broken on SPAs (and What Actually Counts)

On May 28, I analyzed one of my websites' traffic over 20 minutes to figure out whether my current 2-core setup was holding up — or holding me back. This is what I found.<figure class="image"><img src="https://images.unsplash.com/photo-1555617778-02518510b9fa?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw0NXx8Y29yZXxlbnwwfHx8fDE3NDg0ODA4ODF8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@christianw?utm_source=DNX&amp;utm_medium=referral">Christian Wiediger</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>🔍 Traffic Snapshot (20 Minutes)</h2>From <code>access_20min.log.txt</code>, I counted:~13,400 total requestsMany from bots: Googlebot, Bingbot, IASMany hits on SSR-heavy pages: <code>/swimmer/</code>, <code>/rankings/</code>, <code>/records/</code>That’s roughly:670 requests per minute11 requests per second<h2>📈 What a 2-Core VPS Can Usually Handle</h2>Under ideal conditions:~20–50 requests/sec (API or SSR)Assumes good caching, minimal disk I/O, responsive DBBut SwimStandards also:Uses Next.js SSR + Feathers.js APIRuns MongoDB aggregation per requestHandles bot load 24/7Shows socket hang up errors and TIME_WAIT spikes<h2>🧠 What That Means</h2>You're operating at the edge of stability for a 2-core server.Red flags:<code>socket hang up</code> during peak periods<code>TIME_WAIT</code> sometimes exceeds 300MongoDB slow logs show query latencyHigh I/O due to bot hits on uncached pages<h2>✅ Recommendations</h2><h3>1. Upgrade to a 4-core VPS if:</h3>You want margin for real traffic surgesYou want better SSR/API responsivenessYou want fewer 502/socket errors without blocking bots<h3>2. Not upgrading yet? Then:</h3>Move MongoDB to its own box (if not already)Use <code>pm2 scale feathers-dna 2</code> to add more backend workersEnable Redis or file-based cachingUse Cloudflare or NGINX with caching to protect SSR routes<h2>🧪 Commands I Used for Analysis</h2><h3>⏱️ View last 20 mins of top IP traffic</h3><pre><code class="language-plaintext">sudo awk -v d="$(date -d '20 minutes ago' '+%d/%b/%Y:%H:%M')" '$0 ~ d,0' /var/log/apache2/other_vhosts_access.log | awk '{print $2}' | sort | uniq -c | sort -nr | head -20</code></pre><h3>🗂️ Count Requests in Log</h3><pre><code class="language-plaintext">wc -l access_20min.log.txt</code></pre><h3>📊 Check Active Connections (443 port)</h3><pre><code class="language-plaintext">sudo netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c</code></pre><h3>🔍 Analyze top IPs hitting server (bot check)</h3><pre><code class="language-plaintext">sudo awk '{print $2}' /var/log/apache2/other_vhosts_access.log | sort | uniq -c | sort -nr | head -20</code></pre><h3>🔐 Watch Feathers &lt;-&gt; Next.js traffic (port 5052 example)</h3><pre><code class="language-plaintext">watch -n 1 "netstat -anp | grep :5052 | wc -l"</code></pre><h3>🔗 View connection state summary</h3><pre><code class="language-plaintext">sudo netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c</code></pre><h3>🧵 Check memory, swap, and load</h3><pre><code class="language-plaintext">free -m
uptime</code></pre><h3>🐢 Slow MongoDB queries (on DB server)</h3><pre><code class="language-plaintext">sudo grep -i "slow query" /var/log/mongodb/mongod.log | jq -c 'select(.attr.durationMillis &gt; 800)' &gt; slow.log</code></pre><h2>🧭 Final Thoughts</h2>If your site handles real-time rankings and dynamic pages like mine, a 2-core box can survive — but it won’t thrive. The more traffic (bot or not), the harder it gets to avoid dropped connections, long delays, and random SSR failures.For me, this test showed it’s time to move up — or keep scraping by with every tweak possible. UPDATE: 09/04/2025 When all numbers seem to be fine. Try this: Yep — that’s a common quick fix.When a Node app (like your <code>next-dna</code>) gets into a “stuck” state (memory leak, hanging DB query, event loop blocked, etc.), doing:<pre><code class="language-plaintext">pm2 restart &lt;process-name-or-id&gt;
</code></pre>will kill the existing process and spawn a fresh one.A few clarifications that might help you:<code>pm2 restart</code> vs <code>pm2 reload</code><code>restart</code>: full stop/start → clears memory, resets connections, resets workers. Useful when things are “stuck.”<code>reload</code>: zero-downtime hot reload (round-robin replacement of workers if in cluster mode). Good for deploying code changes, but it won’t always fix stuck states if the issue persists across workers.Cluster modeWith multiple instances, <code>pm2 restart</code> restarts all of them at once (brief downtime).<code>pm2 reload</code> replaces them one at a time (no downtime).Why restart “fixes” itYou’re effectively killing the bad process tree, flushing memory leaks, dangling handles, or zombie requests. If it happens often, it’s a symptom (memory leak, unclosed DB/socket, blocking CPU loop) — restart just hides the root cause.When to automateYou can configure:<pre><code class="language-plaintext">pm2 restart &lt;process&gt; --max-memory-restart 500M
</code></pre>to auto-restart when memory exceeds a threshold.Or use health checks (<code>pm2-runtime</code>, uptime monitoring, or a separate watchdog).

On May 28, I reviewed 20 minutes of live traffic logs from my website to evaluate whether my 2-core server could keep up with demand. The data showed over 13,000 requests — roughly 11 per second — with a mix of bot and real user traffic hitting SSR pages and API routes. While the server handled it, signs of strain appeared: spikes in TIME_WAIT, socket hang-up errors, and MongoDB lag. The conclusion? My setup is nearing its safe limits. Upgrading to 4 cores or offloading some processing (e.g., MongoDB or caching) may be necessary to maintain performance and stability as traffic grows.

Is My 2-Core Server Enough? Real Traffic Test & Recommendations

When deploying Node.js applications with PM2, it’s important to understand how cluster mode, instances, and CPU cores interact — especially when you’re combining multiple apps like a Next.js frontend and a Feathers.js backend.This post breaks down the core concepts and lessons learned from setting up <code>next-dna</code> and <code>feathers-dna</code> with PM2 cluster mode.<figure class="image"><img src="https://images.unsplash.com/photo-1635809337847-cc5e79a3969c?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwzNHx8Y2x1c3RlcnxlbnwwfHx8fDE3NDg0NjY2Nzl8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@acton_crawford?utm_source=DNX&amp;utm_medium=referral">Acton Crawford</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>🔧 1. Workers, Instances, Processes, and CPU Cores</h3>Instance in PM2 refers to a copy of your app.Worker is the actual process that runs an instance.Cluster mode allows PM2 to spawn multiple Node.js processes behind a single port using the built-in cluster module.Ideally, you run one instance per CPU core, so the workload is evenly distributed.You can check your available cores with:<pre><code class="language-plaintext">nproc
</code></pre>If you set:<pre><code class="language-plaintext">instances: "max"
</code></pre>PM2 will match your number of CPU cores.<h3>✅ 2. Cluster Mode with 1 Instance Is Still Valid</h3>Even if you only run 1 instance, using cluster mode still works — and may even be better than fork mode.Why?Cluster mode sets up a master process that manages workers.It keeps the option open to scale later without changing architecture.PM2 handles restarts and monitoring more cleanly in cluster mode.So yes — cluster mode with 1 instance is valid and sometimes preferable.<blockquote>⚠️ Important Note: Cluster mode with only 1 instance does not support true zero-downtime reloads. During a reload, that single worker must exit before a new one is started, resulting in a short downtime window (you may briefly see 503 errors). To enable zero-downtime reloads, you need at least 2 instances.</blockquote><h3>⚠️ 3. Multiple Instances on a Single Core</h3>You can run multiple instances on a single core — but you shouldn’t.What happens:The OS time-slices the CPU across all your workers.This leads to context switching, where the CPU keeps switching between processes.That can introduce latency and reduce throughput.It’s not catastrophic in small apps, but for production workloads, you’ll want at most one worker per core.<h3>🔥 4. More Instances Than CPU Cores = Stress</h3>If you go overboard (e.g., 4 workers on 2 cores):You’re not magically getting 4× performance.Instead, your app can become slower due to CPU thrashing.If your app is also I/O-bound (e.g., hitting a DB), performance may degrade even further.📌 Tip: Use <code>instances: os.cpus().length</code> or simply <code>instances: "max"</code> for optimal performance.<h3>🛠 5. Feathers.js + PM2 Cluster Needs Manual Tweak</h3>By default, if you naively start Feathers.js in cluster mode using:<pre><code class="language-plaintext">app.listen(port);
</code></pre>Each worker will try to bind to the same port — and crash with:<pre><code class="language-plaintext">EADDRINUSE: address already in use
</code></pre>You need to tweak your startup logic:<pre><code class="language-plaintext">const startServer = async () =&gt; {
 await app.setup();

 if (process.env.NODE_APP_INSTANCE === undefined || process.env.NODE_APP_INSTANCE === '0') {
 await app.listen(port);
 logger.info(`Feathers app listening on port ${port}`);
 } else {
 logger.info(`Worker ${process.env.NODE_APP_INSTANCE} initialized`);
 }
};

startServer();
</code></pre>This ensures only one worker binds to the port, and others are still initialized properly to handle requests routed by PM2.<h3>🧩 6. Matching Next.js and Feathers.js Instances Improves Stability</h3>If your frontend (Next.js) is running 2 instances, and your backend (Feathers.js) is only running 1 (e.g., fork mode):You may see errors like:<pre><code class="language-plaintext">socket hang up
</code></pre>Or long response delays, as the single Feathers.js worker becomes a bottleneck.Why?Next.js routes API calls to Feathers.js.If there are more frontend workers than backend, you’ll have idle frontend capacity, but backend saturation.💡 Matching instance counts between <code>next-dna</code> and <code>feathers-dna</code> reduces the risk of these issues.<h3>✅ Final Setup That Works Well</h3>After much testing, the following setup works stably:<pre><code class="language-plaintext">// pm2 config
instances: 1,
exec_mode: "cluster",
</code></pre>For both:<code>next-dna</code> (Next.js)<code>feathers-dna</code> (Feathers.js)This avoids port binding issues, avoids overloading CPU, and keeps things simple — while still using cluster mode for consistency and future scalability.<blockquote>🔁 For zero-downtime reloads, bump to <code>instances: 2</code> on both apps.</blockquote><h3>🚀 TL;DR</h3>✅ Use cluster mode, even for 1 instance — it’s cleaner.🧠 Match instances to CPU cores — don’t oversubscribe.⚙️ Feathers.js needs a startup guard for port binding.🔁 1 instance ≠ zero-downtime — for that, use 2+ instances.📶 Match instance counts between frontend and backend for stability.

When deploying Node.js applications with PM2, it’s important to understand how cluster mode, instances, and CPU cores interact — especially when you’re combining multiple apps like a Next.js frontend and a Feathers.js backend.

This post breaks down the core concepts and lessons learned from setting up next-dna and feathers-dna with PM2 cluster mode.

Understanding PM2 Cluster Mode with Feathers.js and Next.js

<blockquote>Besides the file-based caching causing high disk I/O, adjusting the <a target="_blank" rel="noopener noreferrer" href="https://deniapps.com/blog/understanding-pm2-cluster-mode-with-feathersjs-and-nextjs">PM2 configuration</a> appeared to be a key factor in resolving the socket hang-up issue.</blockquote>Starting on May 22, SwimStandards.com began experiencing major slowness — high server load, “socket hang up” errors in the Next.js logs, and sluggish API responses. The issue initially seemed to coincide with my integration of new ad scripts (specifically a CMP script added to the header), which I suspected might be blocking Next.js SSR and delaying downstream API calls. But even after removing the script, the issue returned — confirming it wasn’t the root cause.That kicked off a full-scale meltdown diagnosis and optimization effort. I:<ul><li>Tuned Axios timeout settings (from 10s to 30s),</li><li>Blocked abusive bots and IPs,</li><li>Investigated MongoDB slow queries and reviewed indexes,</li><li>Limited $skip usage in paginated queries,</li><li>Hid expensive features like team records,</li><li>Tweaked Apache settings (MaxConnectionsPerChild=1000, KeepAlive, etc.),</li><li>And tested persistent socket settings (keep-alive, agent pooling).</li></ul><figure class="image"><img src="https://images.unsplash.com/photo-1559484642-dab5f9c9653e?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxNXx8bWF5fGVufDB8fHx8MTc0ODIzMzkzMHww&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@sxtcxtc?utm_source=DNX&amp;utm_medium=referral">Sorin Gheorghita</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>But the actual root cause?I had enabled meet result caching on May 12 — which generated .json files into the .next/.cache folder using aggregation-heavy requests. These files quickly piled up (over 15,000), and because both bots and users accessed them constantly, the intense disk I/O (up to 5MB/s) crippled performance. Even when I trimmed the cache down to 1,000 files, the slowness persisted. The fix? I completely disabled the meet result cache — and everything immediately stabilized.Along the way, I also fixed a long-standing bug in the FeathersJS setModel logic and improved database hygiene. I now actively monitor MongoDB slow query logs, netstat, and system resource usage to stay ahead of future regressions.Below are all the shell commands and diagnostic tools I used throughout this painful but productive journey.<h3>✅ Server Load &amp; Traffic Debugging Checklist</h3><h3>1. 🔍 Check for suspicious or bot activity</h3>Look for bots targeting /.env or other known paths<pre><code class="language-css">sudo grep '/.env' /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head</code></pre>Check top IPs accessing any vhost<pre><code class="language-css">sudo awk '{print $2}' /var/log/apache2/other_vhosts_access.log | sort | uniq -c | sort -nr | head -10</code></pre>Check top IPs in the last 20 minutes<pre><code class="language-css">sudo awk -v d="$(date -d '20 minutes ago' '+%d/%b/%Y:%H:%M')" '$0 ~ d,0' /var/log/apache2/other_vhosts_access.log | awk '{print $2}' | sort | uniq -c | sort -nr | head -20</code></pre><h3>2. 🚫 Block abusive IPs using iptables</h3>List all existing rules with line numbers<pre><code class="language-css">sudo iptables -L INPUT -n --line-numbers</code></pre>Block IP<pre><code class="language-css">sudo iptables -I INPUT 1 -s &lt;IP_ADDRESS&gt; -j DROP</code></pre>Unblock IP<pre><code class="language-css">sudo iptables -D INPUT -s &lt;IP_ADDRESS&gt; -j DROP</code></pre><h3>3. 📊 Monitor PM2 logs and app errors</h3><pre><code class="language-css">pm2 logs # Real-time logs
pm2 status # Check memory/CPU per process</code></pre><h3>4. 🐢 Identify slow MongoDB queries (on DB server)</h3><pre><code class="language-css">sudo grep -i "slow query" /var/log/mongodb/mongod.log | jq -c 'select(.attr.durationMillis &gt; 800)' &gt; slow.log</code></pre><h3>5. 🌐 Monitor TCP socket load (Next.js &lt;-&gt; Feathers.js port)</h3><pre><code class="language-css">watch -n 1 "netstat -anp | grep :5052 | wc -l"</code></pre><h3>6. 🔗 Check HTTPS connection states</h3><pre><code class="language-css">sudo netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c</code></pre><h3>🔸 Healthy values (approximate):</h3><ul><li>ESTABLISHED: ~40–60</li><li>TIME_WAIT: &lt; 50 preferred (but up to ~100 is manageable)</li><li>SYN_RECV: ~200–300 is okay if from bots, but monitor for spikes</li></ul>&nbsp;

In late May, my website faced severe performance issues—high server load, 'socket hang up' errors, and slow responses. Initially, I suspected new ad scripts, but removing them didn’t help. After days of debugging—adjusting Axios timeouts, blocking bots, optimizing the database, and disabling heavy features—I found the root cause. This post shares the steps I took

May Meltdown Fixes: Every Command I Ran to Battle Website Slowness

I recently uncovered one of the most elusive bugs I've ever dealt with — and it had been quietly sitting in my codebase for over 3 years.<figure class="image"><img src="https://images.unsplash.com/photo-1523151594509-9d2e49774fec?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw3fHxidWd8ZW58MHx8fHwxNzQ4MjI0ODk5fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@davidclode?utm_source=DNX&amp;utm_medium=referral">David Clode</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>🔍 The Symptom</h3>Out of nowhere, MongoDB logs were showing slow queries against the wrong collections:<pre><code class="language-plaintext">ns: swimdb.strokes2324
query: { ageGroup: "13-14", ... }
</code></pre>But that didn’t make sense — this should have used the <code>best_strokes2324</code> collection.<h3>💡 The Suspicion</h3>My service uses a dynamic <code>setModel()</code> method to switch MongoDB collections based on query parameters. It looked fine:<pre><code class="language-plaintext">setModel = (collectionName) =&gt; {
 this.app.get("mongoClient").then((db) =&gt; {
 this.Model = db.collection(collectionName);
 });
};
</code></pre>And in the hook:<pre><code class="language-plaintext">await context.service.setModel("best_strokes2324");
</code></pre>Looks safe, right? 😅<h3>🧨 The Bug</h3>The <code>setModel()</code> function wasn’t returning anything — meaning that the <code>await</code> did absolutely nothing.Requests were racing ahead before the model was actually updated. As a result:Some queries hit the right collectionOthers hit a stale or incorrect oneAnd the worst part: it all looked fine most of the time<h3>🧠 The Fix</h3>One word: <code>async</code>.<pre><code class="language-plaintext">setModel = async (collectionName) =&gt; {
 const db = await this.app.get("mongoClient");
 this.Model = db.collection(collectionName);
};
</code></pre>Or if you still use <code>.then()</code>:<pre><code class="language-plaintext">setModel = (collectionName) =&gt;
 this.app.get("mongoClient").then((db) =&gt; {
 this.Model = db.collection(collectionName);
 });
</code></pre>Now <code>await setModel(...)</code> actually waits.<h3>🚦 What I Learned</h3>A missing <code>return</code> inside an async-like method can silently break everything.If your service state depends on timing, you must understand whether the mutation is blocking.MongoDB slow query logs are gold — they helped me trace the issue when nothing else would.<h3>🧠 Bonus: Why We Also Call <code>setModel()</code> in the <code>after</code> Hook</h3>You might wonder — if we already called <code>await setModel()</code> in the <code>before</code> hook, why call it again in the <code>after</code> hook?The answer is subtle but critical:<blockquote><code>context.service.Model</code> is shared across all requests. If another request comes in and sets a different model before our <code>after</code> hook runs, we could end up running queries against the wrong collection — even if we set it earlier.</blockquote>Feathers services are singletons. The model (<code>this.Model</code>) isn't scoped per request — it's global. But <code>context.params</code> is request-specific. So we store <code>season</code> in <code>context.params._season</code> during the <code>before</code> hook and re-call <code>setModel()</code> in the <code>after</code> hook, just before any late queries like <code>.distinct()</code>.That one extra line protects us from race conditions:<pre><code class="language-plaintext">await context.service.setModel("collection_prefix" + context.params._season);
</code></pre>This ensures the model is always correct at the time it’s needed — even if another user is hammering the server with overlapping requests. 🏁 ResultAfter the fix:No more inconsistent collectionsQuery times dropped dramaticallyConfidence restored

Just discovered a 3-year-old bug in my Feathers.js service: I was calling await setModel(...), but forgot to return a Promise inside setModel. The result? Queries sometimes hit the wrong MongoDB collection due to race conditions. It worked most of the time — until I checked the slow query logs. One missing return caused years of silent issues. Fixed now, and performance is back. Lesson learned.

All Posts