<blockquote><p><i><strong>Note</strong>: This post is auto-generated by ChatGPT based on my recent experience while trying to resolve the issue. The information here is for reference only and may not be entirely accurate. You are welcome to add your comments below.</i></p></blockquote><p>If you need to run a scheduled task on your Mac—even when it’s asleep—you’ll quickly find that <strong>cron</strong> doesn’t wake up the computer by itself. This post covers how to schedule a <strong>cron job at 7 AM on macOS</strong> and ensure it runs reliably, even if the Mac is sleeping.</p><figure class="image"><img src="https://images.unsplash.com/photo-1631885777506-69a414ca3735?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw4M3x8c2NoZWR1bGV8ZW58MHx8fHwxNzQxODk4NjU2fDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@mk__s?utm_source=DNX&amp;utm_medium=referral">mk. s</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p><strong>1️⃣ Setting Up a Cron Job</strong></p><p>macOS still supports <strong>cron</strong>, although Apple prefers <strong>launchd</strong> for scheduling tasks. To add a cron job, first, open <strong>Terminal</strong> and run:</p><pre><code class="language-css">crontab -e</code></pre><p>This will open your crontab file for editing. Add the following line to run a script at <strong>7:00 AM daily</strong>:</p><pre><code class="language-css">0 7 * * * /Users/adam/Projects/ss-db/restore.sh</code></pre><p>Make sure your script is <strong>executable</strong>:</p><pre><code class="language-css">chmod +x /Users/adam/Projects/ss-db/restore.sh</code></pre><p><strong>✅ Does Cron Run When the Mac is Asleep?</strong></p><p>No. If your Mac is <strong>asleep</strong> at 7 AM, <strong>cron will not run</strong>. It only executes jobs when the system is awake.</p><p><strong>2️⃣ Using pmset to Wake the Mac</strong></p><p>To ensure your Mac <strong>wakes up before running the cron job</strong>, schedule a wake event using:</p><pre><code class="language-css">sudo pmset schedule wakeorpoweron "07:00:00"</code></pre><p>This tells macOS to wake up at <strong>7:00 AM</strong> every day, ensuring that the cron job can run.</p><p><strong>Checking Scheduled Wake Events</strong></p><p>Verify the scheduled wake-up with:</p><pre><code class="language-css">pmset -g sched</code></pre><p><strong>3️⃣ Using launchd Instead of Cron</strong></p><p>Since macOS favors <strong>launchd</strong> over <strong>cron</strong>, another approach is to create a <strong>LaunchAgent</strong> or <strong>LaunchDaemon</strong>.</p><p><strong>Create a LaunchAgent (~/Library/LaunchAgents/com.adam.restoreDB.plist)</strong></p><p>1. Open Terminal and create the file:</p><pre><code class="language-css">nano ~/Library/LaunchAgents/com.adam.restoreDB.plist</code></pre><p>2. Add the following XML:</p><pre><code class="language-css">&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
    &lt;key&gt;Label&lt;/key&gt;
    &lt;string&gt;com.adam.restoreDB&lt;/string&gt;

    &lt;key&gt;ProgramArguments&lt;/key&gt;
    &lt;array&gt;
        &lt;string&gt;/Users/adam/Projects/ss-db/restore.sh&lt;/string&gt;
    &lt;/array&gt;

    &lt;key&gt;StartCalendarInterval&lt;/key&gt;
    &lt;dict&gt;
        &lt;key&gt;Hour&lt;/key&gt;
        &lt;integer&gt;7&lt;/integer&gt;
        &lt;key&gt;Minute&lt;/key&gt;
        &lt;integer&gt;0&lt;/integer&gt;
    &lt;/dict&gt;

    &lt;key&gt;WakeSystem&lt;/key&gt;
    &lt;true/&gt;
&lt;/dict&gt;
&lt;/plist&gt;</code></pre><p>3. <strong>Load the job</strong> into launchctl:</p><pre><code class="language-css">launchctl load ~/Library/LaunchAgents/com.adam.restoreDB.plist</code></pre><p>4. <strong>To run the job immediately:</strong></p><pre><code class="language-css">launchctl start com.adam.restoreDB</code></pre><p>5. <strong>To unload the job:</strong></p><pre><code class="language-css">launchctl unload ~/Library/LaunchAgents/com.adam.restoreDB.plist</code></pre><p><strong>✅ Why Use launchd?</strong></p><p>• It supports <strong>waking up the system</strong> (WakeSystem).</p><p>• It’s <strong>more reliable</strong> than cron on modern macOS versions.</p><p>• No need to manually set pmset wake timers.</p><p><strong>4️⃣ Checking Logs &amp; Debugging</strong></p><p>If the script doesn’t run:</p><p>1. <strong>Check cron logs:</strong></p><pre><code class="language-css">tail -f /var/log/system.log</code></pre><p>or:</p><pre><code class="language-css">grep cron /var/log/system.log</code></pre><p>2. <strong>Check LaunchAgent logs:</strong></p><pre><code class="language-css">log show --predicate 'subsystem == "com.apple.launchd"' --info --last 10m</code></pre><p>3. <strong>Manually test the script:</strong></p><pre><code class="language-css">/Users/adam/Projects/ss-db/restore.sh</code></pre><p><strong>📌 Final Thoughts</strong></p><p><strong>Which Method Should You Use?</strong></p><figure class="table"><table class="ui table celled"><thead><tr><th><strong>Feature</strong></th><th><strong>Cron</strong></th><th><strong>pmset + Cron</strong></th><th><strong>launchd</strong></th></tr></thead><tbody><tr><td>Runs on schedule</td><td>✅</td><td>✅</td><td>✅</td></tr><tr><td>Works if Mac is asleep</td><td>❌</td><td>✅</td><td>✅</td></tr><tr><td>Logs &amp; Debugging</td><td>Limited</td><td>Limited</td><td>Better</td></tr><tr><td>Apple-Recommended</td><td>❌</td><td>❌</td><td>✅</td></tr></tbody></table></figure><p>If your <strong>Mac is always awake at 7 AM</strong>, <strong>cron</strong> is enough.</p><p>If your <strong>Mac sleeps</strong>, use <strong>pmset + cron</strong> or <strong>launchd</strong>.</p><p>For <strong>Apple’s recommended approach</strong>, <strong>launchd is the best</strong>.</p><p><strong>🚀 TL;DR</strong></p><p>✅ <strong>To run a cron job at 7 AM, even if your Mac is asleep:</strong></p><p>• Use <strong>pmset</strong> to wake the Mac before execution.</p><p>• Or, use <strong>launchd</strong> (WakeSystem key) for a more reliable setup.</p><p>Got questions? Drop them in the comments! 🚀</p>

If you need to run a scheduled task on your Mac—even when it’s asleep—you’ll quickly find that cron doesn’t wake up the computer by itself. This post covers how to schedule a cron job at 7 AM on macOS and ensure it runs reliably, even if the Mac is sleeping.

 Scheduling a Cron Job on macOS with Wake Support

<p>Server performance is critical for any web application, but it’s common to encounter issues caused by factors like excessive log growth, abusive IP traffic, or internal requests. In this blog post, we’ll walk through a real-world example of addressing these issues and optimizing server performance.</p><figure class="image"><img src="https://images.unsplash.com/photo-1488779382325-da88fd3175e5?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw3OXx8cGVyZm9ybWFuY2V8ZW58MHx8fHwxNzM3MzIzODEwfDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@joehernandez?utm_source=DNX&amp;utm_medium=referral">Joe Hernandez</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2><strong>The Problem</strong></h2><h3><strong>1. Excessive Log Growth</strong></h3><p>The <code>other_vhosts_access.log</code> file was growing at an alarming rate, reaching hundreds of megabytes in a short span of time. This rapid growth was making it difficult to analyze logs and increasing disk I/O, potentially affecting overall server performance.</p><h3><strong>2. Abusive IP Traffic</strong></h3><p>A monitoring script revealed multiple IPs repeatedly generating requests resulting in <code>403 Forbidden</code> responses. These IPs seemed to be attempting to access unauthorized resources, putting unnecessary load on the server.</p><h3><strong>3. Internal Requests Flooding Logs</strong></h3><p>Internal requests (from private IPs) were also being logged, contributing significantly to the size of the log file. These requests were not useful for analysis but were consuming valuable resources.</p><h2><strong>The Solution</strong></h2><p>To address these issues, we took a series of targeted steps:</p><h3><strong>1. Handling Large Log Files</strong></h3><h4><strong>Analyzing Log Size</strong></h4><p>We started by analyzing the size and growth rate of the <code>other_vhosts_access.log</code> file using the following command:</p><pre><code class="language-css">wc -l /var/log/apache2/other_vhosts_access.log
</code></pre><p>This revealed tens of thousands of entries within minutes, highlighting the need for optimization.</p><h4><strong>Implementing Log Rotation</strong></h4><p>To prevent logs from growing indefinitely, we ensured <code>logrotate</code> was configured to rotate and compress logs:</p><pre><code class="language-css">cat /etc/logrotate.d/apache2
</code></pre><p>Example configuration:</p><pre><code class="language-plaintext">/var/log/apache2/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        systemctl reload apache2 &gt; /dev/null
    endscript
}
</code></pre><h3><strong>2. Blocking Abusive IPs</strong></h3><h4><strong>Identifying Abusive IPs</strong></h4><p>Using the monitoring script, we identified IPs generating repeated <code>403</code> requests:</p><pre><code class="language-css">awk '{print $1}' /var/log/apache2/other_vhosts_access.log | sort | uniq -c | sort -nr | head
</code></pre><h4><strong>Adding IPs to Firewall</strong></h4><p>To block these IPs, we used <code>iptables</code>:</p><pre><code class="language-css">sudo iptables -I INPUT 1 -s &lt;IP&gt; -j DROP
</code></pre><p>The <code>-I INPUT 1</code> ensures the rule is added at the top of the chain, so the traffic is blocked before further processing.</p><p>We verified the rules:</p><pre><code class="language-css">sudo iptables -L INPUT -n -v --line-numbers
</code></pre><h3><strong>3. Excluding Internal IPs from Logs</strong></h3><h4><strong>Updating Apache Configuration</strong></h4><p>Internal IPs like <code>10.x.x.x</code> and <code>127.0.0.1</code> were generating many log entries. To exclude them, we updated the Apache configuration:</p><pre><code class="language-css">SetEnvIf Remote_Addr ^10\. no_log
SetEnvIf Remote_Addr ^127\. no_log
SetEnvIf Remote_Addr ^192\.168\. no_log
SetEnvIf Remote_Addr ^172\.16\. no_log
CustomLog /var/log/apache2/other_vhosts_access.log combined env=!no_log
</code></pre><p>This configuration ensures requests from internal IPs are ignored in the logs.</p><h4><strong>Reloading Apache</strong></h4><p>We applied the changes by reloading Apache:</p><pre><code class="language-css">sudo systemctl reload apache2
</code></pre><h4><strong>Verifying the Results</strong></h4><p>After these changes, we monitored the logs:</p><pre><code class="language-css">grep '10\.' /var/log/apache2/other_vhosts_access.log | wc -l
</code></pre><p>Requests from internal IPs no longer appeared in the logs, significantly reducing their size.</p><h3><strong>4. Optimizing IP Blocking Rules</strong></h3><p>Adding a large number of individual IP blocking rules to <code>iptables</code> can potentially slow down performance, especially if your server processes a high volume of incoming traffic. Here’s a detailed explanation:</p><h4><strong>How iptables Processes Rules</strong></h4><ol><li><strong>Rule Evaluation:</strong><ul><li><code>iptables</code> evaluates rules sequentially, starting from the top of the chain.</li><li>For each incoming packet, it traverses the rules until a match is found or the packet reaches the default policy.</li></ul></li><li><strong>Impact of Many Rules:</strong><ul><li>As the number of rules increases, the time taken to evaluate each packet also increases.</li><li>If there are hundreds or thousands of <code>DROP</code> rules, each packet may take slightly longer to process, which can add up under heavy traffic.</li></ul></li></ol><h4><strong>When Does It Affect Performance?</strong></h4><ol><li><strong>Large Number of Rules:</strong><ul><li>Having hundreds or thousands of IP blocking rules can cause noticeable delays.</li><li>If you’re only adding a few dozen rules, the performance impact is negligible.</li></ul></li><li><strong>High Traffic Volume:</strong><ul><li>On a busy server with thousands of incoming requests per second, even small delays from rule evaluation can accumulate.</li></ul></li><li><strong>Resource Constraints:</strong><ul><li>On resource-limited servers (low CPU/memory), the overhead of processing many rules can become significant.</li></ul></li></ol><h4><strong>Solutions for Better Performance</strong></h4><p>If you need to block many IPs efficiently, consider these alternatives:</p><ol><li><strong>Use IP Sets</strong><ul><li>IP sets allow you to manage large groups of IPs efficiently. Instead of adding individual rules, you create an IP set and reference it in a single rule.</li><li><strong>Steps:</strong></li></ul></li></ol><p>Install <code>ipset</code> (if not already installed):</p><pre><code class="language-css">sudo apt install ipset
</code></pre><p>Create an IP set:</p><pre><code class="language-css">sudo ipset create blacklist hash:ip
</code></pre><p>Add IPs to the set:</p><pre><code class="language-css">sudo ipset add blacklist 47.128.111.209
sudo ipset add blacklist 47.128.39.234
sudo ipset add blacklist 111.225.148.31
sudo ipset add blacklist 110.249.201.41
sudo ipset add blacklist 111.225.148.17
</code></pre><p>Create an <code>iptables</code> rule to drop traffic from the IP set:</p><pre><code class="language-css">sudo iptables -I INPUT -m set --match-set blacklist src -j DROP
</code></pre><p>Save the rules:</p><pre><code class="language-css">sudo ipset save &gt; /etc/ipset.conf
sudo iptables-save &gt; /etc/iptables/rules.v4
</code></pre><ul><li><strong>Advantages:</strong><ul><li>The IP set is managed in memory, making it much faster.</li><li>Adding or removing IPs is efficient and doesn’t require modifying the <code>iptables</code> rules.</li></ul></li></ul><ol><li><strong>Use a Web Application Firewall (WAF):</strong><ul><li>A WAF like Cloudflare or AWS WAF can block abusive IPs before they reach your server.</li><li>These services can block entire regions or IP ranges with minimal performance impact.</li></ul></li><li><strong>Block by IP Range:</strong><ul><li>If abusive IPs come from a small number of IP ranges, block the entire range instead of individual IPs.</li></ul></li></ol><p>Example:</p><pre><code class="language-css">sudo iptables -I INPUT -s 111.225.148.0/24 -j DROP
</code></pre><h3><strong>Conclusion</strong></h3><ul><li><strong>A Few Dozen IP Rules:</strong> Won’t significantly affect performance.</li><li><strong>Many Rules (Hundreds/Thousands):</strong> Use <code>ipset</code> for better performance.</li><li><strong>High Traffic:</strong> Consider a WAF or rate-limiting to mitigate abuse efficiently.</li></ul><p>Let me know if you’d like help setting up <code>ipset</code> or exploring other options!</p><h2><strong>The Results</strong></h2><p>After implementing these solutions:</p><ul><li><strong>Log Growth Reduced</strong>: The <code>other_vhosts_access.log</code> file size was drastically reduced, making it easier to manage and analyze.</li><li><strong>Abusive Traffic Mitigated</strong>: Blocking abusive IPs reduced unnecessary load on the server.</li><li><strong>Improved Performance</strong>: Excluding internal IPs and reducing disk I/O improved overall server performance.</li></ul><h2><strong>Lessons Learned</strong></h2><ol><li><strong>Monitor Logs Regularly</strong>: Keep an eye on log growth to identify unusual traffic patterns early.</li><li><strong>Block Abusive IPs</strong>: Use tools like <code>iptables</code> to immediately block suspicious traffic.</li><li><strong>Optimize Logging</strong>: Exclude irrelevant requests, like internal traffic, from logs to reduce overhead.</li><li><strong>Automate with Scripts</strong>: Monitoring scripts can help detect and respond to issues faster.</li></ol><h2><strong>Conclusion</strong></h2><p>By addressing excessive log growth, blocking abusive traffic, and optimizing logging, we significantly improved server performance. These steps are essential for maintaining a healthy and efficient web application infrastructure.</p><p>If you’re facing similar issues, follow these strategies to optimize your server and keep your application running smoothly.</p>

