Forem: Syed Muhammad Yaseen

Why Quick Cache Implementation Creates More Problems Than It Solves: The Hidden Tech Debt Crisis

Syed Muhammad Yaseen — Wed, 30 Jul 2025 13:56:35 +0000

What I'm Going to Teach You

I'm going to show you why rushing into cache implementation without proper planning is one of the fastest ways to accumulate technical debt in your application. You'll learn the hidden complexities of cache management and how to implement caching systems that improve your codebase instead of destroying it.

By the end of this post, you'll understand:

The real cost of "quick and dirty" cache implementations
Why cache invalidation becomes exponentially harder over time
A systematic approach to cache design that prevents tech debt
Practical patterns for maintainable cache architectures
How to refactor existing problematic cache systems

Why This Matters to You

That innocent "just add some caching" feature request is about to become your biggest maintenance nightmare.

If you're a developer who's ever been asked to "just make it faster with some caching," you're walking into a minefield. Here's what happens when you implement caching without proper architecture:

Your "simple" cache becomes a web of interdependent invalidation logic
Race conditions emerge in production that never showed up in testing
Data consistency bugs multiply faster than you can fix them
New features require understanding and modifying cache behaviour everywhere
Performance improvements disappear as cache hit rates plummet
Your team spends more time debugging cache issues than building features

This isn't just a technical problem; it's a velocity killer. I've seen teams slow to a crawl because every change requires navigating a maze of cache dependencies that nobody fully understands anymore.

Why Most People Fail at Caching

Most developers fall into one of these traps when implementing caches:

❌ The "Just Store It" Approach: They cache data without considering invalidation strategies. Result: stale data everywhere.

❌ The "Cache Everything" Approach: They add caching to every function and API call. Result: a performance nightmare with no clear ownership.

❌ The "Time-Based Only" Approach: They rely entirely on TTL expiration. Result: users see outdated data and cache misses spike unpredictably.

❌ The "Frontend Cache Chaos" Approach: They implement different cache strategies across components. Result: users refresh frantically trying to see updated data.

❌ The "Copy-Paste Pattern" Approach: They duplicate cache logic everywhere it's needed. Result: inconsistent behavior and impossible maintenance.

The real issue? They don't understand that caching is a data consistency problem, not a performance optimization problem. You're essentially creating a distributed system within your application, and distributed systems are hard.

The Cache Maintenance Reality Check

Here's what implementing caching means for your codebase:

Every cached piece of data becomes a state management problem. You're not just storing data; you're creating multiple sources of truth that must stay synchronised.

When you cache user profile data, you're signing up to handle:

Profile updates from the user settings page
Profile updates from the admin panel
Profile updates from mobile apps
Profile updates from background jobs
Profile updates from third-party integrations
Bulk profile updates from CSV imports
Profile deletions and account deactivations

Each of these triggers requires cache invalidation logic. Miss one, and users see stale data. Get the order wrong, and you have race conditions.

The CRUD Cache Complexity Explosion

Let's break down what "maintaining cache" actually means:

Create Operations

Where do you put new data in the cache?
How do you handle cache key conflicts?
What happens if the cache write fails but the database write succeeds?
Do you invalidate related cache entries?

Read Operations

What's your cache miss strategy?
How do you prevent cache stampedes?
What happens when the cache returns corrupted data?
How do you handle partial cache hits?

Update Operations

Do you update the cache in place or invalidate?
How do you handle concurrent updates?
What if the cache update succeeds but the database update fails?
Which related caches need invalidation?

Delete Operations

How do you find all related cache entries to invalidate?
What happens if cache deletion fails?
Do you soft delete in cache or hard delete?
How do you handle cascading deletes?

The Frontend Cache Nightmare

Frontend caching adds another layer of complexity because, as you mentioned, "you know how users can be":

Users open multiple tabs with different cached states
Users expect real-time updates across all their devices
Users refresh pages expecting to see changes immediately
Users navigate back and expect fresh data, not stale cache
Users share links expecting others to see the same data
Users switch between mobile and desktop, expecting consistency

Getting fresh values every time is easy: just make the API call. With cache, you're now managing synchronisation across:

Component-level state
Application-level cache
Browser storage (localStorage, sessionStorage)
Service worker cache
HTTP cache headers
CDN cache layers

Each layer can get out of sync, creating a debugging nightmare.

Cache Is Not a Feature, It's Architecture

The moment you add caching to your application, you're committing to building and maintaining a distributed data consistency system.

This isn't hyperbole. Every cache is essentially a replica of your primary data with its consistency requirements, failure modes, and performance characteristics.

Treating cache as a simple "add-on" feature is like treating database design as an afterthought. It works fine for toy applications, but it becomes a crushing technical debt burden as your system grows.

Key Takeaways: Building Maintainable Cache Systems

To implement caching without destroying your codebase, focus on these principles:

• Design for invalidation first - Before caching any data, map out every possible way that data can change and plan your invalidation strategy

• Centralise cache logic - Create dedicated cache services rather than scattering cache calls throughout your codebase

• Implement cache observability - You can't maintain what you can't monitor; add metrics, logging, and debugging tools from day one

• Start with course-grained caching - Cache entire API responses or page-level data before optimising individual queries

• Use event-driven invalidation - Build a system where data changes automatically trigger appropriate cache invalidations

• Plan for cache failures - Your application must work correctly even when the cache is completely unavailable

• Document cache dependencies - Maintain clear documentation of what data depends on what cache keys

• Implement gradual rollout - Never deploy cache changes to all users at once; use feature flags and gradual rollouts

The Right Way to Approach Caching

Instead of starting with "let's cache this API call," start with these questions:

What is the data lifecycle? How is this data created, modified, and deleted?
Who owns cache invalidation? Which team/service is responsible for keeping this cache accurate?
What are the consistency requirements? Is slightly stale data acceptable, or must updates be immediate?
How will you monitor cache effectiveness? What metrics will tell you if caching is helping or hurting?
What's the fallback strategy? What happens when the cache is down, corrupted, or returning errors?

Only after answering these questions should you start thinking about implementation details like cache keys, TTL values, and storage mechanisms.

Refactoring Problematic Cache Systems

If you're already living with cache technical debt, here's how to dig out:

Phase 1: Audit and Document

Map out all existing cache implementations
Document cache dependencies and invalidation triggers
Identify the highest-pain cache maintenance areas

Phase 2: Consolidate

Extract cache logic into dedicated services
Standardise on consistent cache key patterns
Implement unified cache monitoring and debugging

Phase 3: Systematic Improvement

Replace time-based invalidation with event-driven invalidation
Add comprehensive testing for cache behaviour
Implement gradual cache warming strategies

Phase 4: Culture Change

Make cache design reviews mandatory for new features
Trainthe team on cache architecture principles
Build cache maintenance into sprint planning

Conclusion

Caching done right is one of the most powerful performance optimisations available. But caching done wrong becomes a technical debt monster that consumes your team's productivity and your application's reliability.

The difference isn't in the technology you choose; it's in respecting caching as a fundamental architectural decision that affects every part of your system.

The next time someone asks you to "just add some caching," remember: you're not just storing data, you're designing a distributed system. Treat it with the planning and respect it deserves.

Your future self, your team, and your users will thank you when your application is both fast and reliable, instead of fast and buggy.

Want to learn more about building maintainable software architectures? Follow me for deep dives into solving real-world engineering challenges without creating technical debt.

Browser Tab Leader Pattern: Stop Wasting API Calls Across Browser Tabs

Syed Muhammad Yaseen — Mon, 14 Jul 2025 11:09:13 +0000

What I'm Going to Teach You

I'm going to show you how to implement a tab leader pattern that eliminates redundant API polling across multiple browser tabs. You'll learn to build a system where only one tab handles data fetching while all others benefit from shared cache updates through localStorage and the BroadcastChannel API.

By the end of this post, you'll have a complete TypeScript implementation that:

Automatically elects a "leader" tab to handle API polling
Shares cached data across all tabs instantly
Handles edge cases like tab closure and leadership transitions
Integrates seamlessly with React and Redux/RTK Query

Why This Matters to You

Every additional API call incurs a cost and degrades the user experience.

If you're building a dashboard, admin panel, or any multi-tab application, you're likely facing this problem right now:

User opens 5 tabs of your app
Each tab polls your API every 3 minutes
Your server gets hammered with 5x the necessary requests
Your API rate limits kick in
Users see inconsistent data across tabs
Your hosting costs skyrocket

This isn't just a technical problem; it's a business problem. I've seen companies spending thousands extra per month on unnecessary API calls simply because they never implemented proper tab coordination.

Why Most People Fail at This

Most developers attempt one of these flawed approaches:

❌ The "Ignore It" Approach: They hope users won't open multiple tabs. Spoiler: they will.

