DEV Community: Maaz Khan

Bypassing Shadow DOMs & Same-Origin Iframes: How I Solved LinkedIn's Massive SDUI Update

Maaz Khan — Fri, 10 Jul 2026 22:43:34 +0000

Imagine waking up to see the browser extension you spent months building, refining, and scaling completely break overnight.

That is exactly what happened to my extension, JobEasyApply. For months, job seekers used it to autofill job applications on LinkedIn. Then, in a single day, LinkedIn rolled out a massive frontend update.

Suddenly:

None of our selectors could find form fields.
Clicks programmatically dispatched to buttons did absolutely nothing.
Even when text fields seemed to be filled, form validators acted as if they were completely blank.

LinkedIn had transitioned their Easy Apply flow to a Server-Driven UI (SDUI) architecture.

Here is a look at the engineering challenges this update created, how we diagnosed the structural changes, and the conceptual strategies we used to keep the extension running.

An Industry-Wide Shakeup: A Shared Struggle

This update wasn't just a minor tweak to a few CSS classes. It was a complete paradigm shift in how LinkedIn handles form components.

Almost overnight, the entire job-search automation ecosystem was hit:

LazyApply, JobCopilot, and other major players in the automated application space suddenly started throwing errors, getting stuck on pages, or failing to fill fields correctly.
User reviews across the Chrome Web Store for multiple tools saw a sudden spike in reports of "it's not clicking the next button anymore" or "it fills the first page and hangs."

When platforms roll out major security or framework updates like Server-Driven UI, it forces extension developers to re-think how they interact with the DOM. Tools that relied on static selectors or simple browser macros broke instantly. To survive, we had to build a much deeper, framework-aware automation engine.

The Challenge: Isolation & Hidden Contexts

When we inspected the new page structure, we noticed something wild. The "Easy Apply" modal was no longer a simple division in the main DOM. Instead, it was rendered inside a same-origin iframe, and within that iframe, elements were partitioned behind Shadow DOMs.

This creates two massive hurdles for traditional web scraping/automation scripts:

Shadow DOM Isolation: Standard query selectors like document.querySelectorAll('input') cannot cross shadow boundaries. If an input lives inside a shadow root, it is invisible to the main document.
Iframe Partitioning: Querying from the global document context doesn't search inside <iframe> elements. You must access the iframe's internal document context explicitly.

If your extension cannot "see" the fields, it cannot fill them. Here is how we conceptually bypassed these isolation layers.

Strategy 1: The Shadow & Iframe-Aware Traversal Engine

To find form elements anywhere on the page, we had to replace simple query selectors with a custom traversal engine.

Instead of searching the static document tree, our engine uses a recursive tree-walking algorithm that performs the following steps:

Check Main Document: First, search the standard DOM tree for the target element.
Probe Shadow Roots: If an element has a shadow root (element.shadowRoot), recursively descend into it and run the selectors inside the shadow tree.
Traverse Same-Origin Iframes: If the engine encounters an <iframe>, it safely checks if it belongs to the same origin. If it does, the engine accesses its document (contentDocument), grabs its root element, and recursively searches inside it.

This recursive approach creates an "X-ray vision" effect, allowing the extension to locate elements nested multiple levels deep inside shadow roots and nested iframes seamlessly.

Strategy 2: Resolving the Context Trap

Once we located the form fields, we ran into a second, subtler issue. When checking labels or resolving relationships (such as locating a label associated via aria-labelledby), the script would fail to locate the target elements.

The problem was that the code was using the global document object to query IDs. However, since the elements lived inside an iframe, their IDs existed in the iframe's document, not the parent window's document.

To solve this, we bypassed the global document entirely. Whenever we query for associated labels or related inputs, we resolve the query relative to the target element's actual document context by targeting the element's parent document owner:

$$\text{Target Context} = \text{Element} \rightarrow \text{ownerDocument}$$

Looking up elements relative to their true owner document ensures that the query context automatically scales to the correct iframe, regardless of how deep it is nested.

Strategy 3: Bypassing React/Ember State Handlers with Event Emulation

Finding the elements was only half the battle. When we set inputs programmatically using standard JavaScript assignments (element.value = "New Delhi"), the text would appear on screen, but clicking the "Next" button resulted in validation errors claiming the field was empty.

Modern frontend frameworks like React or Ember intercept user inputs. They listen to events like input, change, and blur to update their internal virtual DOM and component state. If you change the element value directly, the framework's internal state remains blank.

To bypass this, we had to simulate the entire sequence of events a human performs when interacting with a form:

For Standard Text Fields:

Focus: Put cursor focus on the target element.
Update Value: Modify the value using the element's native prototype setter (bypassing the framework's interceptors).
Notify Framework: Dispatch a sequence of bubbles-enabled events:
1. input — triggers React/Ember's real-time state changes.
2. change — updates the form model.
3. blur — signals that the user has moved to the next field.

For Autocomplete / Typeahead Dropdowns:

Autocomplete fields are even more complex. Typing the value isn't enough; the suggestion list must appear, and the extension must select a valid item. Our strategy:

Clear the field and focus on it.
Type character-by-character with a small delay to simulate typing rhythm.
Fire keyup events to trigger search.
Wait for the listbox dropdown to appear inside the shadow root or iframe.
Traverse the list options, calculate matching scores against the target value, and simulate a click on the best candidate.

Strategy 4: Simulating Clicks on SDUI Buttons

Finally, even buttons wouldn't click with a simple click method. Because of SDUI's pointer listeners, we had to dispatch a complete pointer lifecycle event pipeline.

Instead of just triggering .click(), we dispatch:

pointerdown
pointerup
mousedown
mouseup
click

By sending the entire pointer lifecycle to the button, the framework's handlers are successfully triggered, and the form transitions to the next step.

The Takeaway

By shifting from static page selectors to a recursive, scope-aware, and event-emulated traversal model, we kept the extension running smoothly.

If you are building browser extensions or automation tools, the key takeaway is simple: Do not rely on the global document context or simple element click hooks. As more platforms shift towards server-driven UI, open shadow roots, and nested iframes, your automation must adapt by becoming dynamic, recursive, and deeply event-driven.

Try It Out

If you are looking for an Easy Apply assistant that stays updated and successfully navigates these new layouts, check out our Chrome Web Store page:

👉 JobEasyApply — AI Auto Apply for LinkedIn

How I Built a Suite of 8 AI Tools with $0/Month in API Costs Using NVIDIA NIM

Maaz Khan — Fri, 19 Jun 2026 10:13:02 +0000

jobeasyapply.com/blog/how-i-built-8-ai-tools-for-0-dollars-with-nvidia-nim

Building a SaaS is hard; driving traffic to it is even harder.

Paid ads for career keywords are notoriously expensive, often costing anywhere from $2 to $5 per click. For a bootstrapped indie hacker, that's a quick way to run out of money before you even find product-market fit.

To solve this for our platform, JobEasyApply, we decided to build a suite of 8 free AI career tools (ATS resume checkers, interview prep assistants, cover letter generators, etc.) to act as an SEO and utility marketing engine.

But free AI tools are a double-edged sword. If they go viral or get indexed by bots, a spike in traffic can translate to hundreds of dollars in LLM API costs overnight.

Here is the exact engineering stack, Python code, and Redis Lua rate-limiting setup we use to host and run all 8 tools for $0/month in infrastructure and API costs while serving thousands of active users.

The Core Challenge: LLM API Costs vs. Virality

Free tools are the top of our funnel. When a user runs their resume through our Free ATS Resume Checker, our backend:

Parses the raw PDF/Word document text.
Cross-references it against a job description.
Scores match accuracy, scans for missing keywords, and compiles improvement tips.

Because parsing and semantic analysis require high intelligence and a large context window, lightweight 8B models don't cut it. We needed a heavy-hitting model like Llama 3.3 70B Instruct or Nemotron 70B.

If we paid standard token rates on OpenAI or Anthropic for this volume of free traffic, we would have gone broke in weeks. We needed a model that was:

Fast (low time-to-first-token).
Intelligent enough for resume analysis.
Free or heavily subsidized for developer experimentation.

Enter NVIDIA NIM (NVIDIA Inference Microservice)

NVIDIA NIM provides optimized API endpoints for open-weights models running on their infrastructure.

For developers, they offer free API keys with a highly generous rate-limit quota. Since we wanted top-tier reasoning for ATS scoring, we chose meta/llama-3.3-70b-instruct and nvidia/llama-3.3-nemotron-super-49b-v1 as our primary engines.

To make this architecture robust enough for production traffic under free quotas, we had to solve two main problems:

API Key Limits: Handling rate limits (HTTP 429) dynamically without interrupting user sessions.
Abuse & Scraping: Blocking bot traffic and spam aggressively at the IP level.

Here is how we implemented the solutions.

1. The Dual-Key Failover Client (Python / FastAPI)

To maximize our free quota and handle heavy spikes in traffic, we built a dual-key failover client.

If our primary NVIDIA API key hits a rate limit (HTTP 429) or throws a connection error, the client catches the exception and immediately falls back to a secondary key. If that key also fails, it down-shifts to our secondary fallback model.