Server performance is critical for any web application, but it’s common to encounter issues caused by factors like excessive log growth, abusive IP traffic, or internal requests. In this blog post, we’ll walk through a real-world example of addressing these issues and optimizing server performance.

Managing Apache Logs and Server Performance: A Real-World Case Study

<p>MongoDB's <code>find()</code> method is a powerful way to query multiple documents in PHP. However, the way you process the results can significantly impact the efficiency and readability of your code. This blog post explores two common approaches to handling the results of <code>find()</code> in PHP: using <code><strong>toArray()</strong></code> and iterating directly with <code><strong>foreach</strong></code>.</p><figure class="image"><img src="https://images.unsplash.com/photo-1693832581943-15b43d13f1b4?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwzMnx8Y29uZnVzaW9ufGVufDB8fHx8MTczNDczODQ5OHww&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@yogidan2012?utm_source=DNX&amp;utm_medium=referral">Daniele Levis Pelusi</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>The Basics: <code>find()</code></h2><p>The <code>find()</code> method in MongoDB returns a <strong>cursor</strong>, which is an iterable object that allows you to traverse through documents one by one. You can process the documents directly or convert the cursor into an array for batch processing.</p><h3>Example Query</h3><pre><code class="language-php">$cursor = $collection-&gt;find([
    'teamCode' =&gt; 'RMSC',
]);</code></pre><p>This retrieves all documents where <code>teamCode</code> is <code>'RMSC'</code>.</p><p>Now, let's explore the two methods of processing these results.</p><h2>Method 1: Using <code>toArray()</code></h2><p>The <code><strong>toArray()</strong></code> method converts the entire cursor into a PHP array. This is useful when you need all documents at once, such as passing them to a function or performing batch operations.</p><h3>Example</h3><pre><code class="language-php">$documents = $cursor-&gt;toArray(); // Converts the cursor into an array

foreach ($documents as $doc) {
    echo "Slug: " . $doc['slug'] . "\n";
}

// The documents array is reusable
print_r($documents);</code></pre><h3>Pros</h3><ul><li><strong>Convenience</strong>: All documents are immediately available as an array.</li><li><strong>Reusability</strong>: The resulting array can be passed to functions or processed multiple times.</li></ul><h3>Cons</h3><ul><li><strong>Memory Usage</strong>: Loads all documents into memory at once, which can be problematic for large datasets.</li><li><strong>Batch Processing Only</strong>: You lose the ability to process documents incrementally.</li></ul><h2>Method 2: Using <code>foreach</code> Directly on the Cursor</h2><p>Instead of converting the cursor, you can iterate over it directly using <code>foreach</code>. This streams documents one at a time from MongoDB, which is more memory-efficient for large datasets.</p><h3>Example</h3><pre><code class="language-php">foreach ($cursor as $doc) {
    echo "Slug: " . $doc['slug'] . "\n";
}</code></pre><h3>Pros</h3><ul><li><strong>Memory Efficiency</strong>: Only one document is loaded into memory at a time.</li><li><strong>Streaming</strong>: Ideal for processing large datasets incrementally.</li></ul><h3>Cons</h3><ul><li><strong>Single Use</strong>: Once a cursor is exhausted, it cannot be reused.</li><li><strong>Less Convenient for Arrays</strong>: If you need all documents in an array, you must manually build it.</li></ul><h3>Building an Array with <code>foreach</code></h3><pre><code class="language-php">$documents = [];
foreach ($cursor as $doc) {
    $documents[] = $doc;
}

// Now $documents contains all documents
print_r($documents);</code></pre><h2>Key Differences: <code>toArray()</code> vs <code>foreach</code></h2><figure class="table"><table class="ui table celled"><thead><tr><th>Feature</th><th><code>toArray()</code></th><th><code>foreach</code> on Cursor</th></tr></thead><tbody><tr><td>Memory Usage</td><td>High (loads all documents into memory)</td><td>Low (loads one document at a time)</td></tr><tr><td>Incremental Processing</td><td>❌</td><td>✅</td></tr><tr><td>Reusability</td><td>✅ Can reuse the resulting array</td><td>❌ Cursor is exhausted after iteration</td></tr><tr><td>Convenience</td><td>✅ Directly get all documents as an array</td><td>❌ Must manually build array if needed</td></tr></tbody></table></figure><h2>When to Use Each</h2><h3>Use <code>toArray()</code> When:</h3><ul><li>You are working with small datasets.</li><li>You need all documents at once (e.g., for batch operations).</li><li>You want the convenience of an array for reuse or passing to functions.</li></ul><h3>Use <code>foreach</code> on the Cursor When:</h3><ul><li>You are processing large datasets.</li><li>You want to keep memory usage low.</li><li>You are performing streaming or incremental processing.</li></ul><h2>Practical Example: A Function Requiring an Array</h2><p>Imagine you have a function that processes an array of documents:</p><pre><code class="language-php">function processDocuments(array $documents) {
    foreach ($documents as $doc) {
        echo $doc['slug'] . "\n";
    }
}</code></pre><h3>With <code>toArray()</code></h3><pre><code class="language-php">$documents = $cursor-&gt;toArray();
processDocuments($documents); // Directly pass the array</code></pre><h3>With <code>foreach</code></h3><pre><code class="language-php">$documents = [];
foreach ($cursor as $doc) {
    $documents[] = $doc; // Manually build the array
}
processDocuments($documents);</code></pre><h2>Conclusion</h2><p>Both <code>toArray()</code> and <code>foreach</code> on the cursor are valid ways to process results from MongoDB's <code>find()</code> method. The choice depends on your use case:</p><ul><li><strong>For small datasets and convenience</strong>, use <code>toArray()</code>.</li><li><strong>For large datasets and memory efficiency</strong>, use <code>foreach</code>.</li></ul><p>Understanding these differences can help you write more efficient and maintainable code. Happy coding!</p>

MongoDB's find() method is a powerful way to query multiple documents in PHP. However, the way you process the results can significantly impact the efficiency and readability of your code. This blog post explores two common approaches to handling the results of find() in PHP: using toArray() and iterating directly with foreach.

Exploring MongoDB's find() in PHP: toArray() vs foreach

<p>Working with MongoDB in PHP can be confusing, especially when it comes to the behavior of <code>findOne()</code> and how the results can be accessed. This blog post aims to clarify the nuances and help you avoid common pitfalls.</p><figure class="image"><img src="https://images.unsplash.com/photo-1505298537670-f32d119be330?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxNnx8Y29uZnVzaW9ufGVufDB8fHx8MTczNDczODQ5Mnww&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@mihaisurdu?utm_source=DNX&amp;utm_medium=referral">Mihai Surdu</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>The Basics: <code>findOne()</code> in PHP</h2><p>The <code>findOne()</code> method retrieves a single document from a MongoDB collection. By default, it returns a <code><strong>MongoDB\Model\BSONDocument</strong></code> object. This object supports:</p><ol><li><strong>Object-style access (</strong><code><strong>-&gt;</strong></code><strong>)</strong>: Access document properties like <code>$doc-&gt;key</code>.</li><li><strong>Array-style access (</strong><code><strong>['key']</strong></code><strong>)</strong>: Access properties like <code>$doc['key']</code>, because <code>BSONDocument</code> implements PHP's <code>ArrayAccess</code> interface.</li></ol><p>Here's a simple example:</p><pre><code class="language-php">$doc = $collection-&gt;findOne([
    'slug' =&gt; 'john-doe',
]);

if ($doc) {
    // Object-style access
    echo "Slug (object-style): " . $doc-&gt;slug . "\n";

    // Array-style access
    echo "Slug (array-style): " . $doc['slug'] . "\n";
} else {
    echo "No document found with slug 'john-doe'.\n";
}</code></pre><p>Both access styles work fine in this case. But what happens if you call <code>jsonSerialize()</code> or use the <code>typeMap</code> option?</p><h2>Using <code>jsonSerialize()</code></h2><p>Calling <code>jsonSerialize()</code> on a <code>BSONDocument</code> converts it into a <code><strong>stdClass</strong></code><strong> object</strong>, which only supports object-style access (<code>-&gt;</code>). Array-style access (<code>['key']</code>) will fail.</p><p>Here’s an example:</p><pre><code class="language-php">$serializedDoc = $doc-&gt;jsonSerialize();

// Object-style access works
echo "Slug (object-style): " . $serializedDoc-&gt;slug . "\n";

// Array-style access will fail
try {
    echo "Slug (array-style): " . $serializedDoc['slug'] . "\n";
} catch (Throwable $e) {
    echo "Error: " . $e-&gt;getMessage() . "\n";
}</code></pre><h3>Expected Output</h3><p>If the document exists:</p><pre><code class="language-css">Slug (object-style): john-doe
Error: Cannot use object of type stdClass as array</code></pre><p>This demonstrates that <code>jsonSerialize()</code> changes the access behavior.</p><h2>Enforcing Return Types with <code>typeMap</code></h2><p>You can use the <code>typeMap</code> option to control how <code>findOne()</code> returns the document. For example:</p><ol><li><strong>Return as an associative array</strong>:</li></ol><pre><code class="language-php">$doc = $collection-&gt;findOne([
    'slug' =&gt; 'john-doe',
], [
    'typeMap' =&gt; ['root' =&gt; 'array'],
]);

if ($doc) {
    // Array-style access works
    echo "Slug (array-style): " . $doc['slug'] . "\n";

    // Object-style access will fail
    try {
        echo "Slug (object-style): " . $doc-&gt;slug . "\n";
    } catch (Throwable $e) {
        echo "Error: " . $e-&gt;getMessage() . "\n";
    }
}</code></pre><ol><li><strong>Return as a PHP object</strong>:</li></ol><pre><code class="language-php">$doc = $collection-&gt;findOne([
    'slug' =&gt; 'john-doe',
], [
    'typeMap' =&gt; ['root' =&gt; 'object'],
]);

if ($doc) {
    // Object-style access works
    echo "Slug (object-style): " . $doc-&gt;slug . "\n";

    // Array-style access will fail
    try {
        echo "Slug (array-style): " . $doc['slug'] . "\n";
    } catch (Throwable $e) {
        echo "Error: " . $e-&gt;getMessage() . "\n";
    }
}</code></pre><h3>Key Takeaways</h3><ul><li><strong>Default behavior</strong>: <code>findOne()</code> returns a <code>BSONDocument</code>, supporting both access styles.</li><li><strong>With </strong><code><strong>jsonSerialize()</strong></code>: Converts to <code>stdClass</code>, breaking array-style access.</li><li><strong>With </strong><code><strong>typeMap</strong></code>:<ul><li><code>['root' =&gt; 'array']</code>: Returns an associative array, breaking object-style access.</li><li><code>['root' =&gt; 'object']</code>: Returns a PHP object, breaking array-style access.</li></ul></li></ul><h2>Conclusion</h2><p>MongoDB’s PHP driver offers flexibility in accessing documents, but it can be confusing due to the interplay of <code>BSONDocument</code>, <code>jsonSerialize()</code>, and <code>typeMap</code>. Here’s a quick summary:</p><figure class="table"><table class="ui table celled"><thead><tr><th>Access Type</th><th>Default (<code>BSONDocument</code>)</th><th>After <code>jsonSerialize()</code></th><th>With <code>typeMap =&gt; array</code></th><th>With <code>typeMap =&gt; object</code></th></tr></thead><tbody><tr><td>Object-style (<code>-&gt;</code>)</td><td>Works</td><td>Works</td><td>Fails</td><td>Works</td></tr><tr><td>Array-style (<code>[]</code>)</td><td>Works</td><td>Fails</td><td>Works</td><td>Fails</td></tr></tbody></table></figure><p>When working with <code>findOne()</code>, choose the method that best suits your needs and stick to it for consistency. Let me know if this post helps clarify the confusion!</p>

Working with MongoDB in PHP can be confusing, especially when it comes to the behavior of findOne() and how the results can be accessed. This blog post aims to clarify the nuances and help you avoid common pitfalls.

Understanding MongoDB's findOne() Behavior in PHP