❌ The "Disable Multiple Tabs" Approach: They try to prevent multiple tabs entirely. Users hate this and work around it.

❌ The "Complex WebSocket" Approach: They over-engineer with WebSockets when simple browser APIs would suffice.

❌ The "Shared Worker" Approach: They use SharedWorker, which has poor browser support and unnecessary complexity.

The real issue? They don't understand that tab coordination is a leadership problem, not a communication problem. You need one tab to be the "leader" that does the work, while others follow.

The Tab Leader Pattern Changes Everything

Here's the breakthrough insight: Treat your browser tabs like a distributed system with leader election.

Instead of each tab acting independently, you establish a hierarchy:

One leader tab handles all API polling
All follower tabs listen for updates via BroadcastChannel
Automatic failover when the leader tab closes
Shared cache in localStorage keeps everyone in sync

This pattern reduces API calls by 80-90% while improving data consistency across tabs.

Key Takeaways

By implementing this pattern, you'll achieve:

• Massive API cost reduction - Only one tab polls your endpoints, regardless of how many tabs are open

• Improved performance - No more duplicate network requests slowing down your app

• Better user experience - Consistent data across all tabs with instant updates

• Automatic failover - When the leader tab closes, another tab seamlessly takes over

• Zero configuration - The system self-organises without any user intervention

• Framework agnostic - Works with React, Vue, Angular, or vanilla JavaScript

• Production-ready - Handles edge cases like rapid tab switching and network failures

• Type-safe implementation - Full TypeScript support with proper error handling

The Complete Implementation

Let's build this step by step.

Step 1: The Core Leadership Manager

First, we need a system to elect and maintain a leader tab:

// pollingLeaderManager.ts
type Listener = (isLeader: boolean, lastPollTime: number) => void;

const CHANNEL_NAME = 'polling-leader';
const LEADER_TTL = 5000;

let isLeader = false;
const tabId = `${Date.now()}-${Math.random()}`;
let channel: BroadcastChannel | null = null;
let pingInterval: NodeJS.Timeout | null = null;
let leaderTimeout: NodeJS.Timeout | null = null;
let listeners: Listener[] = [];
let initialized = false;

export let lastLeaderPollTime = 0;

function notifyListeners() {
  listeners.forEach(listener => listener(isLeader, lastLeaderPollTime));
}

export function subscribeToLeadership(listener: Listener) {
  listeners.push(listener);
  listener(isLeader, lastLeaderPollTime);

  return () => {
    listeners = listeners.filter(l => l !== listener);
  };
}

export function initPollingLeader() {
  if (initialized) return;
  initialized = true;

  channel = new BroadcastChannel(CHANNEL_NAME);

  const sendPing = () => {
    channel?.postMessage({ type: 'ping', tabId, timestamp: Date.now() });
  };

  const becomeLeader = () => {
    if (!isLeader) {
      isLeader = true;
      lastLeaderPollTime = Date.now();
      notifyListeners();
    }
    sendPing();
  };

  const loseLeadership = () => {
    if (isLeader) {
      isLeader = false;
      notifyListeners();
    }
  };

  const handleMessage = (event: MessageEvent) => {
    if (event.data?.type === 'ping' && event.data.tabId !== tabId) {
      loseLeadership();
      resetLeaderTimeout();
    }
  };

  const resetLeaderTimeout = () => {
    if (leaderTimeout) clearTimeout(leaderTimeout);
    leaderTimeout = setTimeout(() => {
      becomeLeader();
    }, LEADER_TTL + 500);
  };

  channel.addEventListener('message', handleMessage);
  resetLeaderTimeout();

  pingInterval = setInterval(() => {
    if (isLeader) sendPing();
  }, LEADER_TTL - 1000);

  window.addEventListener('beforeunload', () => {
    channel?.close();
    if (pingInterval) clearInterval(pingInterval);
    if (leaderTimeout) clearTimeout(leaderTimeout);
  });
}

How it works:

Each tab gets a unique ID and listens to a BroadcastChannel
Leader tabs send "ping" messages every 4 seconds
If a tab doesn't hear pings for 5.5 seconds, it assumes leadership
Clean shutdown handling prevents zombie leaders

Step 2: The Polling Hook

Next, we create a React hook that handles the actual polling logic:

// useLeaderPollingEffect.ts
import { useEffect, useRef } from 'react';

const POLLING_INTERVAL = 180000; // 3 minutes
const POLLING_DEBOUNCE = 5000;
const LAST_POLL_TIME_KEY = 'last_poll_time';

function getLastPollTimeFromStorage(): number {
  const stored = localStorage.getItem(LAST_POLL_TIME_KEY);
  return stored ? parseInt(stored, 10) : 0;
}

function setLastPollTimeInStorage(time: number): void {
  localStorage.setItem(LAST_POLL_TIME_KEY, time.toString());
}

export function useLeaderPollingEffect(
  isLeader: boolean, 
  lastLeaderPollTime: number, 
  pollingFns: (() => void)[] = []
) {
  const intervalRef = useRef<NodeJS.Timeout | null>(null);

  useEffect(() => {
    if (!isLeader) {
      if (intervalRef.current) {
        clearInterval(intervalRef.current);
        intervalRef.current = null;
      }
      return;
    }

    const lastStoredPollTime = getLastPollTimeFromStorage();
    const currentTime = Date.now();
    const timeSinceLastPoll = currentTime - lastStoredPollTime;

    const delay = Math.max(0, POLLING_INTERVAL - timeSinceLastPoll);

    const runPolling = () => {
      pollingFns.forEach(fn => fn());
      setLastPollTimeInStorage(Date.now());
    };

    const timeout = setTimeout(
      () => {
        runPolling();
        intervalRef.current = setInterval(runPolling, POLLING_INTERVAL);
      },
      timeSinceLastPoll >= POLLING_INTERVAL ? POLLING_DEBOUNCE : delay
    );

    return () => {
      clearTimeout(timeout);
      if (intervalRef.current) clearInterval(intervalRef.current);
    };
  }, [isLeader, lastLeaderPollTime, pollingFns]);
}

Key features:

Only polls when the tab is the leader
Calculates smart delays based on the last poll time
Prevents rapid polling during leadership transitions
Persists timing across tab changes

Step 3: The Main Hook

Create a simple interface for components to use:

// usePollingLeader.ts
import { useEffect, useState } from 'react';
import { initPollingLeader, subscribeToLeadership } from './pollingLeaderManager';

export function usePollingLeader() {
  const [isLeader, setIsLeader] = useState(false);
  const [lastPollTime, setLastPollTime] = useState(0);

  useEffect(() => {
    initPollingLeader();
    const unsubscribe = subscribeToLeadership((isLeader, lastPollTime) => {
      setIsLeader(isLeader);
      setLastPollTime(lastPollTime);
    });

    return unsubscribe;
  }, []);

  return { isLeader, lastPollTime };
}

Step 4: Real-World Usage

Here's how to use it in your app:

// AuthorizedLayout.tsx
import { useMemo } from 'react';
import { usePollingLeader } from './usePollingLeader';
import { useLeaderPollingEffect } from './useLeaderPollingEffect';

export default function AuthorizedLayout({ children }) {
  const { isLeader, lastPollTime } = usePollingLeader();

  // Define your API calls
  const pollingFns = useMemo(() => [
    () => triggerGetAllAttributes(),
    () => triggerGetAllCustomEventsWithProperties(),
    () => triggerGetAllAttributesWithProperties(),
    () => triggerGetAllSegments(),
    () => triggerGetChannelConfig(),
  ], [/* your dependencies */]);

  // Only the leader tab will execute these
  useLeaderPollingEffect(isLeader, lastPollTime, pollingFns);

  return <div>{children}</div>;
}

Advanced Considerations

Error Handling

Add retry logic and error boundaries:

const runPolling = async () => {
  try {
    await Promise.all(pollingFns.map(fn => fn()));
    setLastPollTimeInStorage(Date.now());
  } catch (error) {
    console.error('Polling failed:', error);
    // Implement exponential backoff
  }
};

Performance Optimization

Use useMemo for polling functions to prevent unnecessary re-renders
Implement request deduplication at the API layer
Consider using requestIdleCallback For non-critical updates

Testing

Mock BroadcastChannel in your tests:

// test-utils.ts
class MockBroadcastChannel {
  addEventListener = jest.fn();
  postMessage = jest.fn();
  close = jest.fn();
}

global.BroadcastChannel = MockBroadcastChannel;

Browser Support and Fallbacks

BroadcastChannel has excellent modern browser support but consider fallbacks:

const hasSupport = typeof BroadcastChannel !== 'undefined';
if (!hasSupport) {
  // Fallback to polling in each tab
  // Or use a different communication method
}

Conclusion

The tab leader pattern is a game-changer for multi-tab applications. It's the difference between a system that scales elegantly and one that crumbles under its API requests.