Here is the Python implementation in our FastAPI backend:

import json
import logging
from openai import OpenAI

logger = logging.getLogger(__name__)

NVIDIA_BASE_URL = "https://integrate.api.nvidia.com/v1"
NVIDIA_MODELS = [
    "meta/llama-3.3-70b-instruct",              # Primary: Best reasoning & speed
    "nvidia/llama-3.3-nemotron-super-49b-v1"    # Fallback: Resilient secondary
]

def call_nvidia(system_prompt: str, user_prompt: str, api_keys: list[str]) -> dict | None:
    """
    Call NVIDIA NIM with dual-key + multi-model failover.
    Tries each model with each key before giving up.
    Returns parsed JSON dict or None on failure.
    """
    if not api_keys:
        logger.warning("No NVIDIA API keys configured")
        return None

    for model in NVIDIA_MODELS:
        for i, key in enumerate(api_keys):
            try:
                # Initialize standard OpenAI client pointed at NVIDIA's endpoint
                client = OpenAI(base_url=NVIDIA_BASE_URL, api_key=key)
                response = client.chat.completions.create(
                    model=model,
                    messages=[
                        {"role": "system", "content": system_prompt},
                        {"role": "user", "content": user_prompt},
                    ],
                    temperature=0.15,
                    max_tokens=2048,
                )
                content = response.choices[0].message.content or ""

                # Clean up LLM output if it wraps response in markdown code blocks
                content = content.strip()
                if content.startswith("```

"):
                    first_newline = content.index("\n")
                    content = content[first_newline + 1:]
                if content.endswith("

```"):
                    content = content[:-3]
                content = content.strip()

                # Return the structured JSON response
                parsed = json.loads(content)
                logger.info(f"NVIDIA success: model={model}, key=#{i+1}")
                return parsed

            except json.JSONDecodeError as e:
                logger.error(f"NVIDIA {model} key #{i+1}: JSON parse error: {e}")
                continue
            except Exception as e:
                err_str = str(e)
                if "404" in err_str:
                    logger.warning(f"Model {model} not available (404), skipping model")
                    break  # Skip to next model, don't waste time trying other keys
                logger.error(f"NVIDIA {model} key #{i+1} failed: {e}")
                continue

    return None

2. Atomic Sliding Window Rate Limiting (Redis + Lua)

Free API keys have limits. To prevent scraping scripts and bots from draining our quotas, we enforce a strict limit: 5 requests per hour per IP address for public endpoints.

Using a simple counter in Redis (like INCR with an EXPIRE time) creates a vulnerability: if a user makes 5 requests in the final second of an hour, they can immediately make 5 more in the first second of the next hour (a spike of 10 requests in 2 seconds).

To prevent this, we use a rolling sliding window implemented with a Redis Sorted Set (ZSET).

The Race Condition Problem

If you check the size of the sorted set, delete old keys, and add a new timestamp in multiple round-trips from Python, two concurrent requests from the same user can execute in parallel, bypass the count checks, and execute both actions.

To make the rate check 100% atomic, we run the entire check on the Redis server using a Lua Script:

-- Redis Lua script for sliding window rate limiting
local key          = KEYS[1]
local window_start = tonumber(ARGV[1])
local now          = tonumber(ARGV[2])
local limit        = tonumber(ARGV[3])
local window       = tonumber(ARGV[4])

-- 1. Remove timestamps older than our 1-hour sliding window
redis.call('ZREMRANGEBYSCORE', key, 0, window_start)

-- 2. Count active requests within the window
local count = redis.call('ZCARD', key)
if count >= limit then
    return 0 -- Deny request (limit reached)
end

-- 3. If under limit, add current request timestamp and refresh expiration
redis.call('ZADD', key, now, tostring(now))
redis.call('EXPIRE', key, window)
return 1 -- Allow request

FastAPI Route Middleware

Here is how we integrate this Lua script into our FastAPI endpoints:

import time
import redis
from fastapi import APIRouter, HTTPException, Request

# Connect to Redis
redis_client = redis.Redis.from_url("redis://localhost:6379", decode_responses=True)

# Register the Lua script
_rate_limit_script = redis_client.register_script(_RATE_LIMIT_LUA)

RATE_LIMIT = 5
RATE_WINDOW = 3600 # 1 hour in seconds

def check_rate_limit(ip: str) -> bool:
    """Atomic Redis rate limiter (sliding window)."""
    key = f"rate_limit:free_tools:{ip}"
    now = time.time()
    window_start = now - RATE_WINDOW
    try:
        result = _rate_limit_script(
            keys=[key],
            args=[window_start, now, RATE_LIMIT, RATE_WINDOW],
        )
        return bool(result)
    except Exception as e:
        # Fail-open to protect UX if Redis experiences hiccups
        logger.error(f"Redis rate limit failed: {e}")
        return True

3. Client-Side Browser Automation (Saving Hundreds in Server Bills)

The free tools optimize the resumes, but once they are ready, users want to auto-apply to matching roles on LinkedIn.

Running browser automation (Puppeteer, Playwright, or Selenium) on cloud servers is incredibly expensive. You need raw CPU cores to render chromium pages, and you must purchase residential proxy pools to bypass LinkedIn's bot detection.

We solved this with a hybrid architecture:

Cloud for LLM Reasoning: Parsing and scoring happen on our backend via NVIDIA NIM.
Local Client for Action Execution: The actual auto-apply click-actions run inside a Chrome Extension on the user's local machine.

Because the extension runs in the user's active browser, it utilizes their own residential IP and active LinkedIn session cookies. This keeps their account completely safe from bot detection and eliminates the need for us to pay for expensive cloud browser instances and residential proxies.

The $0/Month Economic Breakdown

By combining cloud free tiers, static hosting, and NVIDIA NIM, our operational costs are exactly $0.00 / month:

Service	Role	Cost
NVIDIA NIM	Llama 3.3 70B & Nemotron Inference	`$0.00` (Free Dev Quota)
Vercel	Next.js Frontend & SEO Landing Page hosting	`$0.00` (Hobby Tier)
Oracle Cloud	FastAPI backend & Redis container host	`$0.00` (Always-Free Tier)
Total	Running 8 free AI tools in production	`$0.00`

Wrap Up

If you are bootstrapping a SaaS in 2026, utility marketing via free tools is one of the most effective ways to build an organic traffic engine.

Instead of treating LLM API calls as a cost center, you can shift the work to developer-friendly microservices like NVIDIA NIM, wrap them in failover loops, protect them with Redis Lua rate limiters, and offload browser heavy-lifting to local Chrome extensions.

Have any questions about the Redis Lua setup or the failover loop? Ask in the comments below!

Feel free to check out the project live at JobEasyApply or explore our open-source browser automation codebase on GitHub:

👉 GitHub Repository: maazkhanxo/jobeasyapply-linkedin-auto-apply

I Was Tired of Applying to 100+ Jobs Manually. So I Built an AI to Do It for Me.

Maaz Khan — Thu, 11 Jun 2026 11:27:59 +0000

The job hunt in 2026 is broken.

You spend hours editing your resume, searching through LinkedIn, and filling out the exact same form fields over and over again. And then comes the worst part: writing custom paragraphs answering "Why should we hire you?" or "Describe your experience with React" for the 50th time.

Only to get ghosted.

As a developer, I couldn't stand the repetition anymore. We automate deployments, tests, and code reviews—so why are we still applying to jobs like it's 2010?

I decided to build an automated solution: JobEasyApply. Here is how it works and the tech stack behind it.

🛠️ The Tech Stack

I wanted the tool to be fast, secure, and run in the background without needing my browser window to remain open. Here is what I chose:

Frontend: React & Next.js for a sleek, responsive dashboard.
Chrome Extension: Vanilla JavaScript to securely sync session cookies (like li_at for LinkedIn) to the server so the backend can apply on the user's behalf.
Backend Workers: Python Celery tasks running on a background server to handle job crawling, resume parsing, and auto-filling questionnaires.
AI Engine: Groq / NVIDIA LLMs to read the form questions and match them with the user's resume content to write custom, high-scoring responses.

⚙️ How It Works (Under the Hood)

1. Resume Parsing & Scoring

When a user uploads a resume, the backend extracts their core skills, years of experience, and achievements. When the crawler finds a job listing, the AI reads the job description and generates a compatibility score. If the score is high, it gets queued.

2. The Auto-Apply Automation

Instead of running a heavy headless browser like Puppeteer for hours on my local machine (which burns CPU), we use a Chrome Extension to sync session cookies.

This lets our backend worker do the heavy lifting in the cloud. It simulates the application network requests directly, injecting custom, AI-generated answers for the employer's screening questions based on the candidate's actual resume.


javascript
// A peak into how our frontend wizard coordinates the steps:
const STEPS = [
  { key: "resume", icon: "📄", title: "Upload Your Resume" },
  { key: "linkedin", icon: "🔗", title: "Connect LinkedIn" },
  { key: "preferences", icon: "🎯", title: "Job Preferences" },
  { key: "groq", icon: "🤖", title: "AI API Key" },
];

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sog630n81ny0dnesed8t.png)