<p>For a long time, I’ve been naming my shell scripts with the <code>.sh</code> extension and assuming they’d run just fine in any shell. Most of the time, they worked perfectly—but every now and then, I’d hit unexpected issues, especially when running them with <code>sh scriptName.sh</code>.</p><p>This got me thinking: <strong>Why do we even name our scripts </strong><code><strong>scriptName.sh</strong></code><strong>? Shouldn't it be </strong><code><strong>scriptName.bash</strong></code><strong> if it's written specifically for Bash?</strong></p><figure class="image"><img src="https://images.unsplash.com/photo-1475079385159-08c8fd87a2ed?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw5MHx8c2hlbGx8ZW58MHx8fHwxNzMyODA0NTIyfDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@lauren_abrahall?utm_source=DNX&amp;utm_medium=referral">Lauren</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 Shebang Problem</h3><p>Most of my scripts begin with a shebang like this:</p><pre><code class="language-css">#!/bin/bash</code></pre><p>This line ensures the script is executed with Bash when run directly, for example:</p><pre><code class="language-css">./scriptName.sh</code></pre><p>However, if I run the same script with:</p><pre><code class="language-css">sh scriptName.sh</code></pre><p>The shebang is completely ignored! Instead, the script is executed using <code>sh</code> (which might point to a more basic shell like <code>dash</code> on many systems). This often works fine—until the script relies on Bash-specific features.</p><h3>What Happens When <code>sh</code> Runs a Bash Script?</h3><p>Here’s an example of a script that breaks when run with <code>sh</code>:</p><pre><code class="language-css">#!/bin/bash
echo "Using Bash!"
my_array=(one two three)
echo "Second element: ${my_array[1]}"</code></pre><p><strong>Run with Bash (or Directly):</strong></p><pre><code class="language-css">./scriptName.sh</code></pre><p>Output:</p><pre><code class="language-css">Using Bash!
Second element: two</code></pre><p><strong>Run with </strong><code><strong>sh</strong></code><strong>:</strong></p><pre><code class="language-css">sh scriptName.sh</code></pre><p>Output:</p><pre><code class="language-css">Using Bash!
scriptName.sh: 3: scriptName.sh: Syntax error: "(" unexpected</code></pre><p>The error occurs because <code>sh</code> doesn’t support arrays or other Bash-specific features. This happens because the <code>sh</code> command forces the use of a simpler shell, completely ignoring the shebang.</p><h3>Why <code>.sh</code> Can Be Misleading</h3><p>Naming a script <code>scriptName.sh</code> implies it’s compatible with <code>sh</code> (or any POSIX-compliant shell). But if your script relies on Bash-specific features, this isn’t true. This mislabeling can confuse others—or even you—into running the script incorrectly.</p><h3>A Case for <code>.bash</code></h3><p>If a script depends on Bash, naming it with the <code>.bash</code> extension might be more accurate. For example:</p><pre><code class="language-css">scriptName.bash</code></pre><p>This naming convention immediately signals that the script is Bash-specific, reducing the likelihood of running it with <code>sh</code> by mistake.</p><h3>What I’ve Learned (and What I’ll Do Differently)</h3><ol><li><strong>Be Explicit with the Interpreter:</strong></li></ol><p>If my script starts with <code>#!/bin/bash</code>, I’ll always run it using Bash:</p><pre><code class="language-css">bash scriptName.sh</code></pre><ul><li>If a script is POSIX-compliant, I’ll test it with <code>sh</code> to ensure compatibility.</li></ul><ol><li><strong>Use the Shebang Correctly:</strong></li></ol><p>Make scripts executable and run them directly:</p><pre><code class="language-css">chmod +x scriptName.sh
./scriptName.sh</code></pre><ol><li><strong>Adopt Clear File Extensions:</strong><ul><li>Use <code>.sh</code> only for POSIX-compliant scripts.</li><li>Use <code>.bash</code> for scripts that rely on Bash-specific features.</li></ul></li><li><strong>Write Scripts with Compatibility in Mind:</strong><ul><li>If I expect the script to be run with <code>sh</code>, I’ll avoid Bash-only features like arrays or <code>[[ ]]</code>.</li><li>If it’s written for Bash, I’ll clearly document it and name it appropriately.</li></ul></li></ol><h3>Moving Forward</h3><p>Understanding the difference between <code>sh</code> and <code>bash</code> and how the shebang works has saved me a lot of frustration. Going forward, I’ll pay closer attention to how I name and run my scripts to ensure compatibility and clarity.</p><p>What about you? Have you ever run into similar issues with <code>.sh</code> scripts or interpreter mismatches? Let me know your thoughts—I’d love to hear your experiences!</p>

For a long time, I’ve been naming my shell scripts with the .sh extension and assuming they’d run just fine in any shell. Most of the time, they worked perfectly—but every now and then, I’d hit unexpected issues, especially when running them with sh scriptName.sh.

A Mistake I’ve Been Making for Years About .sh Scripts