The best part? Your users will never notice the complexity; they'll just experience faster, more consistent data across all their tabs while your API costs plummet.

Start with the core implementation above, then customise it for your specific use case. Your future self (and your hosting bill) will thank you.

Want to see more advanced patterns like this? Follow me for more deep dives into solving real-world frontend challenges.

Shadow DOM: The Ultimate Solution for Embedding Third-Party HTML Without CSS Conflicts

Syed Muhammad Yaseen — Mon, 14 Jul 2025 11:05:57 +0000

What You'll Learn in This Guide

By the end of this article, you'll master:

What Shadow DOM is and why it's a game-changer for web development
How to implement Shadow DOM to isolate third-party HTML content
Real-world techniques for embedding HTML templates without CSS conflicts
Advanced patterns for mobile simulation and responsive previews
Best practices for maintaining control over embedded content

Why This Matters to You (And Your Sanity)

Picture this: You've a beautiful email template builder. Users create stunning templates, and now you need to display these templates on your main platform for preview. Simple, right?

Wrong.

The moment you inject that HTML into your DOM, chaos ensues:

Your carefully crafted platform styles get overridden
The template's CSS bleeds into your UI components
Buttons break, layouts shift, and your design system crumbles
Users report bugs that seem impossible to reproduce

Sound familiar? You're not alone. This is the #1 pain point for developers building platforms that handle user-generated or third-party HTML content.

Why Most Developers Fail at HTML Isolation

The iframe trap: Most developers reach for iframes as their first solution. Sure, iframes provide perfect isolation, but they come with deal-breaking limitations:

No programmatic control over the content
Complex communication between parent and child
Mobile responsiveness nightmares
SEO and accessibility issues

The CSS namespace illusion: Others try to solve this with CSS namespacing, BEM methodologies, or CSS-in-JS solutions. These approaches are like putting a band-aid on a broken dam; they might work for simple cases, but they inevitably fail when dealing with complex, dynamic content.

The sanitisation maze: Some developers go down the rabbit hole of HTML sanitisation and CSS parsing. While important for security, this approach is fragile, performance-heavy, and often breaks legitimate styling.

Shadow DOM Is the Future of Content Isolation

Here's the truth: Shadow DOM is the web standard specifically designed to solve this exact problem. It's not just a hack or workaround; it's a fundamental browser feature that creates true style and DOM isolation.

Unlike other solutions, Shadow DOM gives you:

True encapsulation: Styles cannot leak in or out
Full programmatic control: Access and manipulate content as needed
Native browser support: No external dependencies or performance overhead
Flexible architecture: Works with any framework or vanilla JavaScript

Key Takeaways

• Shadow DOM creates isolated DOM trees that prevent CSS conflicts between your platform and embedded content

• Unlike iframes, Shadow DOM allows full programmatic control while maintaining perfect style isolation

• Mobile simulation becomes trivial when you control the viewport dimensions within the shadow root

• Performance is superior to iframe solutions since everything runs in the same document context

• Browser support is excellent, and Shadow DOM is supported in all modern browsers

• Security boundaries are maintained while allowing controlled interaction between the host and embedded content

Real-World Use Case: Email Template Preview Platform

Let me walk you through a real scenario I encountered while building an email template builder platform.

The Challenge

We have built an email template builder where users can create complex HTML templates with custom CSS. The challenge was displaying these templates on our main platform for preview without:

Breaking our existing UI components
Having template styles leak into our design system
Losing the ability to programmatically control the preview (ruling out iframes)
Creating mobile-responsive preview modes

The Shadow DOM Solution

Here's an example of implementing a robust solution using Shadow DOM:

Sure, it can be refactored even further; this is just to give an idea.

import { useRef, useEffect, useCallback } from 'react';

interface UseShadowDOMPreviewReturn {
  containerRef: React.RefObject<HTMLDivElement>;
  showPreview: () => void;
  hidePreview: () => void;
}

export const useShadowDOMPreview = (
  htmlContent: string, 
  isMobile: boolean = false
): UseShadowDOMPreviewReturn => {
  const containerRef = useRef<HTMLDivElement>(null);
  const shadowRootRef = useRef<ShadowRoot | null>(null);

  useEffect(() => {
    if (containerRef.current && !shadowRootRef.current) {
      // Create isolated Shadow DOM
      shadowRootRef.current = containerRef.current.attachShadow({ mode: 'open' });

      // Define viewport dimensions
      const mobileWidth = 375;
      const mobileHeight = 667;

      // Create isolated styles
      const styleElement = document.createElement('style');
      styleElement.textContent = `
        :host {
          all: initial;
          display: none;
          position: fixed;
          top: 0;
          left: 0;
          z-index: 9999;
          background: white;
          ${isMobile ? `
            width: ${mobileWidth}px;
            height: ${mobileHeight}px;
            left: 50%;
            top: 50%;
            transform: translate(-50%, -50%);
            border: 2px solid #ccc;
            border-radius: 20px;
            overflow: hidden;
            box-shadow: 0 10px 30px rgba(0,0,0,0.3);
          ` : `
            width: 100%;
            height: 100%;
          `}
        }

        ${isMobile ? `
          /* Mobile simulation styles */
          * {
            -webkit-text-size-adjust: 100%;
            -webkit-tap-highlight-color: transparent;
          }

          html, body {
            width: ${mobileWidth}px !important;
            height: ${mobileHeight}px !important;
            margin: 0 !important;
            padding: 0 !important;
            overflow-x: hidden !important;
            font-size: 16px !important;
          }

          button, a, input {
            min-height: 44px !important;
            min-width: 44px !important;
          }
        ` : ''}
      `;

      shadowRootRef.current.appendChild(styleElement);
    }
  }, [isMobile]);

  useEffect(() => {
    if (shadowRootRef.current && htmlContent) {
      // Clear previous content while preserving styles
      const styleElement = shadowRootRef.current.querySelector('style');
      shadowRootRef.current.innerHTML = '';

      if (styleElement) {
        shadowRootRef.current.appendChild(styleElement);
      }

      // Process HTML for mobile if needed
      let processedHtml = htmlContent;
      if (isMobile) {
        processedHtml = `
          <div class="mobile-container" style="
            width: 100%;
            height: 100%;
            overflow: auto;
            -webkit-overflow-scrolling: touch;
          ">
            ${htmlContent}
          </div>
        `;
      }

      // Inject isolated content
      const contentDiv = document.createElement('div');
      contentDiv.innerHTML = processedHtml;
      shadowRootRef.current.appendChild(contentDiv);

      // Add mobile environment simulation
      if (isMobile) {
        const script = document.createElement('script');
        script.textContent = `
          // Override window dimensions for mobile simulation
          Object.defineProperty(window, 'innerWidth', { value: 375 });
          Object.defineProperty(window, 'innerHeight', { value: 667 });
          Object.defineProperty(navigator, 'userAgent', { 
            value: 'Mozilla/5.0 (iPhone; CPU iPhone OS 14_7_1 like Mac OS X) AppleWebKit/605.1.15'
          });
        `;
        shadowRootRef.current.appendChild(script);
      }
    }
  }, [htmlContent, isMobile]);

  const showPreview = useCallback(() => {
    if (containerRef.current) {
      containerRef.current.style.display = 'block';
    }
  }, []);

  const hidePreview = useCallback(() => {
    if (containerRef.current) {
      containerRef.current.style.display = 'none';
    }
  }, []);

  return { containerRef, showPreview, hidePreview };
};

Implementation in React Component

const EmailTemplatePreview = ({ template, isMobile }) => {
  const { containerRef, showPreview, hidePreview } = useShadowDOMPreview(
    template.htmlContent, 
    isMobile
  );

  return (
    <>
      {/* Isolated preview container */}
      <div
        ref={containerRef}
        className="email-preview"
        style={{ display: 'none' }}
      />

      {/* Platform UI remains unaffected */}
      <div className="preview-controls">
        <Button onClick={showPreview}>
          Preview {isMobile ? 'Mobile' : 'Desktop'}
        </Button>
        <Button onClick={hidePreview} variant="outline">
          Close Preview
        </Button>
      </div>
    </>
  );
};

The Results: Why This Approach Wins

Perfect Style Isolation

No more CSS conflicts. Our platform styles remained pristine while email templates displayed exactly as intended. The Shadow DOM boundary acted as an impenetrable wall between the two style contexts.

Mobile Simulation Made Simple

By controlling the viewport dimensions within the Shadow DOM, we created pixel-perfect mobile previews without the complexity of device detection or responsive breakpoints.

Maintained Control

Unlike iframe solutions, we could:

Programmatically show/hide previews
Access and modify content when needed
Handle user interactions seamlessly
Implement custom loading states and error handling

Superior Performance

Everything ran in the same document context, eliminating the overhead of iframe communication and cross-frame data transfer.