<blockquote><p><strong>Note</strong>: This post is auto-generated by ChatGPT based on my recent experience while trying to resolve the issue. The information here is for reference only and may not be entirely accurate. You are welcome to add your comments below.</p></blockquote><p>Managing sitemaps is a critical component of ensuring that your website is crawled and indexed effectively by Google. However, submitting too many sitemaps or overwhelming Google’s crawlers can lead to delays, poor user experience, and frustrating errors like “Could not be fetched.” In this post, we'll explore best practices for optimizing sitemap submissions, managing Google’s crawl budget, and keeping your content indexed efficiently.</p><figure class="image"><img src="https://images.unsplash.com/photo-1452421822248-d4c2b47f0c81?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxzaXRlJTIwbWFwfGVufDB8fHx8MTcyNzYxNTE3N3ww&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@dariuszsankowski?utm_source=DNX&amp;utm_medium=referral">Dariusz Sankowski</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h4><strong>1. Why Sitemaps Matter for SEO</strong></h4><p>A sitemap is an XML file that helps search engines understand the structure of your website and find important pages. Google relies on sitemaps to efficiently crawl websites, especially large or complex sites with lots of dynamic or infrequently linked pages.</p><p>When managed properly, sitemaps improve indexing, making it easier for Google to discover and prioritize your content. However, submitting too many sitemaps or poorly organized ones can hinder indexing.</p><h4><strong>2. Common Issues with Sitemap Submissions</strong></h4><p>Many website owners encounter errors such as “Couldn't fetch” or delayed indexing after submitting their sitemaps. Here’s why these issues occur:</p><ul><li><strong>Overwhelming Google’s Crawl Budget</strong>: Submitting a large number of sitemaps in a short time can overload Google’s crawlers, leading to delays or failures in processing.</li><li><strong>Poor Feedback</strong>: Google may report a failure (“Couldn't fetch”) without clearly stating that the sitemap is pending for crawling. This can cause confusion about whether or not the sitemap was processed.</li></ul><h4><strong>3. Best Practices for Sitemap Submission</strong></h4><p><strong>a) Stagger Sitemap Submissions</strong></p><p>If your website generates multiple sitemaps (especially for large sites with thousands of URLs), avoid submitting them all at once. Staggering your submissions allows Google to process each sitemap in smaller batches, reducing the load on their crawlers and minimizing errors.</p><p><strong>How to Stagger Submissions</strong>:</p><ul><li>Submit a few sitemaps at a time, spaced out over several days or weeks.</li><li>Focus on submitting sitemaps for newly updated or more important content first.</li></ul><p><strong>b) Combine Sitemaps Strategically</strong></p><p>Rather than submitting dozens of small sitemaps, consider combining related URLs into fewer, larger sitemaps. By organizing your content into logical groups (e.g., by category, section, or content type), you can reduce the total number of sitemaps submitted, making it easier for Google to process your content.</p><p><strong>Example</strong>:</p><ul><li>Group all meet results under a single sitemap (e.g., <code>meet-results.xml</code>), rather than having a separate sitemap for each meet.</li><li>Use a sitemap index file to reference multiple sitemaps if your site is still too large for one sitemap.</li></ul><p><strong>c) Optimize Sitemap Size</strong></p><p>While the official limit is 50,000 URLs per sitemap, it’s often better to keep your sitemaps smaller, around 5,000 to 10,000 URLs. Smaller sitemaps tend to get processed faster and more efficiently by Google.</p><p><strong>Benefits of Smaller Sitemaps</strong>:</p><ul><li>Easier to regenerate and update.</li><li>Reduced risk of delays or errors during submission.</li><li>Faster crawl and indexing for important pages.</li></ul><p><strong>d) Adjust Priority and Change Frequency</strong></p><p>Use the <code>priority</code> and <code>changefreq</code> fields in your sitemap to guide Google on how often to re-crawl pages and how important they are relative to other content on your site. For example, a newly added meet or event page may require frequent crawling, while static pages need less attention.</p><p><strong>Recommended Settings</strong>:</p><ul><li><strong>Newly added or frequently updated pages</strong>: Use <code>priority</code> of <code>0.8</code> to <code>0.9</code> and <code>changefreq</code> of <code>daily</code> or <code>weekly</code>.</li><li><strong>Older or rarely updated pages</strong>: Use <code>priority</code> of <code>0.3</code> to <code>0.5</code> and <code>changefreq</code> of <code>monthly</code> or <code>yearly</code>.</li></ul><p><strong>e) Monitor in Google Search Console</strong></p><p>Always monitor your sitemap submissions through Google Search Console. Google will report any issues, such as parsing errors or failed submissions, so you can address them quickly.</p><p><strong>Steps</strong>:</p><ul><li>Log into Google Search Console and navigate to the “Sitemaps” section.</li><li>Check the status of each submitted sitemap.</li><li>If you see a “Couldn't fetch” error, wait before resubmitting to avoid overloading Google.</li></ul><h4><strong>4. What to Do if Google Reports "Couldn't fetch"</strong></h4><p>If you encounter this message after submitting a sitemap, it doesn’t always mean that Google is ignoring your sitemap. It often indicates that the sitemap is still in the queue to be processed. Here’s what you can do:</p><ul><li><strong>Wait</strong>: Give Google time to process the sitemap, especially if you’ve recently submitted multiple sitemaps.</li><li><strong>Don’t Resubmit Too Soon</strong>: Repeatedly submitting the same sitemap too quickly may delay Google’s ability to process it.</li><li><strong>Check for Issues</strong>: Ensure there are no syntax errors in the sitemap and that it’s accessible to Google (no <code>robots.txt</code> blocks or server issues).</li></ul><h4><strong>5. The Importance of Pinging Google</strong></h4><p>While Google typically crawls your site based on its algorithm, you can speed up the indexing process by pinging Google with your sitemap URL when new content is added or updated. This helps Google recognize that fresh content is available.</p><p><strong>How to Ping Google</strong>:</p><pre><code class="language-css">http://www.google.com/ping?sitemap=https://example.com/sitemap.xml</code></pre><p>This simple step notifies Google of the changes without overwhelming its crawlers.</p><h4><strong>6. Conclusion: Simplify and Optimize Your Sitemap Strategy</strong></h4><p>To ensure that Google crawls and indexes your content efficiently, focus on optimizing how and when you submit your sitemaps. Avoid overwhelming Google with too many sitemaps at once, and use priority and frequency settings to guide its crawlers to the most important content.</p><p>By staggering submissions, combining smaller sitemaps, and monitoring the process in Google Search Console, you’ll improve your site’s crawlability and avoid the frustrating “Couldn't fetch” errors.</p>

Managing sitemaps is a critical component of ensuring that your website is crawled and indexed effectively by Google. However, submitting too many sitemaps or overwhelming Google’s crawlers can lead to delays, poor user experience, and frustrating errors like “Could not be fetched.” In this post, we'll explore best practices for optimizing sitemap submissions, managing Google’s crawl budget, and keeping your content indexed efficiently.

Optimizing Sitemap Submissions: Best Practices for Smooth Google Indexing

<p>In Next.js, hydration errors are a common issue when using browser-specific APIs, such as <code>sessionStorage</code> or <code>localStorage</code>. One of the most frequent errors developers encounter is:</p><pre><code class="language-css">Error: Text content does not match server-rendered HTML.
Warning: Text content did not match. Server: "2023-2024" Client: "2022-2023"</code></pre><p>This error occurs because Next.js renders content on both the server and the client. When the server renders the content, it doesn’t have access to the browser-specific APIs, so it may use default values. However, once the content is hydrated on the client side, these browser APIs become available, and the content may change, leading to a mismatch between the server-rendered and client-rendered HTML.</p><figure class="image"><img src="https://images.unsplash.com/photo-1554140426-5e830b73a5e8?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw0NHx8aHlkcmF0aW9ufGVufDB8fHx8MTcyNzIzMTg4M3ww&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@janoschlino?utm_source=DNX&amp;utm_medium=referral">Janosch Lino</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>In this post, we’ll walk through how to use the <code>useEffect</code> hook to fix this hydration mismatch by ensuring that browser-specific logic, such as accessing <code>sessionStorage</code>, only runs on the client.</p><h3>Understanding the Problem</h3><p>Let's say you have the following code that uses <code>sessionStorage</code> to save and retrieve the active season of a sports application:</p><pre><code class="language-javascript">const [activeSeason, setActiveSeason] = useState(initialSeason());

function initialSeason() {
  if (typeof window !== "undefined") {
    const savedSeason = sessionStorage.getItem("SS-IM-ACTIVE-SEASON");
    if (savedSeason) {
      return JSON.parse(savedSeason); // Retrieve both season and seasonDisplay
    }
  }
  return {
    season: season,
    seasonDisplay: `${seasonStart}-${seasonEnd}`, // Default seasonDisplay
    seasonStart: seasonStart,
    seasonEnd: seasonEnd,
  };
}</code></pre><p>At first glance, this looks fine, but it will cause a <strong>hydration error</strong> when the server renders one set of values (e.g., the default season) and the client renders a different value from <code>sessionStorage</code>. Since the HTML differs, Next.js will throw a hydration mismatch error.</p><h3>Solution: Using <code>useEffect</code></h3><p>The key to solving this issue is to ensure that any browser-specific logic, such as accessing <code>sessionStorage</code>, only runs on the client side after the component has mounted. This is where <code>useEffect</code> comes in handy.</p><p><code>useEffect</code> allows you to delay certain logic until after the component has been rendered on the client, ensuring that the server-rendered HTML matches the initial client-side HTML. Let’s modify the previous code to use <code>useEffect</code> and prevent the hydration mismatch.</p><h3>Fixing the Hydration Mismatch</h3><p>Here’s how to refactor the code:</p><pre><code class="language-javascript">import { useState, useEffect } from 'react';

const MyComponent = ({ season, seasonStart, seasonEnd }) =&gt; {
  // Initialize state with the default season for server-side rendering
  const [activeSeason, setActiveSeason] = useState({
    season: season,
    seasonDisplay: `${seasonStart}-${seasonEnd}`,
    seasonStart: seasonStart,
    seasonEnd: seasonEnd,
  });

  useEffect(() =&gt; {
    // Run only on the client side
    if (typeof window !== "undefined") {
      const savedSeason = sessionStorage.getItem("SS-IM-ACTIVE-SEASON");
      if (savedSeason) {
        const parsedSeason = JSON.parse(savedSeason);
        setActiveSeason(parsedSeason); // Update state with sessionStorage data
      }
    }
  }, []); // Empty dependency array ensures this runs only after the component mounts

  return (
    &lt;div&gt;
      &lt;h1&gt;{activeSeason.seasonDisplay}&lt;/h1&gt;
    &lt;/div&gt;
  );
};

export default MyComponent;</code></pre><h3>Explanation:</h3><ol><li><strong>Default State for Server-Side Rendering</strong>:<br>When initializing the <code>useState</code> hook, we provide a default value for the active season based on props like <code>season</code>, <code>seasonStart</code>, and <code>seasonEnd</code>. This ensures that the server-rendered HTML will always have a consistent value.</li><li><code><strong>useEffect</strong></code><strong> for Client-Side Update</strong>:<br>The <code>useEffect</code> hook is used to access <code>sessionStorage</code> only on the client side. Since <code>useEffect</code> runs after the component has mounted, it avoids any mismatch during the initial render.</li><li><strong>Preventing Hydration Mismatch</strong>:<br>By setting the default state during server-side rendering and only updating the state after the component has mounted, we ensure that the server-rendered and client-rendered HTML match, avoiding the hydration mismatch error.</li></ol><h3>Why This Works</h3><p>Next.js pre-renders the page on the server and sends the HTML to the client. When the page is loaded on the client, React re-renders the component to "hydrate" it, attaching the React event listeners to the HTML. If the HTML on the server and client are different, a mismatch occurs.</p><p>By using <code>useEffect</code>, the <code>sessionStorage</code> logic is deferred until after the component is mounted on the client side. This ensures the server and client initial renders are consistent, and only after the initial render will the state be updated based on <code>sessionStorage</code>.</p><h3>Key Takeaways</h3><ul><li><strong>Server-Side Rendering (SSR) Mismatch</strong>: This error occurs when the content rendered on the server differs from what’s rendered on the client.</li><li><strong>Fix with </strong><code><strong>useEffect</strong></code>: By using the <code>useEffect</code> hook, you can ensure that browser-specific APIs like <code>sessionStorage</code> are only accessed on the client side, preventing hydration mismatches.</li><li><strong>Best Practice</strong>: Always ensure that initial state values are consistent for both server-side and client-side rendering, and only modify the state after the client has fully mounted.</li></ul><p>With this approach, you can ensure that your Next.js application works seamlessly with browser APIs like <code>sessionStorage</code> without causing any hydration mismatch issues.</p>

In Next.js, hydration errors are a common issue when using browser-specific APIs, such as sessionStorage or localStorage. This error occurs because Next.js renders content on both the server and the client. When the server renders the content, it doesn’t have access to the browser-specific APIs, so it may use default values. However, once the content is hydrated on the client side, these browser APIs become available, and the content may change, leading to a mismatch between the server-rendered and client-rendered HTML.

Fixing Hydration Mismatch in Next.js Using useEffect

<p>Prefetching is one of the most powerful features of Next.js, designed to make navigation between pages incredibly fast. By preloading essential resources in the background, Next.js can provide a seamless user experience, reducing the time it takes to load new pages. But how exactly does prefetching work, and how does it handle dynamic data? Let’s dive into it.</p><figure class="image"><img src="https://images.unsplash.com/photo-1721593712969-c62cdc1d6bae?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxMXx8ZmV0Y2h8ZW58MHx8fHwxNzI2NjI3NjYzfDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@hiking_corgi?utm_source=DNX&amp;utm_medium=referral">Vlad D</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h4><strong>What is Prefetching in Next.js?</strong></h4><p>In simple terms, prefetching allows Next.js to preload the JavaScript and data required to render a page before the user even clicks a link. This means that when a user navigates to a linked page, it’s already partially loaded, making the transition feel instantaneous.</p><p>Next.js achieves this by leveraging the <code>&lt;Link&gt;</code> component, which automatically triggers prefetching for pages linked through it. However, prefetching doesn’t behave the same way for every type of page. It depends on whether the page is using <code>getStaticProps</code> or <code>getServerSideProps</code>.</p><h4><strong>How Prefetching Works with JavaScript and Data</strong></h4><p><strong>Prefetching JavaScript Files</strong><br>By default, when you use Next.js' <code>&lt;Link&gt;</code> component, it prefetches the <strong>JavaScript bundle</strong> for the linked page. This includes all the code necessary to render that page. You can observe this behavior by inspecting the network activity in your browser's developer tools. You’ll notice Next.js loading URLs like:</p><pre><code class="language-css">/_next/static/{buildId}/pages/pokemon/[id].js</code></pre><p>This ensures that when the user clicks the link, the JavaScript for the page is already available, allowing the page to load faster.</p><p><strong>Prefetching Data with </strong><code><strong>getStaticProps</strong></code><br>If the page you're linking to uses <code>getStaticProps</code>, Next.js will also prefetch the <strong>data</strong> for the page. This data is typically stored in a <strong>JSON</strong> file that is fetched along with the page’s JavaScript. This is possible because <code>getStaticProps</code> generates static content at build time, meaning the data is available before the page is even loaded.</p><p>For example, if your page is statically generated and linked with <code>&lt;Link&gt;</code>, you’ll notice Next.js prefetching both the JavaScript and a JSON file containing the data:</p><pre><code class="language-css">/_next/data/{buildId}/pokemon/[id].json</code></pre><p>This prefetching of static data ensures that the page is ready to load almost instantly when the user clicks the link.</p><p><strong>No Prefetching with </strong><code><strong>getServerSideProps</strong></code><br>On the other hand, if the page uses <code>getServerSideProps</code>, Next.js will <strong>only prefetch the JavaScript</strong>—<strong>not the data</strong>. This is because <code>getServerSideProps</code> fetches data dynamically, at request time. Prefetching the data wouldn’t make sense in this case, as it’s intended to be fresh and up-to-date on every page load.</p><p>This means that when you navigate to a page that uses <code>getServerSideProps</code>, the actual data will only be fetched when the user clicks the link and the server processes the request.</p><h4><strong>When Does Prefetching Happen?</strong></h4><p>Next.js prefetches linked pages <strong>as soon as they appear in the viewport</strong>. This is a powerful optimization—pages that the user is likely to click are preloaded in the background, so when they do click, the content is ready.</p><p>However, if you have many links on a page (e.g., a list of 50 swimmers), this could lead to a large number of prefetch requests. While this usually improves user experience, it can potentially overwhelm the server or affect performance, especially if each link corresponds to data fetching from APIs.</p><h4><strong>Controlling Prefetching Behavior</strong></h4><p><strong>Disabling Prefetch for Individual Links</strong><br>Sometimes, you may want to disable prefetching for specific links, especially if preloading a lot of pages isn’t necessary. You can disable prefetching for individual links like this:</p><pre><code class="language-css">&lt;Link href="/swimmer/john" prefetch={false}&gt;
  View John's Profile
&lt;/Link&gt;</code></pre><p><strong>Disabling Prefetch Globally</strong><br>You can also disable prefetching globally in your <code>next.config.js</code> file:</p><pre><code class="language-javascript">module.exports = {
  experimental: {
    prefetchOnHover: false,
  },
};</code></pre><p>This prevents Next.js from automatically prefetching linked pages.</p><h4><strong>Best Practices for Prefetching</strong></h4><ul><li><strong>Use </strong><code><strong>getStaticProps</strong></code><strong> where possible</strong>: If you’re working with static data, <code>getStaticProps</code> will enable Next.js to prefetch both the page and its data, giving you the best performance.</li><li><strong>Limit Prefetching for Large Lists</strong>: If your page contains a long list of links (e.g., hundreds of swimmers), consider disabling prefetching for some of them to avoid overwhelming the server with too many requests.</li><li><strong>Use Dynamic Data Sparingly</strong>: For pages using <code>getServerSideProps</code>, be mindful that prefetching won’t speed up the data-fetching process. Only prefetch what’s essential.</li></ul><h4><strong>Conclusion</strong></h4><p>Prefetching is a core feature of Next.js that greatly enhances user experience by reducing load times. Understanding when and how Next.js prefetches JavaScript and data can help you optimize your application's performance. By using <code>getStaticProps</code>, you can take full advantage of Next.js' prefetching capabilities, while <code>getServerSideProps</code> allows you to keep dynamic data fresh but won’t benefit from data prefetching.</p><p>Knowing how and when to control prefetching can ensure that your app runs efficiently and delivers a fast, smooth experience for users.</p>

Prefetching is one of the most powerful features of Next.js, designed to make navigation between pages incredibly fast. By preloading essential resources in the background, Next.js can provide a seamless user experience, reducing the time it takes to load new pages. But how exactly does prefetching work, and how does it handle dynamic data? Let’s dive into it.



Understanding Prefetching in Next.js

<p>Pagination is a critical aspect of any application that handles large datasets. It affects both the user experience and the performance of the app, especially when dealing with significant amounts of data.</p><figure class="image"><img src="https://images.unsplash.com/photo-1577992805652-44fed5545066?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwzfHxoeWJyaWR8ZW58MHx8fHwxNzI2NTM2OTM2fDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@gpthree?utm_source=DNX&amp;utm_medium=referral">George Pagan III</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>Typically, there are two main types of pagination:</p><ol><li><strong>Server-side Pagination</strong>: The server sends a fixed number of records per page (e.g., 25 records per page), and every time the user changes the page, the client makes an API call to retrieve the next set of data. This method is efficient but leads to multiple network calls, which can slow down performance when users browse through many pages.</li><li><strong>Client-side Pagination</strong>: In this approach, the server sends all the data at once, and the frontend handles the pagination. While this reduces network calls, it can negatively impact performance when the dataset is large, as the initial load takes longer and uses a lot of memory.</li></ol><h3><strong>The Hybrid Approach: Best of Both Worlds</strong></h3><p>To strike a balance between these two methods, we can adopt a <strong>hybrid pagination strategy</strong>. The idea is to:</p><ul><li><strong>Pull data in batches</strong> (e.g., 200 records at a time, covering multiple pages).</li><li>Use <strong>client-side pagination</strong> to handle the pages within the batch.</li><li>When the user navigates beyond the current batch (e.g., page 9 when batch size is 8 pages), the system makes another API call to fetch the next set of data.</li></ul><p>This way, we reduce the number of network calls while keeping memory usage low and the initial load time quick.</p><h4><strong>How it Works</strong></h4><ul><li><strong>Server-side</strong>: Pull data in larger batches (e.g., 200 records covering 8 pages).</li><li><strong>Client-side</strong>: Handle pagination within the current batch.</li><li><strong>For random page requests</strong>: If the user requests a random page (e.g., page 31), calculate which batch this page falls into and pull the data accordingly.</li></ul><p>Here’s an example code in React using this strategy:</p><pre><code class="language-javascript">const SS_PAGESIZE = 25;  // Items per page
const SS_BATCHSIZE = 8;  // Number of pages per batch (8 pages * 25 records)

const TimeTable = ({ initRecords, initOptions, season }) =&gt; {
  const [options, setOptions] = useState(initOptions);
  const [allRecords, setAllRecords] = useState(initRecords);
  const [activePage, setActivePage] = useState(1);
  const [batchStart, setBatchStart] = useState(0);
  const [isLoading, setIsLoading] = useState(false);

  const fetchRecords = async (batchStart) =&gt; {
    setIsLoading(true);
    try {
      const tResult = await getRankings(
        options.event,
        options.type,
        options.ageGroup,
        options.gender,
        season,
        batchStart,
        SS_PAGESIZE * SS_BATCHSIZE  // Fetch a batch of 200 records
      );
      setAllRecords(tResult);
    } catch (err) {
      console.error(err);
    }
    setIsLoading(false);
  };

  const handlePaginationChange = async (value) =&gt; {
    const batchStartNow = Math.floor((value - 1) / SS_BATCHSIZE) * SS_PAGESIZE * SS_BATCHSIZE;
    if (batchStartNow !== batchStart) {
      setBatchStart(batchStartNow);
      await fetchRecords(batchStartNow);  // Fetch new batch if needed
    }
    setActivePage(value);  // Update the page on the client-side
  };

  useEffect(() =&gt; {
    fetchRecords(batchStart);
  }, [batchStart, season, options]);

  const currentRecords = allRecords.data.slice(
    (activePage - 1) % SS_BATCHSIZE * SS_PAGESIZE,
    (activePage % SS_BATCHSIZE) * SS_PAGESIZE
  );

  return (
    &lt;&gt;
      &lt;Table&gt;
        &lt;Thead&gt;
          &lt;Tr&gt;
            &lt;Th&gt;Name&lt;/Th&gt;
            &lt;Th&gt;Age&lt;/Th&gt;
            &lt;Th&gt;Team&lt;/Th&gt;
            {/* More headers... */}
          &lt;/Tr&gt;
        &lt;/Thead&gt;
        &lt;Tbody&gt;
          {currentRecords.map((record, idx) =&gt; (
            &lt;Tr key={idx}&gt;
              &lt;Td&gt;{record.name}&lt;/Td&gt;
              &lt;Td&gt;{record.age}&lt;/Td&gt;
              &lt;Td&gt;{record.team}&lt;/Td&gt;
              {/* More data... */}
            &lt;/Tr&gt;
          ))}
        &lt;/Tbody&gt;
      &lt;/Table&gt;

      &lt;DNXPagination
        activePage={activePage}
        totalPages={Math.ceil(allRecords.total / SS_PAGESIZE)}
        onPageChange={handlePaginationChange}
      /&gt;
    &lt;/&gt;
  );
};</code></pre><h3><strong>Conclusion</strong></h3><p>By adopting a hybrid pagination approach, you can drastically reduce the number of network calls while improving the user experience. The app will load faster initially, and the server won't be overwhelmed with too many requests as the user navigates through the data.</p><p>This structure combines the theory behind hybrid pagination with the practical React implementation, making it a valuable resource for others interested in improving both performance and UX.</p>

Pagination is a critical aspect of any application that handles large datasets. It affects both the user experience and the performance of the app, especially when dealing with significant amounts of data.

Improving UX and Performance with Hybrid Pagination

<p>In many web applications, you often need to scroll to specific elements dynamically based on partial or unknown IDs. This can be especially useful when elements are generated dynamically, and you only know a portion of the ID, such as a prefix or suffix.</p><figure class="image"><img src="https://images.unsplash.com/photo-1527814050087-3793815479db?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwyMXx8bW91c2V8ZW58MHx8fHwxNzI2NTM1ODQwfDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@v3frankie?utm_source=DNX&amp;utm_medium=referral">Frankie</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>Additionally, if your web page has a fixed header (like a navigation bar), you'll need to adjust the scroll position to ensure the target element is fully visible and not hidden behind the fixed header.</p><p>In this guide, we’ll cover:</p><ol><li><strong>How to scroll to an element using a dynamic (partial) ID</strong>.</li><li><strong>How to apply an offset for fixed headers or padding</strong> to ensure proper visibility.</li></ol><h3>1. Scrolling to an Element with a Dynamic ID</h3><p>To scroll to an element when you know only part of its ID (e.g., it starts with or contains a certain string), you can use the CSS attribute selector in combination with JavaScript’s <code>querySelector()</code> method.</p><h4>Example: Scroll to an Element with a Dynamic ID Prefix</h4><p>Let’s say you want to scroll to an element where the ID starts with <code>target-123-</code> (where the <code>123</code> is dynamic).</p><pre><code class="language-javascript">const targetRank = "123"; // Dynamic portion of the ID
const element = document.querySelector(`[id^="target-${targetRank}-"]`); // Find element where ID starts with "target-123-"

if (element) {
  element.scrollIntoView({
    behavior: "smooth", // Smooth scrolling animation
    block: "start",     // Align the element at the start of the viewport
  });
}</code></pre><h3>Explanation:</h3><ul><li><code><strong>[id^="prefix"]</strong></code>: This CSS attribute selector selects an element where the <code>id</code> starts with a specific prefix (<code>target-123-</code> in this case). The <code>^=</code> symbol matches the beginning of the string.</li><li><code><strong>querySelector()</strong></code>: This method allows you to use the selector to find the element with the matching dynamic ID.</li><li><code><strong>behavior: "smooth"</strong></code>: This provides a smooth scrolling effect.</li><li><code><strong>block: "start"</strong></code>: This ensures the element is aligned with the top of the viewport.</li></ul><h3>2. Scrolling with Offset for Fixed Headers or Padding</h3><p>In cases where you have a fixed header (like a navigation bar) or need to add some padding to the scroll position, you’ll want to adjust the scroll position manually. The <code>scrollIntoView()</code> method does not account for fixed elements, so we need to calculate the position and scroll accordingly.</p><h4>Example: Scroll to an Element with an Offset (Fixed Header)</h4><p>Assume your page has a fixed header that is 80px tall. Here’s how you can adjust the scroll position to ensure the element is not hidden behind the header:</p><pre><code class="language-javascript">const targetRank = "123"; // Dynamic portion of the ID
const element = document.querySelector(`[id^="target-${targetRank}-"]`); // Find element where ID starts with "target-123-"

if (element) {
  // Calculate the position of the element and adjust for the fixed header
  const yOffset = -80; // Height of the fixed header (80px)
  const y = element.getBoundingClientRect().top + window.pageYOffset + yOffset;

  // Scroll to the calculated position
  window.scrollTo({
    top: y,
    behavior: 'smooth', // Smooth scrolling animation
  });
}</code></pre><h3>Explanation:</h3><ul><li><code><strong>getBoundingClientRect().top</strong></code>: This method returns the position of the element relative to the viewport (its top position).</li><li><code><strong>window.pageYOffset</strong></code>: This gives the current vertical scroll position of the window.</li><li><code><strong>yOffset</strong></code>: This is the offset for the fixed header. In this case, it’s set to <code>-80</code> to account for the 80px header.</li><li><code><strong>window.scrollTo()</strong></code>: This method allows you to scroll the page to a specific <code>top</code> position (with an optional <code>behavior: 'smooth'</code> for smooth scrolling).</li></ul><h3>3. Dynamic Offset Calculation (If Header Height Varies)</h3><p>If the height of the fixed header changes dynamically (for example, on responsive layouts or different screen sizes), you can calculate the header’s height dynamically:</p><pre><code class="language-javascript">const targetRank = "123"; // Dynamic portion of the ID
const element = document.querySelector(`[id^="target-${targetRank}-"]`); // Find element where ID starts with "target-123-"
const fixedHeaderHeight = document.querySelector('.fixed-header')?.offsetHeight || 0; // Dynamically get the height of the fixed header

if (element) {
  const yOffset = -fixedHeaderHeight; // Use the dynamic header height
  const y = element.getBoundingClientRect().top + window.pageYOffset + yOffset;

  window.scrollTo({
    top: y,
    behavior: 'smooth', // Smooth scrolling animation
  });
}</code></pre><p>In this example:</p><ul><li><code><strong>document.querySelector('.fixed-header')?.offsetHeight</strong></code>: Dynamically retrieves the height of the element with the <code>.fixed-header</code> class. If no such element exists, it defaults to <code>0</code>.</li><li><code><strong>yOffset = -fixedHeaderHeight</strong></code>: This dynamically adjusts the offset based on the actual height of the header.</li></ul><h3>Key Takeaways</h3><ul><li><strong>Dynamic ID Matching</strong>: Use the <code>querySelector()</code> method with CSS attribute selectors like <code>[id^="prefix"]</code> to scroll to elements with dynamic or partial IDs.</li><li><strong>Adjusting for Fixed Headers</strong>: Manually adjust the scroll position to account for fixed headers or padding using <code>getBoundingClientRect()</code> and <code>window.pageYOffset</code>.</li><li><strong>Smooth Scrolling</strong>: You can always apply smooth scrolling by using <code>behavior: "smooth"</code> in both <code>scrollIntoView()</code> and <code>window.scrollTo()</code>.</li></ul><h3>Full Example:</h3><p>Here’s a complete example that handles both dynamic ID scrolling and adjusting for a fixed header:</p><pre><code class="language-javascript">const targetRank = "123"; // Dynamic portion of the ID
const element = document.querySelector(`[id^="target-${targetRank}-"]`); // Find element where ID starts with "target-123-"
const fixedHeaderHeight = document.querySelector('.fixed-header')?.offsetHeight || 0; // Dynamically get the height of the fixed header

if (element) {
  const yOffset = -fixedHeaderHeight; // Use the dynamic header height
  const y = element.getBoundingClientRect().top + window.pageYOffset + yOffset;

  // Scroll to the calculated position with smooth scrolling
  window.scrollTo({
    top: y,
    behavior: 'smooth', // Smooth scrolling animation
  });
}</code></pre><p>This method ensures you can scroll to an element with a dynamic ID while also considering padding or fixed headers, providing a seamless user experience.</p>

In many web applications, you often need to scroll to specific elements dynamically based on partial or unknown IDs. This can be especially useful when elements are generated dynamically, and you only know a portion of the ID, such as a prefix or suffix.

How to Scroll to an Element with a Dynamic ID and Adjust for Padding or Fixed Headers

<p>When implementing search functionality on a website using <strong>Semantic UI React</strong>, you might come across a situation where the message <strong>"No results found"</strong> is displayed when no search results match the user’s query. While this message is helpful from a user interface perspective, it can create SEO issues when crawlers, like Google’s, index the page.</p><figure class="image"><img src="https://images.unsplash.com/photo-1562577309-2592ab84b1bc?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxzZW98ZW58MHx8fHwxNzI2NTM1MzEyfDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@merakist?utm_source=DNX&amp;utm_medium=referral">Merakist</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>Imagine Google indexing a page where a search query was run, and instead of actual content, it encounters a message saying <strong>"No results found."</strong> This isn't ideal for search engine optimization (SEO) because it:</p><ul><li>Adds unnecessary text that doesn't contribute positively to SEO.</li><li>May show up in search results, misleading users about the page’s relevance.</li></ul><p>In this post, we’ll walk you through how to handle this issue in <strong>Semantic UI React’s Search</strong> component.</p><h3>Why Is "No Results Found" a Problem for SEO?</h3><p>When Google's crawler indexes a page with a search component, it could:</p><ol><li>Run into a search that returns no results.</li><li>Index the "No results found" message.</li><li>Show the "No results found" message in search engine result pages (SERPs).</li></ol><p>This can affect the way your page is perceived by search engines and users alike, potentially lowering your page’s rank or reducing click-through rates.</p><h3>How to Hide the "No Results Found" Message in Semantic UI React Search</h3><p>Here’s how you can remove or conditionally hide the <strong>"No results found"</strong> message in <strong>Semantic UI React Search</strong>:</p><h4>1. Use the <code>showNoResults</code> Prop</h4><p>The <strong>Semantic UI React Search</strong> component provides a <code>showNoResults</code> prop. This prop controls whether the "No results found" message should be displayed if no matching results are found.</p><p>By default, this is set to <code>true</code>, meaning that the message will always be displayed when there are no results. To hide it, you can simply set <code>showNoResults={false}</code>.</p><h4>Example:</h4><pre><code class="language-css">import React, { useState } from "react";
import { Search } from "semantic-ui-react";

function MySearchComponent() {
  const [loading, setLoading] = useState(false);
  const [results, setResults] = useState([]);
  const [value, setValue] = useState("");

  const handleSearchChange = (e, { value }) =&gt; {
    setValue(value);
    setLoading(true);

    // Simulating an API call
    setTimeout(() =&gt; {
      const matchedResults = []; // Assume no results are found
      setResults(matchedResults);
      setLoading(false);
    }, 500);
  };

  return (
    &lt;Search
      loading={loading}
      onSearchChange={handleSearchChange}
      results={results}
      value={value}
      showNoResults={false} // Hide "No results found"
      placeholder="Search..."
    /&gt;
  );
}

export default MySearchComponent;</code></pre><p>In this example, when there are no results found, the search box won’t display the <strong>"No results found"</strong> message because <code>showNoResults</code> is set to <code>false</code>.</p><h4>2. Conditionally Show or Hide Based on Input</h4><p>You can also conditionally hide the "No results found" message based on whether the user has started typing. This ensures that search results pages or crawlers don’t see the message unless it's user-triggered.</p><h4>Example:</h4><pre><code class="language-css">import React, { useState } from "react";
import { Search } from "semantic-ui-react";

function SearchComponent() {
  const [loading, setLoading] = useState(false);
  const [results, setResults] = useState([]);
  const [value, setValue] = useState("");

  const handleSearchChange = (e, { value }) =&gt; {
    setValue(value);
    setLoading(true);

    // Simulating an API call
    setTimeout(() =&gt; {
      const matchedResults = value ? [] : results; // Simulating no results
      setResults(matchedResults);
      setLoading(false);
    }, 500);
  };

  return (
    &lt;Search
      loading={loading}
      onSearchChange={handleSearchChange}
      results={results}
      value={value}
      showNoResults={value.length &gt; 0 ? true : false} // Only show when user types
      placeholder="Search for a swimmer..."
    /&gt;
  );
}

export default SearchComponent;</code></pre><p>In this case:</p><ul><li>The <code>showNoResults</code> message is displayed <strong>only if the user has started typing</strong>. If the input field is empty, no "No results found" message will be shown.</li></ul><h3>3. Customize the No Results Message</h3><p>If you still want to display a message but need to customize it, you can use the <code>noResultsMessage</code> and <code>noResultsDescription</code> props to control what appears.</p><h4>Example:</h4><pre><code class="language-css">import React, { useState } from "react";
import { Search } from "semantic-ui-react";

function CustomSearchComponent() {
  const [loading, setLoading] = useState(false);
  const [results, setResults] = useState([]);
  const [value, setValue] = useState("");

  const handleSearchChange = (e, { value }) =&gt; {
    setValue(value);
    setLoading(true);

    // Simulating an API call
    setTimeout(() =&gt; {
      const matchedResults = value ? [] : results; // Simulating no results
      setResults(matchedResults);
      setLoading(false);
    }, 500);
  };

  return (
    &lt;Search
      loading={loading}
      onSearchChange={handleSearchChange}
      results={results}
      value={value}
      showNoResults={value.length &gt; 0}
      noResultsMessage="No swimmers found."
      noResultsDescription="Try refining your search with a team name or location."
      placeholder="Search swimmers, teams, and more..."
    /&gt;
  );
}

export default CustomSearchComponent;</code></pre><h3>SEO Benefits of Hiding "No Results Found"</h3><p>By hiding or customizing the <strong>"No results found"</strong> message, you improve the overall user experience and prevent search engines from indexing irrelevant messages. This helps your pages rank better because they are focused on actual content, not a placeholder message.</p><h3>Final Thoughts</h3><p>While Semantic UI React's search functionality is powerful, being mindful of how elements like <strong>"No results found"</strong> affect your page’s SEO is crucial. By using the <code>showNoResults</code> prop effectively and tailoring your search experience, you can ensure that users (and search engines) only see relevant content, which will ultimately boost your SEO performance.</p>

When implementing search functionality on a website using Semantic UI React, you might come across a situation where the message "No results found" is displayed when no search results match the user’s query. While this message is helpful from a user interface perspective, it can create SEO issues when crawlers, like Google’s, index the page.

How to Remove the "No Results Found" Message in Semantic UI React Search for Better SEO

<p>While working on a recent project that involved ranking swimmers based on their performance times, I had the opportunity to leverage one of the most powerful features of MongoDB: the <strong>aggregation pipeline</strong>. Specifically, I needed to calculate how a swimmer ranked against others, both nationwide (USA rank) and within smaller scopes like zones and Local Swimming Committees (LSCs).</p><figure class="image"><img src="https://images.unsplash.com/photo-1655905273021-3e196f191fb2?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxMXx8cGlwZWxpbmV8ZW58MHx8fHwxNzI2NTMyMjYwfDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@manelandsean?utm_source=DNX&amp;utm_medium=referral">Manel &amp; Sean</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>MongoDB’s aggregation framework made it possible to run dynamic queries and efficiently calculate these rankings, all while handling a variety of filters such as gender, age group, and event type. In this post, I'll walk through how I used <strong>MongoDB's </strong><code><strong>$lookup</strong></code> feature within an aggregation pipeline to create these rankings.</p><h3>The Problem: Ranking Swimmers by Performance Time</h3><p>Imagine a scenario where we have a large database of swimmers’ times from various competitions. We need to calculate where each swimmer ranks based on their performance relative to others for the same event. For example, if a swimmer has a time of 50 seconds in the 50 Freestyle event, we want to know how many swimmers have a faster time in that same event and calculate the swimmer's rank dynamically.</p><p>To achieve this, MongoDB’s aggregation pipeline comes to the rescue.</p><h3>The Aggregation Breakdown</h3><p>Here’s how MongoDB’s aggregation framework works in this context. We will be looking at the key steps in the pipeline and focusing particularly on the <strong>$lookup</strong> stage, which allows us to perform dynamic <strong>ranking lookups</strong>.</p><h4>Step 1: Matching the Swimmer’s Data</h4><p>The first step in the aggregation is to <strong>match</strong> the swimmer’s data. We’re filtering the database to find only the records relevant to the swimmer we are interested in.</p><pre><code class="language-javascript">{
  $match: {
    slug: slug,            // Match the unique identifier (slug) for the swimmer
    type: type,            // Match the stroke type (e.g., LCM)
    ageGroup: ageGroup,    // Match the age group (e.g., 15-16)
    sex: sex,              // Match the swimmer's gender
  },
}</code></pre><p>Here’s what’s happening:</p><ul><li>We use <code>$match</code> to filter documents and find only those that correspond to the swimmer’s <strong>slug</strong> (unique identifier), the stroke type, the age group, and gender.</li><li>This ensures that we are only looking at the relevant records for the swimmer's performance in the current context (e.g., a specific season).</li></ul><h4>Step 2: Projecting the Necessary Fields</h4><p>Next, we use <code>$project</code> to limit the fields we retrieve. We want only the data necessary for ranking calculations, such as the event name, the swimmer's time (<code>intTime</code>), and details like their team, zone, and LSC.</p><pre><code class="language-javascript">{
  $project: {
    event: 1,          // Include the event (e.g., 50 Free, 100 Back)
    intTime: 1,        // Include the internal time value (used for ranking)
    time: 1,           // Include the swimmer's official time
    zone: 1,           // Include the zone the swimmer belongs to
    lsc: 1,            // Include the Local Swimming Committee (LSC)
    teamCode: 1,       // Include the swimmer’s team code
  },
}</code></pre><p>This stage narrows down the dataset to only include the fields we care about for ranking purposes. We focus on:</p><ul><li><strong>intTime</strong>: The internal representation of the swimmer’s performance time, which we’ll use to compare against other swimmers.</li><li><strong>event</strong>: The swimming event (e.g., 50 Free), since rankings must be done event by event.</li><li><strong>zone, lsc, teamCode</strong>: These fields will later be used to calculate more specific rankings, such as zone or team rankings.</li></ul><h4>The Magic: <code>$lookup</code> for USA Rank</h4><p>Here’s where the <strong>real power</strong> of MongoDB’s aggregation framework shines: the <code>$lookup</code> stage.</p><p>In this case, the <code>$lookup</code> stage allows us to perform a <strong>JOIN-like operation</strong> in MongoDB. It enables us to dynamically compare a swimmer's performance time (<code>intTime</code>) with others in the same event and count how many swimmers have a faster time.</p><pre><code class="language-javascript">{
  $lookup: {
    from: "best_strokes" + season, // Use the dynamic season-based table
    let: { swimmerTime: "$intTime", event: "$event" }, // Pass the current swimmer's time and event
    pipeline: [
      {
        $match: {
          type: type,         // Match stroke type (e.g., LCM)
          ageGroup: ageGroup, // Match age group (e.g., 15-16)
          sex: sex,           // Match swimmer's gender
          $expr: {
            $and: [
              { $eq: ["$event", "$$event"] },           // Ensure it's the same event
              { $lt: ["$intTime", "$$swimmerTime"] },   // Find swimmers with faster times
            ],
          },
        },
      },
      { $count: "fasterSwimmers" }, // Count the number of swimmers with faster times
    ],
    as: "usaRankings", // Store the results in the "usaRankings" field
  },
}</code></pre><p>Here’s how this works:</p><ol><li><strong>from</strong>: We are performing the lookup on the same collection (<code>best_strokes</code>), but for a specific season. The <code>from</code> field points to a dynamically generated table based on the season, which allows us to query season-specific data.</li><li><strong>let</strong>: This defines the variables (<code>swimmerTime</code> and <code>event</code>) from the current document (the swimmer’s record). These variables will be used inside the <code>$match</code> stage of the <code>$lookup</code> to filter swimmers in the same event with faster times.</li><li><strong>pipeline</strong>: This is where the lookup does its heavy lifting. It runs a subquery (<code>$match</code>) where:<ul><li>We filter swimmers based on their event (<code>$eq: ["$event", "$$event"]</code>) to ensure we’re comparing times within the same event.</li><li>We look for swimmers with a faster time (<code>$lt: ["$intTime", "$$swimmerTime"]</code>).</li></ul></li><li><strong>$count</strong>: After filtering the swimmers with faster times, we use <code>$count</code> to get the number of swimmers who are faster. The result is stored in a field called <code>fasterSwimmers</code>.</li><li><strong>as</strong>: The results of this lookup are stored in the <code>usaRankings</code> field, which will later be used to calculate the swimmer's USA rank.</li></ol><h3>Calculating the USA Rank</h3><p>After running the lookup, we use <code>$addFields</code> to calculate the actual USA rank. This is done by adding <code>1</code> to the number of swimmers with faster times.</p><pre><code class="language-javascript">{
  $addFields: {
    usaRank: {
      $add: [{ $ifNull: ["$usaRankings.fasterSwimmers", 0] }, 1],
    },
  },
}</code></pre><p>This ensures that:</p><ul><li>If there are no faster swimmers (i.e., the swimmer is the fastest), <code>fasterSwimmers</code> will be <code>0</code>, and the rank will be <code>1</code>.</li><li>Otherwise, the rank is <code>1 + the number of faster swimmers</code>.</li></ul><h3>Why This is Powerful</h3><p>MongoDB's aggregation pipeline, especially the <code>$lookup</code> stage, is incredibly powerful for scenarios like dynamic ranking because:</p><ul><li><strong>Flexibility</strong>: It allows you to dynamically JOIN data across collections (or within the same collection, as in this case) and process complex ranking logic without the need for multiple queries.</li><li><strong>Efficiency</strong>: By using <code>$lookup</code> with pipelines, we can filter and aggregate data in one step, reducing the need for separate queries and simplifying the ranking process.</li><li><strong>Dynamic Queries</strong>: The ability to use variables like <code>$$swimmerTime</code> and <code>$$event</code> within the lookup makes the entire process highly adaptable, as we can perform customized lookups based on the current swimmer’s data.</li></ul><h3>Conclusion</h3><p>Using MongoDB’s aggregation framework with the <code>$lookup</code> stage allowed me to dynamically calculate rankings for swimmers in a single query. This approach is both flexible and efficient, and it showcases the power of MongoDB when dealing with complex data relationships, such as dynamic rankings across different scopes (e.g., USA, zone, LSC).</p><p>If you're working on a similar problem involving dynamic lookups or rankings, I highly recommend exploring MongoDB’s aggregation pipeline. It not only simplifies the query logic but also allows you to handle large-scale data processing efficiently within a single request.</p><p>Let me know if you have any questions or want to dive deeper into any of the aggregation stages!</p>

MongoDB’s aggregation framework made it possible to run dynamic queries and efficiently calculate these rankings, all while handling a variety of filters such as gender, age group, and event type. In this post, I'll walk through how I used MongoDB's $lookup feature within an aggregation pipeline to create these rankings.

Exploring MongoDB’s Powerful Aggregation Pipeline: Dynamic Ranking with $lookup

<p>While working on a recent Feathers.js project, I encountered a challenge related to <strong>modifying service results</strong> in an after hook. Specifically, I needed to append a <strong>calculated value</strong> (in my case, a rank) to each record. However, the way I initially approached the problem led to an unintended <strong>recursion issue</strong>, where the after hook triggered itself repeatedly.</p><figure class="image"><img src="https://images.unsplash.com/flagged/photo-1582733265415-a0740c8a82fd?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwyfHxyZWN1cnNpdmV8ZW58MHx8fHwxNzI2NTMxMDk5fDA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@seimesa?utm_source=DNX&amp;utm_medium=referral">Mario Mesaglio</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>In this note, I’ll walk through what I learned and share how I resolved the issue by using <strong>direct database queries</strong> instead of <code>context.service.find</code>. This could be useful for anyone encountering similar recursion problems in Feathers.js after hooks.</p><h3>The Problem: Recursive Behavior with <code>context.service.find</code></h3><p>In Feathers.js, after hooks are a great way to modify the data returned by a service before sending it back to the client. My goal was to return a list of records (e.g., performance times) and calculate a <strong>rank</strong> for each based on their position relative to others.</p><p>Initially, I used <code>context.service.find</code> to query the database from within the after hook. However, this approach caused the after hook to <strong>re-trigger itself</strong> every time the service method was called, resulting in an <strong>infinite loop</strong>. Here's a simplified version of the problematic code:</p><pre><code class="language-javascript">module.exports = (options = {}) =&gt; {
  return async (context) =&gt; {
    // This causes recursion!
    const totalRecordsBefore = await context.service.find({
      query: {
        intTime: { $lt: context.result.data[0].intTime }
      }
    });

    let currentRank = totalRecordsBefore + 1;
    context.result.data.forEach((record, index) =&gt; {
      record.rank = currentRank + index;
    });

    return context;
  };
};</code></pre><p>Since <code>context.service.find</code> internally triggers the service method again, the after hook kept calling itself, leading to the recursion issue.</p><h3>The Solution: Using Direct Database Queries</h3><p>The key realization was that Feathers.js hooks still have access to the underlying database model (e.g., Mongoose or Sequelize). By using the model directly for queries, I could bypass the service layer and avoid re-triggering the after hook.</p><p>Here’s how I adjusted the code to query the database <strong>directly</strong> using Mongoose’s <code>Model.countDocuments()</code> instead of <code>context.service.find</code>:</p><pre><code class="language-javascript">module.exports = (options = {}) =&gt; {
  return async (context) =&gt; {
    const { Model } = context.service; // Access the database model (e.g., Mongoose, Sequelize, etc.)

    // Check if there are results to rank
    if (context.params.query["ageGroup"] &amp;&amp; context.result.total &gt; 0) {
      const firstRecord = context.result.data[0]; // Get the first record to base the rank on

      // Build the query from context.params.query but remove $limit, $skip, $sort
      const query = { ...context.params.query };
      let nextRank = query.$skip;
      delete query.$limit;
      delete query.$skip;
      delete query.$sort;

      // Add the intTime condition dynamically to the query
      query.intTime = { $lt: firstRecord.intTime };

      // console.log(query);

      // Query the database directly using the model (Mongoose example)
      const totalRecordsBefore = await Model.countDocuments(query);

      let currentRank = totalRecordsBefore + 1; // Start rank based on records before

      // Loop through the results to add ranks
      context.result.data.forEach((record, index) =&gt; {
        // Assign the rank to the current record
        nextRank++;    
        if (
          index &gt; 0 &amp;&amp;
          record.intTime !== context.result.data[index - 1].intTime
        ) {
          currentRank = nextRank;
        }
        record.rank = currentRank;
      });
    }

    return context; // Return the modified context with ranked results
  };
};</code></pre><h3>Why This Solution Works</h3><p>Using the <strong>model</strong> to query the database directly avoids the recursion issue because it doesn’t invoke the Feathers service method again. Here’s what I learned:</p><ul><li><strong>Direct database queries prevent recursion</strong>: By querying the database directly (in this case, using <code>Model.countDocuments()</code> for Mongoose), I was able to fetch the necessary data without triggering the after hook multiple times.</li><li><strong>More control over database operations</strong>: Accessing the model directly gave me more flexibility in how I structured my queries. This allowed me to handle more complex logic, such as calculating ranks and managing pagination.</li><li><strong>Handling pagination and ties</strong>: Since my results were paginated, I needed to ensure that ranks were calculated properly across pages. Ties were also handled by assigning the same rank to records with identical values.</li></ul><h3>Final Thoughts</h3><p>This experience taught me the importance of understanding how Feathers.js hooks interact with the service layer. In cases where you need to modify results in an after hook (like calculating ranks), using <code>context.service.find</code> can lead to recursion problems. Instead, directly accessing the model to query the database provides a simple and effective solution.</p><p>I hope sharing this approach helps others who might run into similar issues with Feathers.js. If you're dealing with recursion or need to query data in an after hook, I recommend using the model directly for querying the database.</p>