Advanced Patterns and Best Practices

1. Device-Specific Simulation

const DEVICE_PRESETS = {
  'iphone-se': { width: 375, height: 667, userAgent: '...' },
  'iphone-12': { width: 390, height: 844, userAgent: '...' },
  'android': { width: 360, height: 640, userAgent: '...' }
};

// Use specific device configurations
const device = DEVICE_PRESETS['iphone-12'];
const { containerRef, showPreview } = useShadowDOMPreview(
  htmlContent, 
  true, 
  device
);

2. Event Handling Across Shadow Boundaries

useEffect(() => {
  if (shadowRootRef.current) {
    // Handle clicks within shadow DOM
    shadowRootRef.current.addEventListener('click', (e) => {
      const target = e.target as HTMLElement;
      if (target.classList.contains('close-button')) {
        hidePreview();
      }
    });
  }
}, [hidePreview]);

3. Dynamic Content Updates

const updatePreviewContent = useCallback((newContent: string) => {
  if (shadowRootRef.current) {
    const contentContainer = shadowRootRef.current.querySelector('.content');
    if (contentContainer) {
      contentContainer.innerHTML = newContent;
    }
  }
}, []);

Security Considerations

While Shadow DOM provides style isolation, remember:

Sanitize HTML content before injection to prevent XSS attacks
Use CSP headers to restrict script execution within shadow roots
Validate user-generated content even within isolated contexts

import DOMPurify from 'dompurify';

const sanitizedHtml = DOMPurify.sanitize(userHtml, {
  ADD_TAGS: ['custom-element'],
  ADD_ATTR: ['custom-attr']
});

Browser Compatibility and Fallbacks

Shadow DOM enjoys excellent modern browser support:

Chrome 53+
Firefox 63+
Safari 10+
Edge 79+

For older browsers, consider:

const hasShadowDOMSupport = 'attachShadow' in Element.prototype;

if (!hasShadowDOMSupport) {
  // Fallback to iframe or alternative solution
  return <IframePreview content={htmlContent} />;
}

Conclusion: Shadow DOM is Your Secret Weapon

Shadow DOM isn't just another web API; it's a paradigm shift in how we think about content isolation and component architecture. For developers building platforms that handle third-party HTML, email builders, widget systems, or any application requiring style isolation, Shadow DOM is not optional; it's essential.

The next time you face the challenge of embedding HTML content without CSS conflicts, remember: you don't need complex workarounds or fragile hacks. You need Shadow DOM.

Ready to implement Shadow DOM in your project? Begin with the patterns presented in this article and gradually expand to more complex use cases. Your future self (and your users) will thank you for choosing the right tool for the job.

That’s it, folks! Hope it was a good read 🚀

How to Avoid Chrome Flagging Your Web Push Notifications (And Why Most People Get It Wrong)

Syed Muhammad Yaseen — Mon, 14 Jul 2025 11:04:03 +0000

What I will teach you: How to ensure your web push notifications don’t get flagged or blocked by Chrome’s new spam detection system, using real-world testing, simple language shifts, and smart campaign practices.

Why This Matters: Chrome’s New Spam Detection System

In May 2025, Google Chrome introduced an on-device machine learning system that filters out push notifications it sees as misleading or spammy. If your message triggers this filter, users might never even see it. That means lower engagement, wasted campaigns, and lost sales, even if your notification is legit.

Chrome’s update includes a machine learning model that runs directly on Android devices, powered by Gemini and trained on both real and synthetic data. This enables Chrome to detect suspicious push content locally, making it faster and more private, as it doesn’t rely on sending user data to external servers.

When a notification is flagged, Chrome displays a warning showing the site name and gives users options to unsubscribe or view the message. The model evaluates titles, bodies, and even action button text.

Read the official blog post here: Chrome Fighting Unwanted Notifications

Additionally, Chrome’s Safety Check feature now runs automatically in the background, revoking permissions from sites users no longer visit or that send misleading messages. Users can also unsubscribe from push messages directly from the notification panel, contributing to a 30% reduction in total notifications on supported devices.

This is especially critical if you rely on push for:

Flash sales
Delivery alerts
Limited-time campaigns
Re-engagement with inactive users

Why Most People Fail at Push Notifications

Most marketers and developers test once, see it works, and assume all is good.

But Chrome’s system learns. That first message might go through, but the same message tomorrow? Blocked.

Even worse, they use language that sounds great but gets flagged — words like "FREE," "WIN," or vague titles like "Act Now" or "Delivery Alert."

My Real-World Testing Experience: What I Learned

I was helping run a push campaign for a beauty brand, and this is what I learned:

Sent: "KLEAN BEAUTY PRODUCTS ARRIVED - FREE Delivery!" — Delivered the first time
Sent it again a few hours later — Blocked
Removed the word FREE — Worked perfectly
Added back FREE — Blocked again
Tried title: "Klean Beauty to Cart Delivery!" — Still blocked (too vague)
Added a red siren emoji 🚨 to the title — Also blocked

That’s when I realised: this isn't just about what you say, it’s how you say it.

Topical Takeaway: Chrome Is Actively Filtering Your Push Content

Chrome now actively filters your push content based on wording, repetition, and user behaviour. Ignore this, and your campaign performance will tank.

7 Rules to Avoid Getting Flagged by Chrome

Avoid buzzwords: FREE, WIN, URGENT, or ACT NOW are red flags.
Don’t use vague phrasing: Titles like "to cart delivery" or "click here" confuse users and get flagged.
Don’t imitate system messages: Chrome watches for notifications that look like OS/system alerts.
Test more than once: A message working once doesn’t mean it’ll work twice.
Send to your device first: Repeatedly. If it disappears or shows a warning, change it.
Be transparent with opt-ins: Never trick users into allowing notifications.
Keep it clear and concise: "Your Klean Beauty order qualifies for delivery" works better than "Klean Beauty to Cart Delivery!"

Bottom Line: Adapt or Get Blocked

If you're sending push notifications in 2025 and not adapting to Chrome's new system, you're flying blind. Learn the rules, test smart, and keep your language honest and clear.

This small shift can mean the difference between a successful campaign and one that never even lands.

That’s it, folks! Hope it was a good read 🚀

How I Started My Software Engineering Career (and Why)

Syed Muhammad Yaseen — Mon, 14 Jul 2025 10:55:11 +0000

Some stories begin with a dramatic moment. Mine began with a PlayStation 1 and a dusty DOS computer in the early 2000s.

I was just four years old, more fascinated with Spyro and Dragon Ball than anything else. But even then, I was drawn to what made things work. The PS1 was for play, but the DOS computer? That was a mystery box I wanted to explore.

Childhood Curiosity: From Games to Geek Mode

When I was five or six years old, my father brought home a Pentium 3 PC. It wasn’t cutting-edge by any means, but to me, it felt like the future had finally arrived. I’d spend hours playing Red Alert 2, using Sega SNES emulators, and enjoying browser games on Miniclip and Y8.

Later, we got a PlayStation 2, which we had modded to run pirated games. I vividly remember buying blank DVD-RWs, downloading PS2 games via torrents, burning them, and getting to play an endless variety of titles. It was thrilling, but also a hands-on tech lesson in file formats, disc burning, and troubleshooting.

However, unlike most kids, I wasn’t just focused on gaming. I was equally curious about what made everything tick. I learned to install and customize Windows, set up software, and fix common system problems. My fun and my learning were deeply intertwined, even if I didn’t realize it then.

By the age of 10, we had a Pentium 4, and my curiosity had only grown deeper. I was in Class 4 when I made a decision that would stick with me for life:

I want to work with computers, either as a Computer Scientist or Computer Engineer.

No backup plans. No wavering.

First Encounters With Code (And Failing Fast)

In 2013, I decided to learn C++ for no particular reason other than the name sounded... powerful. It took just 2–3 days to realize I didn’t understand a thing. So I gave up.

But failure didn’t stop me. I shifted to game development using Construct 2, a drag-and-drop engine. That too didn’t last long, but each failed attempt planted a seed.

Discovering the Web: MERN, CS50 & the First Sparks

In 2017, a HackerNoon blog by Andrei Neagoie introduced me to the MERN stack. The blog linked to a Udemy course, possibly one of the best I’ve ever taken. I dived in and absorbed everything from the fundamentals of the web to Git, Heroku, APIs, and the MERN stack itself.

Unfortunately, my academic life got in the way. Grades 11 and 12 were packed with exam pressure, so I had to hit pause.

But the fire reignited in 2018 when I found Harvard’s CS50 on YouTube. Every lecture was over an hour long, but I was hooked. CS50 changed how I thought about programming and learning.

Honestly, I think every CS student should watch it before starting university. It gives you a glimpse of what's coming.

Rust, Embedded Systems, and PIAIC