While working on a recent Feathers.js project, I encountered a challenge related to modifying service results in an after hook. Specifically, I needed to append a calculated value (in my case, a rank) to each record. However, the way I initially approached the problem led to an unintended recursion issue, where the after hook triggered itself repeatedly.

Lessons Learned: Avoiding Recursion in Feathers.js After Hooks 

<p>In recent times, many developers have encountered challenges when using the <code>mysql2</code> package alongside Knex migrations, especially when dealing with changes in certificate authorities (CAs) for AWS RDS databases. This blog post aims to shed light on how upgrading <code>mysql2</code> and making adjustments in the setup can resolve such issues effectively.</p><figure class="image"><img src="https://images.unsplash.com/photo-1589330694653-ded6df03f754?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxhd3MlMjBjZXJ0aWZpY2F0ZXxlbnwwfHx8fDE3MTU2OTczNTZ8MA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@skillscouter?utm_source=DNX&amp;utm_medium=referral">Lewis Keegan</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h4>The Challenge: Certificate Changes and Knex Migrations</h4><p>AWS RDS introduced new CA certificates like <code>rds-ca-rsa2048-g1</code>, <code>rds-ca-rsa4096-g1</code>, and <code>rds-ca-ecc384-g1</code>, which offer enhanced security features. However, these changes also brought compatibility issues with certain Node.js packages, notably <code>mysql2</code>, especially when using Knex migrations with the <code>--esm</code> flag enabled.</p><h4>Understanding the Issue</h4><p>The primary issue arises from the certificate validation process in <code>mysql2</code>, which may result in errors like "self-signed certificate in certificate chain" when connecting to RDS instances using the new CA certificates. This can lead to disruptions in database operations, especially during Knex migrations.</p><h4>Solution: Upgrading MySQL2 and Adjusting the Setup</h4><ol><li><strong>Upgrade to </strong><code><strong>mysql2</strong></code><strong> Version 3.9.2</strong>: The latest version of <code>mysql2</code> (as of writing this post) includes fixes and enhancements, particularly regarding certificate validation and compatibility with newer CA certificates.</li><li><strong>Remove the </strong><code><strong>--esm</strong></code><strong> Flag in Knex Migrations</strong>: While the <code>--esm</code> flag enables ECMAScript Modules (ESM) support in Knex, it can cause conflicts with certain packages like <code>mysql2</code>. Removing this flag ensures smoother compatibility and module loading in CommonJS (CJS) environments.</li><li><strong>Configure </strong><code><strong>mysql2</strong></code><strong> for New CA Certificates</strong>: Ensure that your <code>mysql2</code> configuration is updated to support the new CA certificates introduced by AWS RDS. This may involve specifying the correct CA certificate file or using the default certificate handling provided by <code>mysql2</code>.</li></ol><h4>Benefits of Upgrading and Adjusting</h4><ul><li><strong>Improved Security</strong>: By upgrading to the latest <code>mysql2</code> version and using newer CA certificates, you enhance the security posture of your database connections, aligning with best practices for secure communication.</li><li><strong>Seamless Knex Migrations</strong>: Removing the <code>--esm</code> flag and configuring <code>mysql2</code> properly ensure that Knex migrations run smoothly without encountering certificate-related errors, providing a seamless development experience.</li></ul><h4>Conclusion</h4><p>In conclusion, upgrading <code>mysql2</code> and making necessary adjustments in the setup, such as removing the <code>--esm</code> flag in Knex migrations and configuring <code>mysql2</code> for new CA certificates, can effectively resolve certificate-related issues and ensure robust database operations in Node.js applications.</p><p>By staying updated with package versions and aligning configurations with evolving security standards, developers can navigate challenges like certificate changes with confidence, maintaining the integrity and reliability of their database interactions.</p>