In 2019, I joined PIAIC’s IoT program. They taught IoT using Rust, and later Embedded Rust. It was fascinating, but tough. I had no background in hardware or registers, and my university had just started. After completing three quarters, I had to step away due to the difficulty and lack of time.

But I did what I always do, kept moving forward.

Entering University (and Not Waiting for Graduation)

When I enrolled in a Computer Science degree in 2019, I had one goal:

Don’t wait until graduation to start your career.

I opened a LinkedIn account, followed industry leaders, and started posting my learning journey.

In 2020, during my second semester, we had a course on Java and OOP. After just a few classes, I realized the instructor would only cover the basics, slowly. So, I decided to teach myself Java.

I found a roadmap and what I believe is the best Java course online. I covered more in two weeks than the course would in four months. I dove deep, Java Core, JavaFX GUIs, APIs, and eventually Spring Boot.

Java is where my actual programming skills began to develop, where I truly understood the concepts, and learned them deeply. Practising all the time, building and sharing stuff over LinkedIn.

First Steps Into Freelancing

At the start of 2021, I jumped into freelancing via Upwork. It took two months of persistence to land my first project, changing a YouTube loader on a website. After that came a Selenium script (which I learned in four hours using Google), PDF generator with Java, Minecraft server setups on Linux, and completely random gigs that taught me a lot.

Around the same time, I joined platforms like Interns Pakistan and The Sparks Foundation, where I earned certificates for completing courses and projects. I posted everything I could on LinkedIn.

Something is better than nothing.

Applied to many places for Internship

I applied to many places for an internship, and did some interviews, but eventually failed to get into all of them. Well, of course, I was sad, but didn’t stop there.

Here’s my first-ever Resume, made with Canva lol.

Applied hundreds of times to many places, making hundreds of changes to my resume:

The Breakthrough: Nisum Internship

In May 2021, I saw a LinkedIn post from Nisum, a software services company, hiring interns. I

reached out to their employees, networked, and finally, someone forwarded my resume.

Resume:

Cover Letter:

There were three rounds:

Written Test – IQ, math, and algorithms
First Interview – 35 minutes of Core Java grilling
Final Interview – More fundamentals

I was confident, and it paid off. I was in.

Bootstrapping in the Real World

On the first day, I found myself among a group of 12 interns: some in Java, some in DevOps, some in QA. I was placed in MERN, which surprised me, but I embraced it.

My mentor, a senior engineer, didn't toss me into endless tutorials. Instead, he introduced me to HackerRank and gave me a week to sharpen my logic using JavaScript. After that, I spent about two weeks learning raw HTML and CSS.

Once I grasped the basics, I started building projects with raw HTML, CSS, and JavaScript. This experience helped me understand core concepts, such as promises beginning with callback hell, moving on to long chains of then clauses, and eventually mastering async/await, along with many other JavaScript fundamentals.

I was tasked with creating a Trello-like project using only raw HTML, CSS, and JavaScript. This experience made me appreciate the challenges that modern frameworks and libraries aim to solve. Eventually, I had to make a decision: should I choose React, Vue, or Angular?

I chose React.

Eventually, all MERN and QA interns were grouped into a project: a food ordering app to automate the office lunch system. We had three mentors, two QA teammates, and two months to deliver.

We built a full-stack MERN app, complete with custom order management and PWA mobile support. I often worked 12-hour days, it didn’t feel like work. I was building something real.

At the end of three months, I was offered a permanent position.

I had just started my 5th semester at that time. Luckily, my university was just a 10-minute ride from the office, making the commute easy.

The job required a commitment of 45 hours per week, and I covered the remaining hours on days when I didn’t have classes.

After my classes, I would come in and stay until around 11 - 12 P.M.

I am truly grateful for my supportive colleagues, as their cooperation helped me balance my studies while working full-time.

Reflection

Fast forward 4 years, my resume:

My software engineering career didn’t happen overnight.

It was a long chain of failed experiments, small wins, online communities, mentors, and a lot of curiosity. From a kid gaming on Red Alert 2 to solving real-world problems with code, this is the journey I’m proud of.

And it's just the beginning.

How I Made My Next.js Blog Serve Markdown Files for Agent Experience SEO (AX-SEO)

Syed Muhammad Yaseen — Mon, 14 Jul 2025 10:45:47 +0000

I’ll show you how to serve raw Markdown files in a Next.js blog using middleware and API routes, enabling Agent Experience SEO (AX-SEO).

AX-SEO focuses on optimizing content for AI agents, LLM-powered search engines, and automated crawlers that now play a major role in content discovery.

By the end of this post, you’ll be able to:

✅ Implement Next.js middleware for .md URL rewriting.

✅ Set up API routes to fetch and serve Markdown content.

✅ Optimize your blog for Agent Experience SEO (AI-driven search).

✅ Provide clean, structured data for AI-powered search engines.

Traditional SEO is no longer enough. AI search engines, LLM-powered assistants (ChatGPT, Perplexity, Google’s AI Overviews, etc.), and autonomous agents are now indexing and ranking content differently.

Why does AX-SEO matter?

AI agents prefer structured content – Raw Markdown is easier to parse than HTML.
LLMs use Markdown for training & retrieval – AI search engines extract structured text more efficiently.
AX-SEO improves discoverability – AI-driven platforms rank content based on how well agents can process it.

If you want your blog optimized for AI-driven search, this guide is for you!

Most blogs serve only HTML, making extracting structured information hard for AI tools. Common mistakes include:

❌ Not offering raw text formats – AI agents struggle with unnecessary markup.

❌ Ignoring structured data for LLMs – AI search engines prioritize clean content.

This guide avoids these mistakes and ensures a future-proof content strategy for AI indexing.

How I Did It

Step 1: Middleware for `.md` Routing

I used Next.js Middleware to detect .md URLs and redirect them to an API route:

import type { NextRequest } from "next/server";
import { NextResponse } from "next/server";

export function middleware(req: NextRequest) {
  const url = req.nextUrl.clone();

  if (url.pathname.endsWith(".md")) {
    url.pathname = `/api${url.pathname}`;
    return NextResponse.rewrite(url);
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/blog/:path*.md", "/projects/:path*.md"],
};

Step 2: API Route to Serve Markdown

Next, I created API endpoints to fetch Markdown content:

import { readMarkdown } from "@/server/read-markdown-file";
import { NextRequest } from "next/server";

export async function GET(_req: NextRequest, { params: { slug } }: { params: { slug: string } }) {
  return readMarkdown(slug);
}

Step 3: Fetching Markdown Content from CMS

The readMarkdown the function retrieves the raw Markdown content:

import useBlogSlug from "@/features/posts/hooks/useBlogSlug";
import { NextResponse } from "next/server";

export async function readMarkdown(slug: string) {
  try {
    const {
      post: {
        content: { markdown },
      },
    } = await useBlogSlug({ params: { slug: slug.replace(".md", "") } });

    return new NextResponse(markdown, {
      headers: {
        "Content-Type": "text/plain",
      },
    });
  } catch (error) {
    console.error("Error reading markdown file:", error);
    return new NextResponse(JSON.stringify({ message: "Markdown file not found" }), { status: 404 });
  }
}

Step 4: Adding a Markdown Link to the Blog

To make the Markdown file accessible, I added a link on each blog page:

<Link href={`/api/${params.type}/${params.slug}.md`} passHref>
  View Markdown
</Link>

Now, every post has a “View Markdown” button that links to the raw .md version.

How This Boosts Agent Experience SEO (AX-SEO)

✅ AI-Optimized Content – Markdown is easier for AI bots to read than HTML.
✅ AX-SEO Ready – AI-powered search engines prefer structured text for ranking and retrieval.
✅ Faster AI Crawling – Lightweight Markdown improves indexing speed.
✅ Better Content Extraction – LLMs can fetch raw text for RAG-based applications.
✅ Scalable & Future-Proof – Works for blogs, docs, and AI knowledge bases.

Final Thoughts

With this approach, I made my Next.js blog serve Markdown dynamically, benefiting both humans and AI bots.

📂 Source Code: GitHub Repository

🌍 Live Website: sm-y.dev

I hope this guide helps you boost your blog’s AX-SEO and AI search visibility! 🚀

Elevate Your Next.js Security: Middleware Authorization with Userfront

Syed Muhammad Yaseen — Sun, 06 Oct 2024 11:10:22 +0000

In this guide, I will show you how to secure your Next.js application with Userfront by implementing middleware-level authorization and leaving component authorization practices.

Implementing robust security measures like IAM is essential for protecting user data and maintaining compliance. This builds trust with your users and safeguards your application from potential vulnerabilities.

Many developers overlook comprehensive IAM solutions, opting for basic authentication methods that can expose their applications to significant security risks.

Key Takeaways

Explore Userfront’s features like SSO, multi-tenancy, two-factor authentication, and custom JWTs—all available with a generous free tier.
Understand the drawbacks of component-level user authorization.
Ensure middleware-level JWT verification for robust authorization.

As applications grow in complexity, robust security becomes increasingly crucial. Userfront provides a modern IAM solution that integrates seamlessly with Next.js. This guide walks you through integrating Userfront authentication, emphasizing best practices for a secure setup.

Understanding Userfront in the IAM Landscape

Userfront simplifies the authentication process for developers with its easy-to-use SDK. Key features include:

Single Sign-On (SSO): Users can log in once and access multiple applications without re-authenticating.
Multi-Tenancy: Supports multiple clients with a single Userfront account, ideal for SaaS applications.
Two-Factor Authentication (2FA): Adds an extra layer of security by requiring a second form of verification.
SOC 2 Compliance: Adheres to strict data privacy and security standards.

Learn more about Userfront here.

Getting Started with Userfront

The Project is already settled up with Userfront. Clone the repository from this link.

To learn about the fundamentals of setting up Userfront with Next.js, refer to the official documentation

https://userfront.com/docs/examples/next

Setting Up Userfront in Your Next.js Application

Environment Variables

Create a .env file in your project root:

# WorkspaceId can be found at https://userfront.com/dashboard
NEXT_PUBLIC_USERFRONT_WORKSPACE_ID="..."

# Public JWT key can be found at https://userfront.com/test/dashboard/jwt?tab=public
# Make sure to get Base64 encoded public key
JWT_PUBLIC_KEY_BASE64="..."

Project Structure

app
├── (auth)
│   ├── layout.tsx
│   ├── login
│   │   └── page.tsx
│   ├── reset
│   │   └── page.tsx
│   └── signup
│       └── page.tsx
├── (public)
│   └── home
│       └── page.tsx
├── (secure)
│   └── dashboard
│       └── page.tsx
├── _components
│   └── Header.tsx
├── globals.css
└── layout.tsx

Directory Breakdown

(auth): Contains authentication-related pages (login, signup, reset).
(public): Public-facing pages (like home) accessible without authentication.
(secure): Pages requiring authentication (like the dashboard).

Why Component-Level Authorization is Problematic

Consider this approach:

// app/(secure)/layout.tsx
"use client";

import * as React from "react";
import { useRouter } from "next/navigation";
import { useUserfront } from "@userfront/next/client";

export default function SecureLayout({ children }: { children: React.ReactNode }) {
  const router = useRouter();
  const { isAuthenticated, isLoading } = useUserfront();

  React.useEffect(() => {
    if (isAuthenticated || isLoading || !router) return;
    router.push("/login");
  }, [isAuthenticated, isLoading, router]);

  if (!isAuthenticated || isLoading) {
    return null;
  }

  return children;
}

added a console log to see how it’s going into the secure component everytime and redirects in split second:

Drawbacks

Redirects: Unnecessary redirects and allowing component access for a split second leaving security flaws and bad UX.
Insecure Logic: Client-side checks can be manipulated, exposing sensitive data.
Race Conditions: Delays in loading may expose restricted content.
Performance Issues: Unnecessary rendering can slow down your application.
Complexity: Mixing authentication logic with UI rendering complicates maintenance.
Scalability: Harder to manage as the application grows.

Implementing Middleware for Authentication

Create a middleware.ts file for JWT verification:

// middleware.ts
"use server";

import { NextRequest, NextResponse } from "next/server";
import { jwtVerify, importSPKI, JWTPayload } from "jose";

const JWT_PUBLIC_KEY_BASE64 = process.env.JWT_PUBLIC_KEY_BASE64!;
const WORKSPACE_ID = process.env.NEXT_PUBLIC_USERFRONT_WORKSPACE_ID

interface UserFrontJwtPayload extends JWTPayload {
  userId?: string;
}

async function verifyToken(token: string, publicKeyBase64: string) {
  try {
    const publicKey = await importSPKI(
      Buffer.from(publicKeyBase64, "base64").toString("utf-8"),
      "RS256"
    );
    const { payload } = await jwtVerify(token, publicKey, {
      algorithms: ["RS256"],
    });
    return payload as UserFrontJwtPayload;
  } catch (error) {
    console.log("JWT verification failed:", error);
    return null;
  }
}

const pathsToExclude = /^(?!\/(api|_next\/static|favicon\.ico|manifest|icon|static|mergn)).*$/;
const publicPagesSet = new Set<string>(["/home"]);
const privatePagesSet = new Set<string>(["/dashboard"]);
const rootRegex = /^\/($|\?.+|#.+)?$/;

export default async function middleware(req: NextRequest) {
  if (!pathsToExclude.test(req.nextUrl.pathname) || publicPagesSet.has(req.nextUrl.pathname)) {
    return NextResponse.next();
  }

  const accessToken = req.cookies.get(`access.${WORKSPACE_ID}`)?.value;
  const decoded = accessToken ? await verifyToken(accessToken, JWT_PUBLIC_KEY_BASE64) : null;
  const isAuthenticated = decoded && decoded.userId;

  if (rootRegex.test(req.nextUrl.pathname)) {
    return isAuthenticated ? NextResponse.redirect(new URL("/dashboard", req.url)) : NextResponse.redirect(new URL("/login", req.url));
  }

  if (privatePagesSet.has(req.nextUrl.pathname) && !isAuthenticated) {
    return NextResponse.redirect(new URL("/login", req.url));
  }

  if (req.nextUrl.pathname.startsWith("/login") && isAuthenticated) {
    return NextResponse.redirect(new URL("/dashboard", req.url));
  }
}

see the instant redirect in action:

Middleware Explained

Middleware processes requests before they reach routes, centralizing authentication logic. Key functions include:

JWT Verification: Ensures only authenticated users can access protected routes.
Path Exclusions: Optimizes performance by excluding public routes from authentication checks.
Redirect Logic: Manages user redirection based on authentication status.

Conclusion

By following these steps, you can effectively secure your Next.js application with Userfront's IAM capabilities. Middleware enhances security, ensuring only authorized users access sensitive routes while providing a seamless user experience.

For more details on the Userfront and its features, visit the Userfront documentation. With Userfront’s generous free tier, you can explore advanced features like SSO, multi-tenancy, and more without any initial investment.

That’s it! I hope you found this guide helpful. 🚀

Feel free to follow me on GitHub and LinkedIn for more guides.

GitHub

Stay awesome and happy coding! ✨

Maximize Vercel's FREE Plan: Enable Auto Deployment for All Members

Syed Muhammad Yaseen — Mon, 30 Sep 2024 03:07:44 +0000

Earlier, Vercel's free pricing plan allowed multiple members to commit changes that would automatically deploy. However, this feature has recently changed, and now only the project creator can trigger deployments.

To enable this feature for each additional member, a fee of $20 will be charged.

Bypass the Charge with a GitHub Action

You can create a GitHub Action that performs an empty commit, triggering Vercel to deploy automatically. Here’s how:

Step 1: Create the Workflow File

Inside your repository, navigate to the .github/workflows directory. If the workflows folder doesn't exist, create it.
Add a file named auto-empty-commit.yml.

Step 2: Add the Script

Paste the following code into auto-empty-commit.yml:

name: Auto Empty Commit

on:
  push:
    branches:
      - 'master' # Trigger on pushes to the master branch
      # - '**' # Uncomment to trigger on pushes to any branch

permissions:
  contents: write # Allow write access to repository contents

jobs:
  empty_commit:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2

      - name: Get the Latest Commit Branch
        id: get_branch
        run: echo "branch=$(git rev-parse --abbrev-ref HEAD)" >> $GITHUB_ENV

      - name: Create Empty Commit
        run: |
          git config --local user.name "example" # Replace with your name
          git config --local user.email "example@example.com" # Replace with your email
          git commit --allow-empty -m "Auto commit after push"
          git push origin ${{ env.branch }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Customization

Branch Configuration: Modify the on.push.branches section to specify which branch will trigger this action.
Git User Configuration: Update the Git user name and email in the Create Empty Commit step with the credentials of the member who created the project on Vercel.

Final Steps

Commit your changes and push them to your repository.
Now, when a commit is made, the action will create an empty commit, triggering Vercel to deploy automatically.

You’ll know the deployment status by the commit icons: a cross ❌ indicates the deployment failed, while a check ✅ shows successful deployment.

Conclusion

That’s it! I hope you found this guide helpful. 🚀

Feel free to follow me on GitHub and LinkedIn for more JavaScript tips and tricks!

GitHub

Stay awesome and happy coding! ✨

4 Ways to Destructure Array in JavaScript & make your code look clean

Syed Muhammad Yaseen — Sun, 11 Aug 2024 09:56:00 +0000

Helloooooooo! 🎉

I hope you're doing awesome! This is SMY! 👋 Today, we're diving into some cool JavaScript magic with array destructuring! 🚀

📜 Contents:

⚡ Wait What?
⚡ But Why?
⚡ But How?
1️⃣ Destructuring Arrays Chronologically
2️⃣ Destructuring Arrays by Index
3️⃣ Destructuring Arrays within Objects
4️⃣ Destructuring Arrays with Dynamic Indexes

⚡ Wait What?

Array destructuring is a neat feature in JavaScript that allows you to extract values from arrays (or properties from objects) into distinct variables. It’s not just for making your code look cool—it’s about writing cleaner, more readable code. Let’s break down how you can destructure arrays in different ways!

⚡ But Why?

Destructuring makes your code more concise and expressive. Instead of accessing array elements by their indices, you can directly extract the values into variables. This can simplify your code, reduce errors, and make it easier to understand.

⚡ But How?

Let’s walk through each method of array destructuring with some examples!

1️⃣ Destructuring Arrays Chronologically

This is the most straightforward way to destructure arrays. You match variables to array elements in the order they appear.

const fruits = ['apple', 'mango', 'banana'];
const [apple, mango, banana] = fruits;

console.log(apple); // apple
console.log(mango); // mango
console.log(banana); // banana

How It Works:

The fruits array contains three elements.
Using [apple, mango, banana], we destructure the array into three variables, each corresponding to an element in the array, in the same order.

2️⃣ Destructuring Arrays by Index

In JavaScript, you can't directly destructure arrays by index within the array literal itself, but you can achieve similar results with a little workaround using Object.entries or by manually setting values.

const fruits = ['apple', 'mango', 'banana'];
const {0: apple, 1: mango, 2: banana} = fruits;

console.log(apple); // apple
console.log(mango); // mango
console.log(banana); // banana

How It Works:

Here, we use a syntax that mimics destructuring by treating array indices as keys. This is more of a workaround since destructuring by indices isn't directly supported, but the idea is to align array elements with variables through indices.

3️⃣ Destructuring Arrays within Objects

You can also destructure arrays that are nested within objects. This allows you to target specific elements in nested structures.

const fruitsPerSeason = {
  summer: ['grapes', 'pineapple'],
  winter: ['kiwis', 'oranges']
};

const { summer: [grape, pineapple], winter: [kiwi, orange] } = fruitsPerSeason;

console.log(grape); // grapes
console.log(pineapple); // pineapple
console.log(kiwi); // kiwis
console.log(orange); // oranges

How It Works:

fruitsPerSeason is an object where each property is an array.
By destructuring within the object, we extract specific elements from these arrays into distinct variables.

4️⃣ Destructuring Arrays with Dynamic Indexes

For a more dynamic approach, you can combine destructuring with variables that hold indices.

const fruitsPerSeason = {
  summer: ['pineapple', 'grapes'],
  winter: ['kiwis', 'oranges']
};

const pineappleIdx = 0, kiwisIdx = 0;
const { summer: [_, pineapple], winter: [_, kiwis] } = fruitsPerSeason;

console.log(pineapple); // pineapple
console.log(kiwis); // kiwis

How It Works:

Here, we’re using _ as a placeholder to ignore the first elements and destructure only the elements we need based on dynamic indices (though indices themselves aren't dynamically used in this example).

Wrapping Up:

Destructuring arrays can streamline your JavaScript code, making it cleaner and more expressive. Whether you're extracting values chronologically, targeting specific indices, or working within objects, these techniques help you handle arrays more efficiently.

That’s it, folks! Hope you found this breakdown of array destructuring helpful and insightful. 🚀

Feel free to follow me on GitHub & LinkedIn for more JavaScript tips and tricks!

GitHub

Stay awesome and happy coding! ✨

Automate Your Git Workflows with Git Hooks 🚀

Syed Muhammad Yaseen — Sun, 28 Jul 2024 10:10:00 +0000

Helloooooooo!

Hope you're doing great! This is SMY! 👋 Let's Jump right in 🚀

....

I've settled up an example commit-msg hook that on every commit

↳ checks for branch name convention i.e [type]/ABC-[ticketnumber]-[objective]

↳ checks for commit-msg convention i.e [ABC-ticketnumber] [type]: objective

↳ checks for lints, prettier, and run unit tests

Gist Link: https://gist.github.com/smyaseen/17083d60d02a07b2a3122410e2d39b6f

.....

1️⃣ What -

↳ Git hooks are scripts that run automatically whenever a particular event occurs in a Git repository.

↳ They let you customize Git’s internal behaviour and trigger customizable actions at key points in the development life cycle.

↳ There are local hooks and server-side hooks.
↳ Local hooks run on your machine and server-side on the remote repository.

local hooks:

↳ pre-commit
↳ prepare-commit-msg
↳ commit-msg
↳ post-commit
↳ post-checkout
↳ pre-rebase

server hooks:

↳ pre-receive
↳ update
↳ post-receive

2️⃣ Why -

↳ For example, you want to run Lint checks before files are committed, so we use the pre-commit hook.

↳ another example you want to enforce the standard branch name and commit-msg convention, so we use the commit-msg hook.

↳ and lots more...

3️⃣ How -

↳ For easy setup, in a JavaScript project, install a library called Husky and follow the documentation

https://www.npmjs.com/package/husky

↳ An example is that I want to enforce branch names, commit message convention, and run lint, prettier, and tests.

↳ We can use multiple hooks. In my case, I will add a commit-msg hook. The reason I haven't chosen pre-commit was that it doesn't check for commit-msg as it runs before commit. I don't want a developer to run checks and fail at commit message, fix, and run all again. I want to check for the commit message first.

↳ Create a commit-msg hook, following husky's documentation, and paste the following example:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# Checks for branch name


currentBranch=$(git rev-parse --abbrev-ref HEAD)
requiredPattern="^(build|chore|feat|docs|refactor|perf|test)/ABC-\d+-.+$"

if ! echo "$currentBranch" | grep -qE $requiredPattern; then
    echo "\nInvalid branch name: $currentBranch"
    echo "-"
    echo "Should follow this pattern: build|chore|feat|docs|refactor|perf|test/ABC-ticketnumber-any-text"
    echo "-"
    echo "example: docs/ABC-123-update-readme.md"
    echo "-"
    echo "Refer to this for convention:"
    echo "-"
    echo "build : Changes related to building the code (e.g. adding npm dependencies or external libraries)."
    echo "-"
    echo "chore: Changes that do not affect the external user (e.g. updating the .gitignore file or .prettierrc file)."
    echo "-"
    echo "feat: A new feature."
    echo "-"
    echo "fix: A bug fix."
    echo "-"
    echo "docs: Documentation a related changes."
    echo "-"
    echo "refactor: A code that neither fix bug nor adds a feature."
    echo "-"
    echo "perf: A code that improves performance style: A code that is related to styling."
    echo "-"
    echo "test: Adding new test or making changes to existing test"
    echo "-\n"

    exit 1  # Branch name doesn't match the pattern, exit with error code
fi

# Checks for commit message

commit_message="$(cat "$1")"

pattern='^\[ABC-[0-9]+\] (build|chore|feat|docs|refactor|perf|test): .+$'

if [[ ! $commit_message =~ $pattern ]]; then
    echo "\nInvalid commit message: $commit_message"
    echo "-"
    echo "Should follow this pattern: [ABC-ticketnumber] build|chore|feat|docs|refactor|perf|test: objective"
    echo "-"
    echo "example: [ABC-15] chore: updated .gitignore"
    echo "-"
    echo "Refer to this for convention:"
    echo "-"
    echo "build : Changes related to building the code (e.g. adding npm dependencies or external libraries)."
    echo "-"
    echo "chore: Changes that do not affect the external user (e.g. updating the .gitignore file or .prettierrc file)."
    echo "-"
    echo "feat: A new feature."
    echo "-"
    echo "fix: A bug fix."
    echo "-"
    echo "docs: Documentation a related changes."
    echo "-"
    echo "refactor: A code that neither fix bug nor adds a feature."
    echo "-"
    echo "perf: A code that improves performance style: A code that is related to styling."
    echo "-"
    echo "test: Adding new test or making changes to existing test"
    echo "-\n"
  exit 1
fi


# npx lint-staged -- uncomment when have lint setted up
# npm run test -- uncomment when have test setted up

↳ Now, whenever you commit, it will check for branch and commit naming convention along with running lint checks. Finally, it will run tests in the end, after everything else is good to go.

4️⃣ Result -

✨ Consistency.
✨ Standardization.
✨ Mind Off the Trivial.
✨ Automate & Focus on Impactful.

Wrapping Up:

We just Elevated Your Development Workflow with a Git Hooks. 🚀

.....

Now you can supercharge your development workflow 🚀

That's it, folks! I hope it was a good read for you. Thank you! ✨

👉 Follow me

GitHub

Elevate Your Development Workflow with GitHub PR Templates! 🌟

Syed Muhammad Yaseen — Tue, 23 Jul 2024 04:59:47 +0000

Helloooooooo!

Hope you're doing great! This is SMY! 👋 Let's Jump right in 🚀

....

I've gathered and put together an Extensive PR Template! Feel free to tailor it further to align with your style.

Template Link: https://lnkd.in/djHD24pH

.....

1️⃣ What -

PR templates offer a visual snapshot for reviewers to quickly grasp the essence and state of a pull request. Imagine your team diving into a PR and instantly comprehending its purpose, changes, and necessary actions. That's the magic of a well-structured template.

2️⃣ Why -

Reason 1: Mind Off the Trivial, Focus on Impactful

Say goodbye to mental juggling! Templates serve as a self-checklist, eliminating the need to wrack your brain over remembering small yet crucial details. Instead, channel that mental energy towards crafting exceptional code and solving complex challenges.

Reason 2: Living Documentation

Treat your PR template as a living, breathing document that captures the essence of each change. It's not just about the present; it's a reference point for the future. Easily traceable and understandable, it becomes a valuable resource for anyone peeking into the history of your codebase.

But wait, there's more! 🌟

Reason 3: Consistency & Standardization

With PR templates, maintain consistency across your project repositories. Whether you're working on bug fixes, feature enhancements, or other changes, ensure a uniform approach that aligns with your team's best practices.

Reason 4: Enhanced Communication

These templates aren't just for code; they foster better communication within your team. Express your intentions, highlight potential issues, and open the floor for meaningful discussions—all in one structured format.

Reason 5: Effortless Onboarding

Simplify onboarding for new team members by providing a clear blueprint for creating effective pull requests. It's like having a welcome mat that guides them through the team's established processes.

3️⃣ How -

Create a custom template with Markdown, and name it "PULL_REQUEST_TEMPLATE.md"
Paste the following example:

## Description

<!--
Please do not leave this blank
This PR [adds/removes/fixes/replaces] the [feature/bug/etc].
-->

## What type of PR is this? (check all applicable)

- [ ] 🍕 Feature - A new feature.
- [ ] 🐛 Bug Fix - self-explanatory
- [ ] 📝 Documentation Update - Documentation and related changes.
- [ ] 🎨 Style - Changes that do not affect the meaning of the code; for example, white space, formatting, or missing semicolons.
- [ ] 🧑‍💻 Code Refactor - A code that neither fixes a bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name).
- [ ] 🔥 Performance Improvements - A code change that improves performance.
- [ ] ✅ Test - Added | Modified | Removed tests
- [ ] 🤖 Build - Changes related to code building (e.g. adding npm dependencies or external libraries).
- [ ] 🔁 CI - Changes that affect the build CI/CD pipeline
- [ ] 📦 Chore - Changes that do not affect the external user (e.g. updating the .gitignore file or .prettierrc file).
- [ ] ⏩ Revert - self-explanatory

## Related Tickets & Documents

## Mobile & Desktop Screenshots/Recordings

<!-- Visual changes require screenshots -->

## Quality Checklist

- [ ] 👷‍♀️ Created small PR.
- [ ] 👴🏻 No deprecated or outdated code is introduced
- [ ] 💭 Code is self-documenting. Comments are unnecessary and should only be used to explain why a decision was made
- [ ] 🗒️ Methods are documented with JS Doc including description, params, and return type
- [ ] 📋 The commit message follows our guidelines
- [ ] 👌 The pull request description explains any decisions or trade-offs made regarding code quality and design
- [ ] 🔖 The branch follows our naming guidelines

## Self Checklist

- [ ] 👓 I have followed the style guidelines of this project
- [ ] 🤳 I have performed a self-review of my code
- [ ] 🏷️ I have correctly labelled PR & added Ticket Number
- [ ] 🙆‍♂️ I have cleared the Acceptance Criteria
- [ ] ⚠️ My changes generate no new warnings

## Added tests?

- [ ] 👍 yes, new and existing unit tests pass locally with my changes
  - [ ] ♻️ had to make changes to existing tests
- [ ] 🥹 no, because I need help
  - [ ] ⏮️ some existing tests are failing
- [ ] ⌛ no time to add tests
- [ ] 🙅 no, because they aren't needed

## Added to documentation?

- [ ] 📜 README.md
- [ ] 📝 Confluence
- [ ] 🙅 no documentation needed

## [optional] Are there any post-deployment tasks we need to perform?

## [optional] What gif best describes this PR or how it makes you feel?

Head to your GitHub repository, select the default branch and make a .git folder at the root.
Put the template in the folder and commit changes.
Now, every time someone makes a PR, the template will appear.

Wrapping Up:

We just Elevated Your Development Workflow with a GitHub PR Template. 🚀

.....

Now you can supercharge your development workflow 🚀

That's it, folks! I hope it was a good read for you. Thank you! ✨

👉 Follow me

GitHub

Seamlessly Transform Your Smart Phone into a Second Screen for FREE with Zero Configuration: Experience Seamless Multitasking!

Syed Muhammad Yaseen — Sat, 13 Jul 2024 12:22:41 +0000

Helloooooooo!

Hope you're doing great! This is SMY! 👋 Let's Jump right in 🚀

Although there are other options like physically connecting with adapters or purchasing software like Duet. But, if you're like me, you would want a seamless Just Work solution and have a second screen setup in no time.

That's where Deskreen comes into play! Follow the steps to easily set up your screen.

Wrapping Up:

We just did the steps to Connect our Screen for Streaming on the Phone's browser. 🚀

.....

Now you can Experience Seamless Multitasking 🚀

That's it, folks! I hope it was a good read for you. Thank you! ✨

👉 Follow me

GitHub

Forem: Syed Muhammad Yaseen

Why Quick Cache Implementation Creates More Problems Than It Solves: The Hidden Tech Debt Crisis

What I'm Going to Teach You

Why This Matters to You

Why Most People Fail at Caching

The Cache Maintenance Reality Check

The CRUD Cache Complexity Explosion

Create Operations

Read Operations

Update Operations

Delete Operations

The Frontend Cache Nightmare

Cache Is Not a Feature, It's Architecture

Key Takeaways: Building Maintainable Cache Systems

The Right Way to Approach Caching

Refactoring Problematic Cache Systems

Conclusion

Browser Tab Leader Pattern: Stop Wasting API Calls Across Browser Tabs

What I'm Going to Teach You

Why This Matters to You

Why Most People Fail at This

The Tab Leader Pattern Changes Everything

Key Takeaways

The Complete Implementation

Step 1: The Core Leadership Manager

Step 2: The Polling Hook

Step 3: The Main Hook

Step 4: Real-World Usage

Advanced Considerations

Error Handling

Performance Optimization

Testing

Browser Support and Fallbacks

Conclusion

Shadow DOM: The Ultimate Solution for Embedding Third-Party HTML Without CSS Conflicts

What You'll Learn in This Guide

Why This Matters to You (And Your Sanity)

Why Most Developers Fail at HTML Isolation

Shadow DOM Is the Future of Content Isolation

Key Takeaways

Real-World Use Case: Email Template Preview Platform

The Challenge

The Shadow DOM Solution

Implementation in React Component

The Results: Why This Approach Wins

Perfect Style Isolation

Mobile Simulation Made Simple

Maintained Control

Superior Performance

Advanced Patterns and Best Practices

1. Device-Specific Simulation

2. Event Handling Across Shadow Boundaries

3. Dynamic Content Updates

Security Considerations

Browser Compatibility and Fallbacks

Conclusion: Shadow DOM is Your Secret Weapon

How to Avoid Chrome Flagging Your Web Push Notifications (And Why Most People Get It Wrong)

Why This Matters: Chrome’s New Spam Detection System

Why Most People Fail at Push Notifications

My Real-World Testing Experience: What I Learned

Topical Takeaway: Chrome Is Actively Filtering Your Push Content

7 Rules to Avoid Getting Flagged by Chrome

Bottom Line: Adapt or Get Blocked

How I Started My Software Engineering Career (and Why)

Childhood Curiosity: From Games to Geek Mode

First Encounters With Code (And Failing Fast)

Discovering the Web: MERN, CS50 & the First Sparks

Rust, Embedded Systems, and PIAIC

Entering University (and Not Waiting for Graduation)

First Steps Into Freelancing

Applied to many places for Internship

The Breakthrough: Nisum Internship

Bootstrapping in the Real World

Reflection

How I Made My Next.js Blog Serve Markdown Files for Agent Experience SEO (AX-SEO)

How I Did It

Step 1: Middleware for .md Routing

Step 2: API Route to Serve Markdown

Step 3: Fetching Markdown Content from CMS

Step 4: Adding a Markdown Link to the Blog

Step 1: Middleware for `.md` Routing