In recent times, many developers have encountered challenges when using the mysql2 package alongside Knex migrations, especially when dealing with changes in certificate authorities (CAs) for AWS RDS databases. This blog post aims to shed light on how upgrading mysql2 and making adjustments in the setup can resolve such issues effectively.

Upgrading MySQL2 and Resolving Certificate Issues with Knex Migrations

<figure class="image"><img src="https://images.unsplash.com/uploads/1413222992504f1b734a6/1928e537?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxMnx8Y2FsbHxlbnwwfHx8fDE3MTQwNTQyMjJ8MA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@ptrikutam?utm_source=DNX&amp;utm_medium=referral">Pavan Trikutam</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>Asynchronous recursive function calls are a powerful technique used in JavaScript for handling tasks that require repeated asynchronous operations until a certain condition is met. In this blog post, we'll explore this concept using a real-world example and discuss how to ensure that the final result is correctly propagated back to the initial caller.</p><h2>Background</h2><p>Imagine a scenario where you need to fetch data from an API in an asynchronous manner, but the data retrieval process may take some time. You want to check the status of the data fetch operation periodically until the data is fully retrieved.</p><h2>Example Scenario</h2><p>Let's consider a simplified example where we have an asynchronous function <code>fetchStatus()</code> that fetches the status of a job from an API. We want to repeatedly check the status until the job is marked as "COMPLETED."</p><pre><code class="language-javascript">// Recursive function to check status
const checkStatus = async () =&gt; {
  // Simulate fetching status from an API
  const getResponse = await fetchStatus(); // Assume fetchStatus() fetches the status from an API

  if (getResponse.JobStatus === "COMPLETED") {
    // If job is completed, resolve with the result
    return getResponse.Result;
  }

  if (getResponse.JobStatus === "PROCESSING") {
    // If job is still processing, wait for 1 second and call checkStatus again
    await new Promise((resolve) =&gt; setTimeout(resolve, 1000));
    return checkStatus(); // Recursive call
    // OR:
    // return new Promise((resolve) =&gt; {
    //     setTimeout(() =&gt; resolve(checkStatus()), 1000);
    //});
  }

  // Handle other job statuses here if needed
  throw new Error("Unexpected job status");
};

// Initial call to checkStatus
const getResult = async () =&gt; {
  try {
    const result = await checkStatus();
    console.log("Final result:", result);
    return result; // Result is bubbled up to the initial caller
  } catch (error) {
    console.error("Error checking status:", error);
    throw error; // Error is also bubbled up if encountered
  }
};

// Usage example
getResult()
  .then((result) =&gt; {
    console.log("Success:", result);
  })
  .catch((error) =&gt; {
    console.error("Error:", error);
  });</code></pre><p>In this example:</p><ol><li>We define the <code>checkStatus</code> function that asynchronously fetches the job status and handles different status scenarios.</li><li>Inside <code>checkStatus</code>, if the job status is "PROCESSING," we wait for 1 second using <code>setTimeout</code> and then recursively call <code>checkStatus</code> again.</li><li>The <code>getResult</code> function initiates the process by calling <code>checkStatus</code>, and the final result or error is bubbled up to the initial caller through promises.</li></ol><h3>With Callbacks</h3><p>To use callbacks in the example of asynchronous recursive function calls, you can modify the code to pass a callback function as a parameter to the <code>checkStatus</code> function. Here's how you can do it:</p><pre><code class="language-javascript">// Recursive function to check status with callback
const checkStatus = async (callback) =&gt; {
  // Simulate fetching status from an API
  const getResponse = await fetchStatus(); // Assume fetchStatus() fetches the status from an API

  if (getResponse.JobStatus === "COMPLETED") {
    // If job is completed, invoke the callback with the result
    callback(null, getResponse.Result);
    return;
  }

  if (getResponse.JobStatus === "PROCESSING") {
    // If job is still processing, wait for 1 second and call checkStatus again
    await new Promise((resolve) =&gt; setTimeout(resolve, 1000));
    checkStatus(callback); // Recursive call with the same callback
    return;
  }

  // Handle other job statuses here if needed
  callback(new Error("Unexpected job status"));
};

// Usage example with callback
const handleStatus = (error, result) =&gt; {
  if (error) {
    console.error("Error checking status:", error);
    return;
  }
  console.log("Final result:", result);
};

// Initiate the process by calling checkStatus with the callback
checkStatus(handleStatus);</code></pre><p>In this updated code:</p><ul><li>The <code>checkStatus</code> function now accepts a callback function as a parameter.</li><li>When the job status is "COMPLETED," it invokes the callback with the result.</li><li>When the job status is "PROCESSING," it recursively calls <code>checkStatus</code> with the same callback.</li><li>The <code>handleStatus</code> function serves as the callback to process the final result or error.</li></ul><p>This approach allows you to handle the asynchronous recursive calls using callbacks, providing more flexibility and control over the flow of the asynchronous operations.</p>

Asynchronous recursive function calls are a powerful technique used in JavaScript for handling tasks that require repeated asynchronous operations until a certain condition is met. In this blog post, we'll explore this concept using a real-world example and discuss how to ensure that the final result is correctly propagated back to the initial caller.

Understanding Asynchronous Recursive Function Calls in JavaScript

<p>In my journey to optimize website performance, I explored the realm of caching in Node.js. Initially, I relied on Axios for API calls without caching, which resulted in redundant calls upon revisits to pages. To address this, I leveraged the Axios Cache Interceptor, a Node.js module designed for efficient API caching.</p><figure class="image"><img src="https://images.unsplash.com/photo-1521356152-ca21fff2693c?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwyfHxjYWNoZXxlbnwwfHx8fDE3MTA1NTczMTF8MA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@laynelawson?utm_source=DNX&amp;utm_medium=referral">Layne Lawson</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>At first glance, the Axios Cache Interceptor seemed like a game-changer. However, over time, I noticed intermittent slowdowns, especially after extended periods of application usage. This led me to investigate further, uncovering a memory leak issue associated with the Axios cache.</p><p>The cache, set with a 5-minute Time-To-Live (TTL), failed to clear efficiently, resulting in increased memory consumption and occasional performance hiccups. Despite my website's modest traffic, the cache's impact on memory usage was significant enough to affect overall performance.</p><p>After disabling the Axios Cache Interceptor, I observed a remarkable improvement in performance consistency, with ample memory allocation consistently available (65+MB). This experience taught me a valuable lesson about the nuances of caching – it's not a one-size-fits-all solution.</p><p>For dynamic websites generating a plethora of unique pages, caching can inadvertently consume excessive memory and impede performance. While caching benefits repeat page visits within sessions, in my case, lightweight queries and optimized memory usage proved to be more effective for maintaining smooth application performance.</p><p>In conclusion, my foray into caching in Node.js taught me the importance of striking a balance between performance optimization techniques and resource management. Sometimes, solving one problem may uncover unexpected challenges, but each experience contributes to a deeper understanding of system optimization strategies.</p>

For dynamic websites generating a plethora of unique pages, caching can inadvertently consume excessive memory and impede performance. While caching benefits repeat page visits within sessions, in my case, lightweight queries and optimized memory usage proved to be more effective for maintaining smooth application performance.

Navigating Node.js Caching: Lessons Learned

<p>Are you encountering issues with PHP extension installations in Homebrew? You're not alone. Many users face challenges when trying to install or upgrade PHP extensions, especially after Homebrew auto-upgrades. Here's a blog post discussing common problems and solutions.</p><figure class="image"><img src="https://images.unsplash.com/photo-1502205849765-9dcecc32a8a8?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwzM3x8YnJld3xlbnwwfHx8fDE3MDg4ODQ4Mjd8MA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@kimdonkey?utm_source=DNX&amp;utm_medium=referral">Manki Kim</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Understanding the Issue</h3><p>When you run <code>brew install</code> to install packages or update existing ones, Homebrew may automatically upgrade certain dependencies, including PHP. However, this auto-upgrade process can sometimes lead to compatibility issues, particularly with PHP extensions like MongoDB.</p><h3>The Problem with PHP MongoDB Extension Installation</h3><p>Let's say you've upgraded to PHP 8.3.3, but the PHP MongoDB extension (<code>php-mongodb</code>) is not installed for the new version. As a result, any PHP scripts relying on MongoDB will throw fatal errors, such as "Uncaught Error: Class 'MongoDB\Driver\Manager' not found."</p><h3>Attempting to Reinstall PHP MongoDB Extension</h3><p>To fix the issue, you might try reinstalling the PHP MongoDB extension using PECL (<code>pecl install mongodb</code>). However, you might encounter errors during the installation process, such as:</p><pre><code class="language-css">Warning: mkdir(): File exists in System.php on line 294
ERROR: failed to mkdir /opt/homebrew/Cellar/php/8.3.3/pecl/20230831</code></pre><h3>Resolving File Existence Error</h3><p>If you encounter a <code>file_exists</code> error during the PHP MongoDB extension installation process, it indicates a misconfiguration or error that resulted in <code>/opt/homebrew/Cellar/php/8.3.3/pecl</code> being symlinked to a file instead of a directory.</p><p>Follow these steps to resolve the issue:</p><p><strong>Remove the Symlink</strong>: First, remove the symlink that points to the file:</p><pre><code class="language-css">sudo rm /opt/homebrew/Cellar/php/8.3.3/pecl</code></pre><p><strong>Recreate the Directory</strong>: Recreate the <code>pecl</code> directory as a proper directory:</p><pre><code class="language-css">sudo mkdir /opt/homebrew/Cellar/php/8.3.3/pecl</code></pre><p><strong>Correct the Symlink</strong>: Next, recreate the symlink to point to the correct directory:</p><pre><code class="language-css">sudo ln -s /opt/homebrew/lib/php/pecl /opt/homebrew/Cellar/php/8.3.3/pecl</code></pre><h3>Resolving <code>extension_dir</code> Configuration Error</h3><p>After resolving the <code>file_exists</code> error by correcting the symlink, you might encounter an issue with the <code>extension_dir</code> configuration in your <code>php.ini</code> file. This error typically arises due to the PHP configuration pointing to an incorrect directory path.</p><p>Follow these steps to fix the <code>extension_dir</code> configuration:</p><p><strong>Locate </strong><code><strong>php.ini</strong></code><strong> File</strong>: Find your PHP configuration file (<code>php.ini</code>). In Homebrew installations, the <code>php.ini</code> file is typically located at <code>/opt/homebrew/etc/php/&lt;version&gt;/php.ini</code>, where <code>&lt;version&gt;</code> corresponds to your PHP version (e.g., <code>8.3.3</code>).</p><p><strong>Edit </strong><code><strong>php.ini</strong></code><strong> File</strong>: Open the <code>php.ini</code> file in a text editor:</p><pre><code class="language-css">sudo nano /opt/homebrew/etc/php/8.x.x/php.ini</code></pre><p>Replace <code>8.x.x</code> with your actual PHP version.</p><p><strong>Update </strong><code><strong>extension_dir</strong></code><strong> Setting</strong>: Look for the <code>extension_dir</code> setting in <code>php.ini</code>. This setting specifies the directory where PHP extensions are located. Update the path to point to the correct directory where the MongoDB PHP extension (<code>mongodb.so</code>) is installed.</p><pre><code class="language-css">extension_dir = "/opt/homebrew/Cellar/php/8.3.3/pecl/20230831"</code></pre><p>Ensure that the directory path matches the location where the MongoDB PHP extension is installed on your system.</p><p><strong>Save and Exit</strong>: After making the necessary changes, save the <code>php.ini</code> file and exit the text editor.</p><p>By updating the <code>extension_dir</code> setting in your <code>php.ini</code> file to point to the correct directory, you should resolve the configuration error. This ensures that PHP can locate and load the MongoDB PHP extension (<code>mongodb.so</code>) properly, allowing your PHP scripts to interact with MongoDB without errors.</p><p>Feel free to customize the blog post as needed!</p>

Are you encountering issues with PHP extension installations in Homebrew? You're not alone. Many users face challenges when trying to install or upgrade PHP extensions, especially after Homebrew auto-upgrades. Here's a blog post discussing common problems and solutions.

Dealing with PHP Extension Installation Issues in Homebrew

<p>In the realm of data processing, the efficiency of code is paramount, especially when dealing with large datasets. This blog post aims to compare the performance of two code snippets designed to count and organize data from a sizable dataset. The snippets, albeit achieving the same result, implement different strategies to handle the data. We will dissect each approach, evaluating their strengths and weaknesses.</p><figure class="image"><img src="https://images.unsplash.com/photo-1454165804606-c3d57bc86b40?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwyfHxjYWxjdWxhdGluZ3xlbnwwfHx8fDE3MDcxNzM4ODl8MA&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@homajob?utm_source=DNX&amp;utm_medium=referral">Scott Graham</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3><strong>Snippet 1: Functional Approach</strong></h3><p>The first snippet employs a functional programming paradigm, utilizing methods like <strong>flatMap</strong> and <strong>reduce</strong> to succinctly process the data. The primary steps involve flattening nested structures, aggregating quantities, and sorting the results. The final output is a well-organized array of publications with corresponding quantities.</p><pre><code class="language-javascript" id="feN0s5DqC">if (data &amp;&amp; data.publicationSentInquiries) {
  const midRows = data.publicationSentInquiries;
  rows = midRows.flatMap((item) =&gt;
    item.inquiryPublications.map((pub) =&gt; ({
      inquiryId: item.id,
      publicationName: pub.name,
      publicationQty: parseInt(pub.qty, 10),
    }))
  );

  const publications = rows.reduce((acc, item) =&gt; {
    const key = item.publicationName;
    acc[key] = (acc[key] || 0) + item.publicationQty;
    return acc;
  }, {});

  sortedPublications = Object.entries(publications)
    .map(([publicationName, publicationQty]) =&gt; ({
      publicationName,
      publicationQty,
    }))
    .sort((a, b) =&gt; b.publicationQty - a.publicationQty);

  const totalSent = sortedPublications.reduce(
    (total, pub) =&gt; total + pub.publicationQty,
    0
  );

  sortedPublications.push({
    publicationName: "Total Sent",
    publicationQty: totalSent,
  });

  // Now, sortedPublications contains the desired result
}
</code></pre><h3><strong>Snippet 2: Iterative Approach</strong></h3><p>Contrastingly, the second snippet follows an iterative approach, utilizing forEach loops and conventional data manipulation techniques. It builds an array (<strong>rows</strong>) by iterating through the input data, incrementally accumulating publication quantities, and eventually sorting the results using an external library (<strong>orderBy</strong>).</p><pre><code class="language-javascript" id="CkQ6HHydy">let rows = [];
if (data &amp;&amp; data.publicationSentInquiries) {
  const midRows = data.publicationSentInquiries;
  midRows.forEach((item) =&gt; {
    const publications = item.inquiryPublications;
    const pubRows = publications.map((pub) =&gt; ({
      inquiryId: item.id,
      publicationName: pub.name,
      publicationQty: pub.qty,
    }));
    rows = rows.concat(pubRows);
  });
}

const publicationRows = [];
const publications = {};
rows.forEach((item) =&gt; {
  if (publications[item.publicationName]) {
    const currentQty = publications[item.publicationName];
    publications[item.publicationName] =
      currentQty + parseInt(item.publicationQty, 10);
  } else {
    publications[item.publicationName] = parseInt(item.publicationQty, 10);
  }
});

const keys = Object.keys(publications);

let totalSent = 0;
keys.forEach((key) =&gt; {
  totalSent += publications[key];
  publicationRows.push({
    publicationName: key,
    publicationQty: publications[key],
  });
});

const sortedPublications = orderBy(
  publicationRows,
  ["publicationQty"],
  ["desc"]
);

sortedPublications.push({
  publicationName: "Total Sent",
  publicationQty: totalSent,
});
</code></pre><h3>Performance Analysis:</h3><p><strong>Code Readability and Maintainability:</strong></p><ul><li>Snippet 1 leverages functional programming, resulting in concise and expressive code. The chaining of methods enhances readability and reduces the likelihood of errors.</li><li>Snippet 2, while functional, relies on traditional iteration methods, potentially making the code less intuitive for developers unfamiliar with such practices.</li></ul><p><strong>Execution Time:</strong></p><ul><li>Snippet 1 leverages built-in array methods, which are generally optimized for performance. The use of functional paradigms can lead to better execution times, especially when processing large datasets.</li><li>Snippet 2, though functional, may exhibit slightly higher execution times due to the manual iteration and reliance on an external library for sorting.</li></ul><p><strong>Memory Usage:</strong></p><ul><li>Snippet 1 employs methods like <strong>flatMap</strong> and <strong>reduce</strong> to manipulate data without creating intermediary arrays, potentially reducing memory overhead.</li><li>Snippet 2 builds arrays incrementally, possibly leading to higher memory consumption, especially when dealing with substantial datasets.</li></ul><p><strong>Flexibility:</strong></p><ul><li>Snippet 1 is modular and can be easily adapted to different data structures or additional processing steps.</li><li>Snippet 2, though effective, may require more effort to modify or extend due to its procedural nature.</li></ul><h3>Conclusion:</h3><p>While both code snippets achieve the desired outcome, the choice between them depends on specific requirements. Snippet 1, with its functional approach, excels in readability and potential performance gains. Snippet 2, though slightly more traditional, might be preferable in situations where familiarity with conventional iteration methods is crucial.</p><p>Developers should carefully consider factors such as code readability, execution time, memory usage, and adaptability when choosing an approach. Ultimately, the decision should align with the project's objectives and the team's coding preferences.</p>

n the realm of data processing, the efficiency of code is paramount, especially when dealing with large datasets. This blog post aims to compare the performance of two code snippets designed to count and organize data from a sizable dataset. The snippets, albeit achieving the same result, implement different strategies to handle the data. We will dissect each approach, evaluating their strengths and weaknesses.

Analyzing Performance: A Comparative Study of Two Approaches for Processing Large Datasets

<p>GraphQL is a powerful query language that enables flexible data fetching, but as your application grows, optimizing data loading becomes crucial. In this blog post, we'll explore how to leverage DataLoader to efficiently batch and cache data-loading requests in a GraphQL server. Additionally, we'll address performance challenges when dealing with many-to-many relationships and demonstrate optimizations for large datasets.</p><figure class="image"><img src="https://images.unsplash.com/photo-1495592822108-9e6261896da8?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw4fHxkYXRhfGVufDB8fHx8MTcwNzE3MzE3M3ww&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@pietrozj?utm_source=DNX&amp;utm_medium=referral">Pietro Jeng</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2><strong>DataLoader: Batching and Caching</strong></h2><p>DataLoader is a utility designed to handle multiple data-loading requests efficiently. It batches requests, minimizing the number of queries sent to the database, and caches the results for improved performance. Let's consider its application within the context of a GraphQL server:</p><pre><code class="language-javascript" id="IThWQP8vL">const DataLoader = require('dataloader');

// ... Other imports ...

const server = new ApolloServer({
  // ... Other configurations ...

  context: ({ event, context }) =&gt; {
    // ... Other context configurations ...

    return {
      ...context,
      loaders: {
        iPublications: new DataLoader((keys) =&gt;
          loaders.itsPublication.batchItsPublicationPages(keys)
        ),
        // ... Other DataLoader instances ...
      },
    };
  },
});
</code></pre><p>Here, we integrate DataLoader instances into the Apollo Server context, enhancing the server's ability to efficiently load data as part of GraphQL queries.</p><h2><strong>Many-to-Many Relationships and Efficient Grouping</strong></h2><p>Dealing with many-to-many relationships, especially when grouping data, requires careful consideration. In scenarios where inquiries and publications share a many-to-many relationship, the <strong>batchItsPublicationPages</strong> function was optimized to efficiently group publications into each inquiry:</p><pre><code class="language-javascript" id="MPtfafzbp">export const batchItsPublicationPages = async (keys) =&gt; {
  // ... Database query and other configurations ...

  // Efficiently group publications by inquiry_id
  const groupedPublications = new Map();

  publications.forEach((publication) =&gt; {
    const key = publication.inquiry_id;
    if (!groupedPublications.has(key)) {
      groupedPublications.set(key, []);
    }
    groupedPublications.get(key).push(publication);
  });

  // Map the results based on the provided keys
  const filteredResults = keys.map((key) =&gt; groupedPublications.get(key) || []);

  return filteredResults;
};
</code></pre><p>By leveraging a Map to organize publications based on <strong>inquiry_id</strong> and subsequently mapping the results, we optimize the grouping process, addressing potential performance bottlenecks.</p><h2><strong>Performance Optimization for Large Datasets</strong></h2><p>When facing performance challenges with a large set of keys, the blog post highlights various optimizations, including refining SQL queries, leveraging batching, and efficiently processing data in JavaScript. Notably, the discussion addresses and optimizes the following operation:</p><pre><code class="language-javascript" id="ulHXgCov0">return keys.map((key) =&gt; publications.filter((sub) =&gt; sub.key === key));</code></pre><p>By implementing the proposed optimizations, developers can significantly improve the speed and efficiency of data-loading operations, ensuring optimal performance even with substantial datasets.</p><p>When handling 58,006 keys, the utilization of a Map structure proves significantly faster than the filter method, with execution times of 2 seconds compared to 8 seconds, respectively. This discrepancy arises from the inherent efficiency of the Map approach in contrast to the filter-based alternative. Let's delve into the pivotal distinctions:</p><p><strong>Mapping Efficiency:</strong></p><p>The Map approach involves a solitary iteration over the publications array, organizing them by inquiry_id. This constitutes an O(n) operation, where n is the length of the publications array.</p><p>On the contrary, the filter approach necessitates iterating over the complete publications array for each key, resulting in a complexity of O(n * m), where n is the length of publications, and m is the length of keys.</p><p><strong>Data Organization:</strong></p><p>The Map structure adeptly organizes publications by inquiry_id in a singular pass, mitigating redundancy and optimizing memory utilization.</p><p>Conversely, the filter approach scans the entire publications array repetitively for each key, leading to less efficient memory usage and heightened computational overhead.</p><p><strong>Algorithmic Complexity:</strong></p><p>The Map approach boasts superior algorithmic complexity, particularly advantageous when dealing with larger datasets, rendering it more scalable.</p><p>The filter approach, burdened by the need for repeated array scans for each key, incurs higher time complexity.</p><p><strong>Performance Impact:</strong></p><p>The Map approach is poised to deliver superior performance, particularly as the dataset size and the number of keys increase.</p><p>Conversely, the filter approach may result in prolonged execution times and heightened resource consumption.</p><p>In conclusion, DataLoader proves to be a valuable tool for optimizing GraphQL data loading, especially in scenarios involving many-to-many relationships and large datasets. By adopting efficient grouping strategies and addressing performance bottlenecks, developers can enhance the scalability and responsiveness of GraphQL servers.</p>

GraphQL is a powerful query language that enables flexible data fetching, but as your application grows, optimizing data loading becomes crucial. In this blog post, we'll explore how to leverage DataLoader to efficiently batch and cache data-loading requests in a GraphQL server. Additionally, we'll address performance challenges when dealing with many-to-many relationships and demonstrate optimizations for large datasets.

Optimizing GraphQL Data Loading with DataLoader and Efficient Grouping

<p>In web development, providing a seamless and user-friendly experience is crucial. One common scenario involves loading a list of blog posts and allowing users to fetch more posts with a "Load More" button. However, when users click on a blog post and then navigate back, the page often resets, and users lose their loaded content. In this blog post, we'll explore how to overcome this challenge by leveraging the power of <code>sessionStorage</code> in a Next.js application.</p><figure class="image"><img src="https://images.unsplash.com/photo-1559838536-082a0c488adf?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwyMXx8ZWZmZWN0fGVufDB8fHx8MTcwNTc5NjIxMXww&amp;ixlib=rb-4.0.3&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@okeykat?utm_source=DNX&amp;utm_medium=referral">okeykat</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Introduction</h3><p>When building dynamic pages in Next.js, it's essential to consider user interactions, especially when implementing features like paginated blog lists. By default, when users click on a blog post and then navigate back, the page resets to its initial state. To enhance this experience, we'll use <code>sessionStorage</code> to store and retrieve the blog list, along with other relevant state variables.</p><h3>Setting Up sessionStorage in useEffect</h3><p>Firstly, we'll use the <code>useEffect</code> hook to check whether there is data stored in <code>sessionStorage</code> when the component mounts. If data is found, we'll use it to set the initial state. This ensures that users see the previously loaded blog list even after navigating away from the page.</p><pre><code class="language-javascript">useEffect(() =&gt; {
  const storedList = JSON.parse(sessionStorage.getItem("postList"));
  const storedShowLoadMore = sessionStorage.getItem("showLoadMore");
  const storedPageId = sessionStorage.getItem("pageId");

  setList(storedList || props.posts);
  setShowLoadMore(storedShowLoadMore === "true" || props.showLoadMore);
  if (storedPageId) setPageId(storedPageId);
}, [props.posts, props.showLoadMore]);</code></pre><h3>Fetching and Updating Blog Lists</h3><p>Next, we'll modify the <code>fetchList</code> function to not only update the local state but also save the latest data to <code>sessionStorage</code>. This ensures that the current state is preserved, allowing users to see the complete page even after navigating away and returning.</p><pre><code class="language-javascript">const fetchList = async (pageId) =&gt; {
  setIsError(false);
  setIsLoading(true);
  try {
    const result = await getPublicPosts(pageId);
    const newList = list.concat(result.data);

    if (result.total &gt; newList.length) {
      setShowLoadMore(true);
    } else {
      setShowLoadMore(false);
    }

    setList(newList);
    
    // Save data to sessionStorage
    sessionStorage.setItem("postList", JSON.stringify(newList));
    sessionStorage.setItem("showLoadMore", showLoadMore);
    sessionStorage.setItem("pageId", pageId);
  } catch (err) {
    setIsError(true);
  }
  setIsLoading(false);
};</code></pre><h3>Conclusion</h3><p>By incorporating <code>sessionStorage</code> into our Next.js application, we've addressed the common issue of losing loaded content when users navigate back from a blog post. This approach ensures that users can seamlessly continue browsing the blog list without interruptions. While more advanced state management tools like Redux might be unnecessary in this case, <code>sessionStorage</code> proves to be a simple yet effective solution for preserving state in a Next.js application. Consider implementing this technique in your projects to create a smoother and more enjoyable user experience.</p>

In web development, providing a seamless and user-friendly experience is crucial. One common scenario involves loading a list of blog posts and allowing users to fetch more posts with a "Load More" button. However, when users click on a blog post and then navigate back, the page often resets, and users lose their loaded content. In this blog post, we'll explore how to overcome this challenge by leveraging the power of sessionStorage in a Next.js application.

All Posts