Forem

How MongoDB Executes a find() Query: A Complete Lifecycle Guide

MongoDB Guests — Thu, 23 Apr 2026 08:30:25 +0000

This article was written by Darshan Jayarama.

When you type something like db.orders.find({ status: "pending", customerId: 1042 }) and the results come back in milliseconds, it feels simple… almost instant.

But behind that one line, MongoDB is doing a lot more than just “searching a collection.”

During my time as a Senior TSE at MongoDB, I spent most of my days deep in query performance and indexing issues, working closely with both customers and the engineering team. It may look simple, but internally, a lot is happening when a find() executes.

Most engineers understand it at a surface level. But once you start digging into what actually happens under the hood, that’s when things change. You begin to see why some queries are fast, why others are painfully slow, and how indexes truly make or break performance.

So let’s break it down — step by step — what really happens inside MongoDB when a query runs. No shortcuts, nothing skipped.

The full journey of a `find()` query (quick overview)

Before we go step by step, here’s the big picture. Every find() query goes through a series of steps in the mentioned order.

There are also two “fast paths” (shown as green arrows):
• When MongoDB can reuse a plan from the plan cache
• When the data is already in memory (WiredTiger cache)

Getting your queries to use these fast paths is what good MongoDB performance tuning is all about.

Stage 1: The Client Sends a Query Over the Wire

Before MongoDB even sees your query, your driver prepares it.

Whether you’re using PyMongo, the Node.js driver, or mongosh, your query is converted into BSON (a binary version of JSON) and sent over a network connection to MongoDB.

MongoDB uses the Wire Protocol to communicate, which is basically a structured way of sending messages between your app and the database.

Since MongoDB 3.6, most operations use a format called OP_MSG.

This message includes:
• which database and collection you’re querying
• the actual filter (your query conditions)
• extra options like projection, sort, limit, skip, hints, and read preferences

# PyMongo serializes this to BSON OP_MSG internally

db.orders.find(
   { "status": "pending", "customerId": 1042 },
   projection={"_id": 0, "amount": 1},
   sort=[("createdAt", -1)],
   limit=10
)

The query lands at the mongod process. The network listener accepts the connection and hands it off to a worker thread from the connection pool.

Stage 2: Authentication Check

The first thing MongoDB does — even before looking at any data — is check who is making the request.

MongoDB supports different ways to authenticate users, but in most real-world cases, this step is already handled. Drivers usually keep connections open and authenticated, so this check happens almost instantly

MongoDB just verifies the session linked to that connection.

If authentication fails, the query stops right there.
You’ll see an error like: “Authentication failed”, and the query never even reaches the database engine.

Stage 3: Authorization — Can You Read This Collection?

Authentication tells MongoDB who you are. Authorization decides what you’re allowed to do. MongoDB uses role-based access control (RBAC). It checks whether your user has permission to run a find() on that specific database and collection.

This could come from built-in roles like read or readAnyDatabase, or from custom roles with specific permissions.

If you don’t have access, the query stops there. You’ll see an error like: “not authorized to execute command”. The good part? This check is extremely fast — it’s just a quick in-memory lookup, not a database scan.

Stage 4: Query Parsing and BSON Validation

At this point, your query is sitting in memory as a BSON document. Now MongoDB starts understanding it.

It does two main things:

1. Checks if the query is valid

MongoDB makes sure your query is written correctly — valid operators like $eq, $in, $gt, $elemMatch, proper structure, and no invalid combinations. If something is wrong, the query fails right here with an error.

2. Converts it into an internal format:

MongoDB rewrites your query into a standard internal structure (think of it like a tree). This is why the order of fields doesn’t matter.

For example, these two are treated exactly the same:
{ a: 1, b: 2 }
{ b: 2, a: 1 }

Internally, MongoDB sees it more like:

AND
├── status = "pending"
└── customerId = 1042

In short, MongoDB first checks that your query is valid, then rewrites it into a format it can efficiently work with.

Stage 5: The Query Planner Enumerates Candidate Plans

This is where MongoDB actually starts making smart decisions. The query planner takes your parsed query and determines the best way to get the data. It doesn’t just pick one way — it tries out multiple options.

For every useful index, MongoDB creates a possible plan. It also always keeps one backup option: scanning the whole collection (COLLSCAN).

Each plan is basically a step-by-step approach to fetch the data.

For example:

Using index on status:

 FETCH
  └─ scan index { status: 1 }
Using index on customerId:
 FETCH
  └─ scan index { customerId: 1 }
Using compound index (status + customerId):
 scan index { status:1, customerId:1 }
 (no FETCH needed — everything is in the index)
No index:
 scan entire collection

MongoDB also thinks about a few important things here:
• Can it avoid sorting by using an index?
• Can it return results directly from the index (covered query)?
• Can it combine multiple indexes if needed?

In short, MongoDB tries different ways to run your query and prepares multiple plans before choosing the best one.

Stage 6: Plan Cache Lookup — The Fast Path

Before MongoDB tries out different plans, it first checks something called the plan cache.

The plan cache stores the best plan from previous runs of similar queries. So if MongoDB has already seen a query like yours before, it can skip all the extra work and reuse the same plan.

What matters here is the query shape — basically the structure of the query, not the actual values.

For example, these two queries are treated the same:

db.orders.find({ status: "pending", customerId: 1042 })

db.orders.find({ status: "shipped", customerId: 9999 })

Because structurally, they are identical:
{ status: <eq>, customerId: <eq> }

Now two things can happen:
• Cache hit → MongoDB already knows the best plan, so it skips all the trial work and runs it directly (this is the fast path)
• Cache miss → MongoDB doesn’t have a saved plan, so it tries multiple options to find the best one

A few important things to know about the plan cache:
• It’s stored in memory (not on disk)
• It’s maintained per collection
• It gets cleared when MongoDB restarts
• It’s also reset if the indexes change or the collection changes a lot

You can even inspect or clear it manually:

// See cached plans
db.orders.getPlanCache().list()
// Clear cache (forces MongoDB to re-evaluate plans)
db.orders.getPlanCache().clear()

In short, if your query has been seen before, MongoDB can skip straight to execution — which is why repeated queries are usually much faster 🚀

Stage 7: Multi-Plan Trial — The Index Race

If MongoDB doesn’t find a plan in the cache, it tries something really interesting.

Instead of guessing the best plan, it tests all possible plans simultaneously. This is called the multi-plan stage.

Each plan is given a chance to run for a few steps, one after the other — kind of like a race.

For example:
Round 1:
Plan A → small progress
Plan B → small progress
Plan C → small progress

Round 2:
Plan A → more progress
Plan B → more progress
Plan C → more progress

This continues until one plan clearly outperforms the others.

The winner is the plan that:
• returns the first ~100 results fastest, or
• finishes scanning the data quickest

Once a plan wins, MongoDB:
→ uses it for the current query
→ saves it in the plan cache for next time

What about full collection scans (COLLSCAN)?

They usually lose… but not always.

• If there are no useful indexes → COLLSCAN wins
• If the collection is very small → COLLSCAN can actually be faster than using an index

If you want to see how this decision was made, you can run:

db.orders.find({ status: "pending", customerId: 1042 })
        .explain("allPlansExecution")

Stage 8: Index Scan (IXSCAN) or Collection Scan (COLLSCAN)

Now that MongoDB has picked the best plan, it finally executes the query.

If an index is used (IXSCAN)

MongoDB uses indexes that work like a tree structure. It quickly navigates this tree to find matching entries.

Once it finds a match, it uses a reference (called RecordId) to go and fetch the actual document from the collection.

Think of it like:
— find the entry in the index
— then go grab the full document

There’s also something called a covered query: If all the fields you need are already in the index, MongoDB doesn’t even need to look at the actual documents.

It returns results directly from the index
This is the fastest possible way to read data

If no index is used (COLLSCAN)

If there’s no useful index, MongoDB has no choice — it reads every document one by one.

So if your collection has 10 million documents, it will scan all 10 million.

That’s definitely slow.

How to spot a problem

When you run explain(), watch for this:

db.orders.find({ status: "pending" }).explain("executionStats")
// Red flags to look for:
// "stage": "COLLSCAN"          ← no index used
// "totalDocsExamined": 9847321  ← scanned 9.8M docs
// "nReturned": 142              ← returned only 142
// Ratio: 69,000:1               ← extremely inefficient

Red flags:

"stage": "COLLSCAN" → no index is being used
Very high "totalDocsExamined"
Very low "nReturned"
scanned ~9.8 million documents
returned only 142

That’s a huge gap, and a clear sign your query is inefficient

Simple rule
If MongoDB is reading way more documents than it returns, you probably need a better index.

Stage 9: The Storage Layer — WiredTiger Cache and Disk

Once MongoDB knows which documents it needs, the next question is: Where does it actually read the data from?

There are three possible sources, and the speed depends on where the data is found.

1. WiredTiger cache (in-memory — fastest)
MongoDB uses WiredTiger as its storage engine, which keeps frequently accessed data in memory.

By default, it uses about 50% of the available RAM.

If the required data is already in this cache, MongoDB can return it almost instantly. This is the ideal scenario.

2. OS page cache (still fast)
If the data is not in MongoDB’s own cache, it checks the operating system’s page cache.

The OS may already have the data in memory from recent reads. Since MongoDB memory-maps its data files, this check is efficient.

This is slightly slower than the WiredTiger cache, but still very fast.

3. Disk (slowest)
If the data is not present in either cache, MongoDB has to read it from disk.

The performance here depends on the type of storage:

NVMe SSD: fastest among disks
SATA SSD: moderate
HDD: significantly slower

At scale, disk access becomes the main bottleneck, especially when queries access data randomly across large datasets. If your working data set fits in memory, queries remain fast. If MongoDB frequently needs to read from disk, query performance drops significantly. This is why working set size is critical in MongoDB performance tuning — your frequently accessed data should ideally fit in RAM.

Checking cache performance

You can inspect cache behavior using:

db.serverStatus().wiredTiger.cache
// 'pages read into cache'       ← total cache misses (disk reads)
// 'pages requested from cache'  ← total requests
// Hit ratio = 1 - (read/requested)
// Target: > 95%

Key metrics:

pages read into cache → disk reads (cache misses)
pages requested from cache → total requests

A good system typically has a cache hit ratio above 95%.

Stage 10: Results Returned to the Client

Here’s what happens:

Applies projection: Removes any fields you didn’t ask for and keeps only what’s needed
Applies skip and limit: Skips the first N documents (if specified) and limits how many results are returned
Converts back to BSON: Turns the in-memory document into a format that can be sent over the network
Creates response batches: MongoDB doesn’t send everything at once. The first batch contains up to 101 documents or 16MB of data (whichever comes first)
Sends the response: The data is sent back to your application over the same connection

What if there’s more data?

If your query returns more than one batch, MongoDB doesn’t send everything in one go.

Instead, it returns a cursor ID.

Your driver then automatically requests the next batch using getMore commands. This happens behind the scenes, so you usually don’t notice it.

The Complete Picture — All 10 Stages

Closing notes: Key Takeaways for Production

Always check your explain() output - Use explain("executionStats") to see exactly how your query ran — which plan was used, how many documents were scanned vs returned, and whether the plan came from cache.
Design indexes based on query patterns, not just fields -Think about how your queries are written. For example, a compound index like { status: 1, customerId: 1 } is usually much more effective than having separate indexes on each field. It can even avoid extra steps like fetching documents if the query is covered.
Keep an eye on cache efficiency - Monitor your WiredTiger cache hit ratio. If it drops below ~90%, it usually means your frequently accessed data no longer fits in memory. At that point, you may need to add more RAM, shard the data, or rethink how your application accesses data.
Be aware of plan cache issues - If a query suddenly becomes slow after something like a bulk insert, the plan cache might be the cause. MongoDB may have picked a suboptimal plan after re-evaluating. In such cases, clear the cache and check the query again with explain().

// Your daily driver for query diagnostics
db.orders.find({ status: "pending" }).explain("executionStats")

// Key fields to read:
// executionStats.executionTimeMillis    ← total time
// executionStats.totalDocsExamined      ← docs touched
// executionStats.totalKeysExamined      ← index keys scanned
// executionStats.nReturned              ← docs returned
// queryPlanner.winningPlan.stage        ← IXSCAN or COLLSCAN

How ORBIT Solves the Langflow CVE‑2026‑33017 Vulnerability

Sam — Thu, 23 Apr 2026 08:26:14 +0000

In March 2026, a critical flaw in Langflow (CVE‑2026‑33017) was exploited in the wild within 20 hours of disclosure. Attackers hijacked agent workflows, injected malicious code, and exfiltrated sensitive data. The root cause? Ungoverned MCP tool execution.

This isn't an isolated incident. The OWASP Foundation just released the MCP Top 10—and schema poisoning (MCP‑01) and tool output tampering (MCP‑02) top the list.

Here's how ORBIT—a sovereign, self‑hosted governance platform—would have blocked the Langflow attack at three layers.

🔴 What Happened with Langflow

Langflow allows users to build AI workflows by connecting "components" (tools) via a drag‑and‑drop interface. The vulnerability allowed an attacker to inject a malicious component definition that executed arbitrary code on the server.

The failure chain:

No validation of component schemas
No sanitization of tool outputs
No audit trail to trace the breach

🛡️ How ORBIT's MCP Gateway Would Have Prevented It

1. Strict Schema Validation (OWASP MCP‑01)

ORBIT's mcp_gateway.py enforces a JSON schema on every registered tool. Malformed or malicious definitions are rejected before they ever reach the agent.


python
# ORBIT rejects this immediately
malicious_tool = {"name": "evil", "description": "..."}  # missing required 'input_schema'
validate_tool_definition(malicious_tool)  # ❌ ValueError
2. Secret Detection & Redaction (OWASP MCP‑05)
Even if a tool somehow executed, ORBIT scans all outputs for high‑confidence secret patterns (OpenAI keys, AWS tokens, etc.) and redacts them in real‑time.

python
output = "API_KEY=sk-1234567890abcdef"
sanitized = sanitize_tool_output(output, "some_tool")
print(sanitized["data"])  # "API_KEY=[REDACTED_OPENAI_API_KEY]"
3. Tamper‑Proof Audit Trail
Every tool invocation is logged with a SHA‑256 hash, timestamp, and agent ID in audit.jsonl. Security teams can instantly query:

bash
cat dot_orbit/audit.jsonl | jq 'select(.event == "mcp_tool_invoked")'
📊 ORBIT vs. The Alternatives
Feature ORBIT   Microsoft AGT   Langflow (Patched)
MCP schema validation   ✅ ✅ ✅ (post‑CVE)
Output secret redaction ✅ ❌ ❌
Stateful budget controls    ✅ ❌ ❌
Self‑hosted / sovereign   ✅ ✅ ✅
🚀 Get Started
ORBIT is open‑source and runs entirely on your hardware.

👉 GitHub: highriseliving777/orbit
🎥 Demo (90 sec): Watch on YouTube
  
  

If you're building AI agents, don't wait for the next CVE. Govern them now.

Follow for more agentic security deep dives. Next up: "Stateful Budgets – Why Microsoft AGT Issue #42 Still Matters."

The Hidden Attack Surface of Modern Cloud Apps in the Age of AI

Sreekari M — Thu, 23 Apr 2026 08:20:48 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Building on the cloud has never been easier. With platforms like Google Cloud, developers can deploy scalable applications, integrate AI, and ship features faster than ever before.

But beneath this convenience lies a growing problem.

Speed and abstraction come at a cost: a rapidly expanding attack surface that few fully understand.

Modern cloud applications aren’t just bigger - they’re more interconnected, more dynamic, and far more exposed than they appear. In the age of AI-driven integrations, the gap between what developers build and what they actually secure is widening faster than ever.

What “Attack Surface” Means in Modern Cloud Applications

Traditionally, an application’s attack surface was relatively straightforward - open ports, exposed servers, and known network entry points. Security efforts focused on hardening these boundaries which included configuring firewalls, patching systems, and restricting direct access.

But in modern cloud environments, that definition no longer holds.

Today, an application is not a single system but a collection of interconnected services. APIs expose functionality to the outside world, identity and access management (IAM) systems control permissions, serverless functions execute code in response to events, and third-party integrations extend capabilities beyond the core application.

Each of these components introduces its own set of entry points, many of which are not immediately visible.

In this context, the attack surface is no longer just about infrastructure. It includes every API endpoint, every permission granted through IAM, every external service connected to the application, and every automated process that runs behind the scenes.

The challenge is that these elements are often abstracted away by cloud platforms like Google Cloud, making it easier to build systems, but harder to fully understand where the risks lie.

As a result, the modern cloud attack surface is not only larger, but also more distributed and harder to detect. And to understand where the real risks emerge, it’s necessary to look at the individual layers that make up this hidden surface.

The Hidden Layers of the Cloud Attack Surface

1. APIs: The Front Door That Never Closes
Unlike traditional entry points, APIs are designed to be accessible, often exposed over the internet and expected to handle requests at scale. This makes them one of the largest and most persistent components of the attack surface.

Weak authentication mechanisms, improper validation of inputs, and lack of rate limiting can turn APIs into easy targets. Even when authentication is implemented, improperly scoped tokens or predictable endpoints can allow attackers to enumerate resources or gain unauthorized access.

In many cases, APIs are treated as purely functional components that are built for performance and usability, while security becomes an afterthought. The result is an entry point that is always open, constantly in use, and often insufficiently protected.

2. IAM: The Most Dangerous Misconfiguration
If APIs are the front door, identity and access management (IAM) is the system that decides who gets in and what they can do once inside.

In cloud environments, IAM replaces traditional perimeter-based security with identity-driven access control. Every service, user, and application interacts based on assigned roles and permissions.

The problem arises when these permissions are overly broad. Developers often grant more access than necessary for the sake of convenience, unintentionally violating the principle of least privilege. Service accounts may be given administrative roles, tokens may carry excessive permissions, and access policies may not be regularly audited.

This creates a dangerous scenario: even a small compromise such as a leaked token, can lead to privilege escalation and widespread access across the system.

In platforms like Google Cloud, IAM is powerful and flexible, but that flexibility also makes it one of the most common sources of security risk.

3. Serverless & Managed Services: The Illusion of Safety
One of the biggest advantages of cloud platforms is the ability to offload infrastructure management. Serverless functions and managed services allow developers to focus purely on code, without worrying about servers, scaling, or maintenance.

However, this convenience can create a false sense of security.

While the underlying infrastructure is managed, the logic, configurations, and triggers that control these services are still the developer’s responsibility. Misconfigured event triggers, overly permissive execution roles, or insecure function logic can all introduce vulnerabilities.

Additionally, the ephemeral nature of serverless systems makes them harder to monitor. Functions spin up and shut down dynamically, leaving limited visibility into their behavior. This makes detecting misuse or abnormal activity significantly more challenging.

The result is an environment that feels secure by design, but can still expose critical weaknesses if not carefully managed.

4. Third-Party & AI Integrations: The New Weak Link
Modern applications rarely operate in isolation. They rely heavily on third-party services for functionality right from payment processing to analytics, and increasingly, AI-powered features.

These integrations expand the capabilities of an application, but they also extend its attack surface beyond its original boundaries. API keys, access tokens, and sensitive data are often shared with external systems, creating new trust relationships that are difficult to fully control.

In the age of AI, this risk becomes even more pronounced. Applications are now integrating with external models and tools that process user inputs and data, sometimes with limited visibility into how that data is handled.

A compromised third-party service, an exposed API key, or a misconfigured integration can provide attackers with indirect access to critical systems. Unlike traditional vulnerabilities, these risks do not originate within the application itself but from the ecosystem it depends on.

These external dependencies are becoming one of the most significant and least understood components of the modern attack surface.

Security at the Speed of AI

The common thread connecting these layers is velocity.

In the pre-AI era, security could often be addressed at the deployment stage. Today, that is a recipe for failure. With the rise of AI agents, your application is no longer a static collection of code; it is a dynamic, evolving environment that changes based on the data it consumes.

The insight here is that visibility is the new perimeter. You cannot secure what you cannot see, and in a cloud environment where microservices spin up and down, static security audits are insufficient. The "hidden" nature of these risks comes from the fact that they often exist in the connections between services - the IAM policies, the API integrations, and the data flows, rather than in the services themselves.

An Attack Story: The "SmartAssist" Compromise

To understand how this looks in practice, let’s look at a scenario: SmartAssist.

SmartAssist is a customer support application running on Google Cloud. It uses a serverless backend to process user queries and leverages a third-party AI model to generate responses.

1. The Entry: An attacker discovers that the API endpoint for SmartAssist is vulnerable to indirect Prompt Injection. By crafting a malicious support ticket, they trick the AI into returning the underlying system instructions.

2. The Escalation: These system instructions reveal the name of a Cloud Storage bucket used for logs. Because the developers configured the serverless function with a broad "Storage Admin" role (violating the principle of least privilege), the attacker successfully uses the prompt injection to manipulate the application into executing a command to list the bucket’s contents.

3. The Exfiltration: The bucket contains API keys for a third-party analytics service. The attacker steals these keys, pivots to the analytics platform, and begins exfiltrating the entire user database.

In this story, there was no "hack" in the traditional sense, no firewall was breached, and no server was compromised. Instead, the attacker abused the intended functionality of the integrated components. The security failure happened in the design of the IAM roles and the lack of validation at the API layer.

The Solution: A Zero Trust, Defense-in-Depth Approach

Securing this modern surface requires moving away from the idea that the cloud is "secure by default." Instead, we must embrace a Zero Trust architecture where every request is treated as hostile until proven otherwise.

To mitigate the risks outlined above, consider a framework like this:

1. Enforce Granular Identity (IAM): Use Workload Identity to ensure that your applications and services act with the absolute minimum permissions required. Never use default service accounts.

2. Validate at the Edge: Implement Google Cloud Armor to protect your API endpoints. Use WAF rules to filter out malicious traffic and rate limiting to prevent enumeration attacks.

3. Implement a Policy Decision Point (PDP): As your system scales, centralize access control. A PDP can evaluate the context of every request—the user's identity, the device's security posture, and the sensitivity of the data, before allowing the API to trigger a compute function.

4. Data Loss Prevention (DLP): Use the Cloud DLP API to automatically redact or mask sensitive data before it reaches your AI models. This ensures that even if an attacker successfully prompts the AI to "leak" information, they are only accessing scrubbed data.

Security as a Feature

The "hidden" attack surface is not a bug in cloud computing; it is a byproduct of the incredible agility that the cloud provides.

We cannot expect to stop the advancement of AI or the interconnected nature of modern applications. Instead, we must change our perspective. Security is not an "add-on" that comes after the code is written. In the age of AI, security is a fundamental feature of the architecture.

By moving away from perimeter-based defenses and toward identity-centric, Zero Trust models, developers can embrace the power of the cloud without sacrificing the safety of their users. The "hidden" surface only remains dangerous if we choose not to look at it. Once we map it, secure it, and monitor it, it becomes just another layer in a robust, resilient system.

Graph Algorithms for Coding Interviews: When to Use BFS, DFS, or Dijkstra

Alex Mateo — Thu, 23 Apr 2026 08:12:38 +0000

Graphs are the most feared topic in coding interviews — not because they're impossible, but because most people learn BFS, DFS, and Dijkstra in isolation without understanding when to use each one.

This guide gives you the decision framework that turns graph problems from guesswork into a systematic process.

The three algorithms every interviewer expects you to know

BFS — Breadth-First Search

Data structure: Queue (FIFO)
Complexity: O(V + E) time, O(V) space

Use when:

You need the shortest path in an unweighted graph
You need the minimum number of steps to reach a target
You need to explore nodes level by level

Don't use when: the graph has weighted edges — BFS treats all edges as equal cost.

Classic problems: Binary Tree Level Order Traversal, Rotting Oranges, Word Ladder, Shortest Path in Binary Matrix.

Interview tip: Always say explicitly: "I'm using BFS because I need the shortest path in terms of edges, and BFS guarantees the first time I reach a node it's via the shortest path." That sentence shows you understand the why, not just the how.

DFS — Depth-First Search

Data structure: Stack (implicit via recursion, or explicit)
Complexity: O(V + E) time, O(V) space

Use when:

You need to detect cycles
You need to find all paths (not just shortest)
You need to check connectivity or count connected components
You need topological sort

Don't use when: you need the shortest path — DFS doesn't guarantee it.

Classic problems: Number of Islands, Course Schedule, Clone Graph, Pacific Atlantic Water Flow.

Interview tip: The most common DFS bug is forgetting to mark nodes as visited before recursing. Always set visited[node] = true at the start, before processing neighbors.

Dijkstra's Algorithm

Data structure: Min-heap (priority queue)
Complexity: O((V + E) log V) time, O(V) space

Use when:

The graph has weighted edges with non-negative weights
You need the shortest distance from source to target (or all nodes)

Don't use when: the graph has negative edge weights — use Bellman-Ford instead.

Classic problems: Network Delay Time, Path With Minimum Effort, Cheapest Flights Within K Stops.

Interview tip: The Dijkstra pattern is always the same: push (cost, node) to the heap → pop cheapest → skip if visited → process neighbors. Know O((V+E) log V) and be able to explain why.

The decision framework

When you see a graph problem, run through this before writing a single line of code:

Signal	Algorithm	Reason
Unweighted graph, need shortest path	BFS	Expands level by level — first reach = shortest
Minimum number of steps / hops	BFS	"Steps" = edges = unweighted
Weighted graph, all weights ≥ 0	Dijkstra	Greedy expansion via min-heap
Weighted graph with negative edges	Bellman-Ford	Dijkstra's greedy assumption breaks
Cycle detection	DFS	Track visited + in-stack state
All paths, not just shortest	DFS + backtracking	BFS doesn't enumerate all paths
Connected components / flood fill	DFS or BFS	Either works — DFS simpler recursively
Topological sort	DFS or Kahn's BFS	DFS post-order = reverse topological order

The single question to ask first: "Does the graph have weights?"

No → choose between BFS (shortest path) and DFS (full exploration)
Yes → Dijkstra (non-negative) or Bellman-Ford (negative weights)

That question narrows the decision from three options to two in almost every case.

What interviewers actually look for

Senior interviewers rarely test whether you can implement BFS from scratch. They test whether you can reason about graph problems systematically.

What separates strong candidates:

Clarifying the graph structure before coding. Directed or undirected? Weighted or unweighted? Can there be cycles? These change the algorithm — asking shows you're not pattern-matching blindly.
Explaining why you chose the algorithm. "I'm using BFS because the graph is unweighted and I need minimum steps" is a complete answer. "I'll use BFS" is not.
Recognizing implicit graphs. Many problems don't say "graph" — they present a grid, a word transformation, a dependency list. Rotting Oranges is multi-source BFS. Word Ladder is shortest path on an implicit graph.
Knowing complexity without being asked. O(V + E) for BFS and DFS, O((V + E) log V) for Dijkstra. Being able to derive these (not just recite them) is the difference at top companies.

How to study so graph algorithms actually stick

Most resources explain algorithms in isolation — here's how BFS works, here's DFS — without building the mental model of when to use each one.

What actually works:

1. Watch execution before writing code. For BFS, watch the queue grow and shrink level by level. For Dijkstra, watch the min-heap pop nodes in cost order and the distance table update. This visual step makes implementation feel natural.

2. Implement on the same graph. Take a 5-node, 7-edge graph. Run BFS, then DFS, then Dijkstra (with weights). Seeing three different traversal orders on the same graph makes the differences concrete.

3. Practice on grid problems. A 2D grid is a graph where each cell is a node and adjacent cells are edges. Grid problems are the most common disguised graph problems in interviews — the pattern transfers directly.

4. Build the decision reflex. After solving, write one sentence: "This is BFS because the graph is unweighted and I need shortest path." Train the recognition, not just the implementation.

FAQ

When should I use BFS vs DFS in a coding interview?

Use BFS when you need the shortest path in an unweighted graph or the minimum number of steps. Use DFS when you need all paths, cycle detection, or connectivity. If shortest path isn't required, both work — DFS is simpler to implement recursively.

What is the difference between BFS and Dijkstra?

BFS finds shortest path by number of edges (unweighted, every edge = cost 1). Dijkstra finds shortest path by total weight (weighted, uses min-heap). BFS for "minimum hops", Dijkstra for "minimum cost."

Can DFS find the shortest path?

No. DFS finds a path, not necessarily the shortest. Use BFS for unweighted shortest path, Dijkstra for weighted.

I built Expora to solve exactly this — the gap between knowing how an algorithm works and knowing when to use it. Expora's visual debuggers show BFS, DFS, and Dijkstra executing step by step on real graphs, so you build the decision intuition that interviewers test, not just the ability to implement from memory.

Originally published at tryexpora.com/blog/graph-algorithms-coding-interview

Port Exhaustion, Context Switching, and Why "HttpClientFactory" Exists (.NET)

Outdated Dev — Thu, 23 Apr 2026 08:10:22 +0000

Hello there!👋🧔‍♂️ When .NET apps call other HTTP APIs under load, production often teaches the same lesson in two different voices: cryptic socket errors such as “Only one usage of each socket address is normally permitted,” and slowdowns or instability that feel like “the network” but trace back to threads waiting on I/O the expensive way. The first story is mostly connection lifecycle (ports, pooling, TIME_WAIT). The second is mostly scheduling (blocking async work, thread-pool pressure, context switching).

What follows maps those symptoms onto System.Net.Http.HttpClient, explains why IHttpClientFactory from Microsoft.Extensions.Http (through AddHttpClient in ASP.NET Core and other generic host apps) is usually the right default, shows where Refit and similar libraries still sit on the same plumbing, and ends with dos and don’ts you can use in code review tomorrow.

The two problems in one sentence

Port exhaustion happens when the OS runs out of usable ephemeral ports (or related socket resources) because too many connections are opened, held, or left in TIME_WAIT. Context switching is the CPU cost of the OS pausing one thread and resuming another; under load, blocking threads on network I/O multiplies that cost and can starve the thread pool. Misusing HttpClient in .NET makes both worse.

Scope: TCP and the thread pool are general OS/runtime ideas, but the APIs, defaults, and examples here are .NET-specific (BCL + ASP.NET Core integration). If you use another language or framework, the symptoms may look the same; the fixes will use different types and lifetimes.

1. How `HttpClient` is tied to sockets and ports

HttpClient is not “a thin wrapper around a single HTTP call.” It owns (via an HttpMessageHandler, typically SocketsHttpHandler) a pool of connections to each host. Connections are reused when possible (Connection: keep-alive). That is good: fewer handshakes, fewer new local ports per request.

Problems appear when every request gets a new HttpClient (or a new handler) so the runtime cannot reuse connections cleanly, or when connections are not returned to the pool promptly.

Ephemeral ports and `TIME_WAIT`

When a TCP connection closes, the local endpoint can sit in TIME_WAIT for a while (often on the order of minutes, depending on OS tuning). While in that state, that (local IP, local port, remote IP, remote port) tuple cannot be reused for a new connection with the same identity. Under bursty traffic, opening many short-lived connections can exhaust the available ephemeral port range for a given destination, or stress socket tables, even if CPU and memory look fine.

So “port exhaustion” in discussions of HttpClient usually means ephemeral port / socket exhaustion or too many concurrent outbound connections, not literally “we ran out of port 443.”

The classic anti-pattern

// Anti-pattern: new client per call (or per request scope without proper disposal)
public async Task<string> GetAsync(string url)
{
    using var client = new HttpClient(); // new handler/socket setup underneath
    return await client.GetStringAsync(url);
}

Creating a new HttpClient for each call often creates a new handler chain and new connection behavior. Even with using, you pay setup cost every time and defeat connection pooling across calls. Under load, this pattern is a common contributor to socket pressure and DNS staleness (see below).

Static singleton HttpClient:

private static readonly HttpClient Shared = new();

public Task<string> GetAsync(string url) => Shared.GetStringAsync(url);

This reuses connections and avoids the per-call construction problem, but a long-lived default HttpClient can still hold a handler that never refreshes DNS the way you expect for long-running processes, and you lose per-logical-client configuration unless you add it carefully.

That is where IHttpClientFactory comes in.

2. What `IHttpClientFactory` fixes

IHttpClientFactory is part of Microsoft.Extensions.Http on .NET; you usually register clients from AddHttpClient in ASP.NET Core or another .NET generic host. Register named or typed clients in DI. The factory:

Pools HttpMessageHandler instances and manages their lifetime (default handler lifetime is about two minutes in modern ASP.NET Core setups; long enough to reuse connections, short enough to pick up DNS and cert changes reasonably).
Centralizes configuration (base address, default headers, timeouts, primary HttpClient handler options).
Lets you compose cross-cutting concerns: logging, resilience (for example with Polly), and tests with clear seams.

Example (ASP.NET Core):

// Program.cs
builder.Services.AddHttpClient("GitHub", client =>
{
    client.BaseAddress = new Uri("https://api.github.com/");
    client.DefaultRequestHeaders.UserAgent.ParseAdd("MyApp/1.0");
});

// A consumer
public class GitHubService(IHttpClientFactory httpClientFactory)
{
    public async Task<string> GetZenAsync(CancellationToken ct = default)
    {
        var client = httpClientFactory.CreateClient("GitHub");
        return await client.GetStringAsync("zen", ct);
    }
}

You still use async/await and one logical client per named registration, not a new physical client per operation.

Key idea: The factory is not magic; it coordinates handler lifetime and pooling so you do not accidentally create unbounded distinct handlers (and thus unbounded distinct connection pools) while still allowing multiple logical HTTP APIs in one process.

3. Other libraries and approaches (same plumbing, nicer surface)

On .NET, everything below ultimately rides on HttpClient and the same socket and threading realities. Pick the surface that matches your team’s style and how strongly typed you want the boundary to be.

Typed clients (first-party)

You inject a class that takes HttpClient in its constructor and register it with AddHttpClient<TClient>(). You get one configured client per type, full testability (mock the wrapper or use a test handler), and no stringly typed client names in business code.

Refit

Refit turns a C# interface into an HTTP client: you declare methods with attributes ([Get("/users/{id}")]). Refit generates the implementation and uses HttpClient under the hood. In ASP.NET Core you typically register with AddRefitClient<T>(), which plugs into IHttpClientFactory, so you keep handler pooling and DNS rotation while your code stays declarative. It shines when an API map is stable and you want compile-time checks instead of manual HttpRequestMessage assembly.

Small example (add the Refit.HttpClientFactory NuGet package):

using Refit;

// Contract
public interface IGitHubZenApi
{
    [Get("/zen")]
    Task<string> GetZenAsync(CancellationToken cancellationToken = default);
}

// Program.cs: Refit wires this client through the same HttpClientFactory pipeline
builder.Services.AddRefitClient<IGitHubZenApi>()
    .ConfigureHttpClient(c =>
    {
        c.BaseAddress = new Uri("https://api.github.com/");
        c.DefaultRequestHeaders.UserAgent.ParseAdd("MyApp/1.0");
    });

// Any service: inject the interface, not HttpClient
public class DemoService(IGitHubZenApi gitHub)
{
    public Task<string> FetchZenAsync(CancellationToken ct = default) =>
        gitHub.GetZenAsync(ct);
}

Flurl

Flurl is a fluent URL builder and HTTP wrapper built on HttpClient. People like it for readable one-off calls and chaining; you still want a single long-lived client strategy (often via FlurlHttp.Configure with a shared client or integration with your DI setup) so you do not recreate clients per call.

RestSharp

RestSharp (from 107+) uses HttpClient internally. The API is different from Refit (builder-style rather than interface-driven). Same rule applies: one client per logical API and no per-request client construction if you care about scale.

Polly and resilience

Polly (or Microsoft.Extensions.Http.Resilience in newer stacks) adds retries, circuit breakers, and timeouts as delegating handlers. AddHttpClient has first-class hooks to add those handlers so retries do not accidentally multiply new sockets; they wrap the same pooled HttpClient pipeline.

When HTTP is the wrong tool

If you control both ends and need streaming, strong contracts, and efficient multiplexing, gRPC (Grpc.Net.Client) is not “instead of HttpClient” in spirit, it still uses HTTP/2, but it changes design and tooling. This post stays on REST-ish HttpClient usage; just remember port and thread pressure also appear if you open too many parallel channels without backpressure.

4. Context switching: what it has to do with HTTP calls

OS thread context switches

When a thread is runnable, the scheduler may preempt it to run another thread on the same CPU. Each switch has a small but non-zero cost (saving registers, cache effects). Under heavy load, too many runnable threads can mean measurable CPU time spent just switching.

Blocking async code

If server code blocks on asynchronous work (.Result, .Wait(), GetAwaiter().GetResult()), you block thread-pool threads while I/O could have freed them:

// Bad in ASP.NET Core request path: blocks a thread
var json = httpClient.GetStringAsync(url).Result;

That can:

Reduce the pool’s ability to accept new requests.
Increase queueing and latency.
Increase context switching as the OS juggles more blocked and runnable threads than necessary.

The fix is to use await all the way and propagate CancellationToken so threads return to the pool while I/O is in flight.

Async I/O is not “free,” but it scales better

await on true async I/O does not mean zero CPU work; there is still scheduling and continuation work. But it avoids holding a thread for every concurrent outbound call, which is exactly what you want when each HttpClient call may wait on the network.

So: proper HttpClient reuse addresses connection/socket pressure; proper async addresses thread-pool and context-switch pressure.

5. `HttpClient` dos and don’ts (best practices)

Do

Use IHttpClientFactory (named, typed, or Refit-generated clients) in ASP.NET Core services so handlers rotate and connections pool predictably.
Set timeouts: HttpClient.Timeout and/or per-operation CancellationTokenSource with a bounded delay for user-facing SLAs.
Pass CancellationToken from the request (or work item) into every outbound call so work cancels when the caller disconnects.
Stay async end-to-end; avoid sync-over-async in request paths.
Configure the primary handler when you need it: for example SocketsHttpHandler.PooledConnectionLifetime (and related settings) so long-lived processes refresh connections and DNS sensibly; Microsoft’s HttpClient guidelines spell out recommended values for server scenarios.
Treat one logical outbound API as one client registration (one name, one typed client, or one Refit interface), with base address and default headers in one place.
Log correlation IDs on outbound calls (via a delegating handler or HttpClient message handler) so distributed traces line up.
Test with HttpMessageHandler mocks or WebApplicationFactory for integration tests; avoid hitting real networks in unit tests.

Don’t

Don’t do new HttpClient() per request (or per arbitrary using scope) in hot paths; the classic socket exhaustion and DNS foot-guns.
Don’t block on Task from HttpClient (.Result, .Wait(), GetResult()) on ASP.NET Core thread-pool threads; it wastes threads and worsens context switching under load.
Don’t dispose HttpClient instances returned by IHttpClientFactory.CreateClient(...); the factory owns the lifetime; disposing can break pooling (see official docs).
Don’t share mutable per-request state on a static HttpClient (for example default headers that change per user), prefer per-request headers on HttpRequestMessage or separate client registrations.
Don’t send unbounded parallel requests without throttling (semaphore, batching, or queue), you can still exhaust remote limits, local ports, or memory even with a correct singleton client.
Don’t disable TLS validation or ignore certificate errors in production; that is a security failure, not a performance tweak.

6. Practical checklist

Concern	What to do
Too many connections / ports / `TIME_WAIT`	Prefer `IHttpClientFactory` (or a carefully managed singleton with correct handler lifetime). Avoid `new HttpClient()` per call.
Stale DNS in long-running apps	Factory-managed handler rotation helps; verify SocketsHttpHandler / PooledConnectionLifetime style settings for your version.
Thread pool starvation / high context switching	Never block on `Task`-based APIs; use `await` and `ConfigureAwait(false)` only where appropriate (libraries; ASP.NET Core apps usually omit it on the server).
Many distinct outbound bases	Use named or typed clients (or Refit interfaces) so each logical API gets one stable configuration, not one new client type per request.

7. Closing thought

Port exhaustion and context switching are different mechanisms, but both show up when a .NET service makes lots of outbound HTTP calls under load. Misusing HttpClient amplifies socket and DNS issues; blocking on async amplifies thread-pool and scheduling issues. IHttpClientFactory is the supported way in ASP.NET Core (and the generic host) to keep handlers and connection pools healthy while you keep your code fully asynchronous, so your CPUs spend time on work, not on fighting the network stack and the scheduler. Libraries like Refit or typed clients sit on top of that .NET foundation; they do not remove the need to get the lifecycle right.

Microtasks: Why Promises Run First

Marsha Teo — Thu, 23 Apr 2026 08:10:16 +0000

This is the third article in a series on how JavaScript actually runs. You can read the full series here or on my website.

In the last article, we established that:

JavaScript execution cannot be interrupted.

Once a macrotask starts, nothing cuts in. Only after it completes does the runtime select the next macrotask from the queue.

But consider this:

setTimeout(() => console.log("timeout"), 0);

Promise.resolve().then(() => console.log("promise"));

console.log("sync done");

The output is always:

sync done
promise
timeout

Both setTimeout and Promise.then are asynchronous and both schedule work to run later. If macrotasks are chosen one at a time, and nothing interrupts them, then promises should behave like timers. But that's not the case. The promise runs first, every time. Why?

If our macrotask model of JavaScript were complete, this ordering would not be guaranteed. Something else must exist. Specifically, there is another category of work in JavaScript: microtasks.

They do not interrupt the current macrotask. And yet they run before the runtime selects the next macrotask. Before we define them fully, we should understand why such a mechanism is needed.

The Tempting but Incomplete Explanation

Many explanations jump immediately to:

“Promises use the microtask queue, which runs before the macrotask queue.”

That statement is technically correct. But it explains nothing. Why are there two queues? Why does one outrank the other?

If we stop here, microtasks feel arbitrary. Let's instead find out more.

Running the Experiments

You can run all code snippets in this series by pasting them into the browser console.

While some examples work in Node.js, others rely on browser APIs (like rendering or requestAnimationFrame), so the browser is the most reliable environment.

A Hypothesis: Promises Are Just Higher-Priority Tasks

A reasonable mental model is that microtasks are just higher-priority tasks. When we have timers and promises, timers go into one queue, promises go into another, and the promise queue is checked first.

Let's test this:

setTimeout(() => console.log("timeout"), 0);

Promise.resolve().then(() => {
  console.log("promise 1");
  Promise.resolve().then(() => {
    console.log("promise 2");
  });
});

console.log("sync done");

If promises are merely higher-priority tasks, we may expect:

sync done
promise 1
timeout
promise 2

After sync done, the runtime has at least two pending pieces of work: the timer callback and the first promise callback. Since promise callbacks have higher priority, the runtime chooses the promise first. Consequently, promise 1 runs before timeout.

When promise 1 runs, it schedules another promise callback: promise 2. At this point, the runtime could choose between the existing timer callback or the newly scheduled promise callback. If promise callbacks were just higher priority macrotasks, the runtime should be free to interleave them.

However, the actual output is:

sync done
promise 1
promise 2
timeout

promise 2 runs immediately after promise 1, before the timeout is even considered.

The Rule That Must Exist

The only model consistent with this behavior is:

Once microtask execution begins, all microtasks must run to completion before the runtime considers another macrotask.

Promise callbacks are not independent tasks competing with timers. They are unfinished work from the current turn of execution. They are continuations and continuations must complete before control is returned to the runtime.

Reframing Microtasks Properly

A microtask is not a faster callback nor is it a convenience queue. Promise callbacks are the most common example of microtasks, but this mechanism also underlie async functions and MutationObserver callbacks. Broadly, a microtask is:

Work that must be completed before JavaScript yields control back to the runtime.

This is why:

microtasks run after the current macrotask finishes,
microtasks run before the runtime chooses another macrotask,
the runtime drains the microtask queue completely,
microtasks can schedule more microtasks,

They exist to preserve atomicity across asynchronous boundaries.

Why This Rule Must Exist

If microtasks were treated like ordinary macrotasks, promise chains could interleave with unrelated work. That would introduce subtle inconsistencies and expose partially completed state.

Consider this:

let state = {
  loading: true,
  data: null
};

Promise.resolve().then(() => {
  state.data = "result";
  state.loading = false;
});

This callback represents a single logical transition where the data arrives and loading ends. From the programmer's perspective, these two assignments belong together.

If the runtime were allowed to pause this callback midway or run unrelated macrotasks before it completes, external code could observe:

{ loading: true, data: "result" }

This is a partially completed update (data has arrived but loading is still true). JavaScript avoids this by enforcing:

Once the current macrotask finishes, the runtime runs all microtasks run before selecting another macrotask.

This ensures that promises are continuations of the current turn of execution. And these continuations must complete before control returns to the runtime. That guarantee makes promise chains predictable:

Promise.resolve()
  .then(() => step1())
  .then(() => step2());

The first .then() callback is queued as a microtask. After the promise returned by step1() settles, the second callback is queued. A promise chain schedules its continuations incrementally, not all at once.

Yet because the runtime must drain the microtask queue completely before selecting another macrotask, these incrementally scheduled callbacks still run back-to-back, without unrelated timers or events cutting in between them. The continuation may be deferred but it is never fragmented.

The Draining Behavior

Microtasks are not executed one-by-one with runtime checks between them. They are drained in a loop:

while (microtask queue is not empty) {
  run next microtask
}

That is why nested promises run immediately. That is why infinite promise loops freeze the page. Consider:

function loop() {
  Promise.resolve().then(loop);
}

setTimeout(() => console.log("timeout fired"), 0);

loop();

If you run this, be prepared to close the page, since this experiment creates an infinite microtask loop.

The page would freeze and timeout fired is never logged since a new microtask is queued every time loop is called. The runtime is not allowed to proceed to another macrotask while microtasks remain. Microtasks are not candidates for task selection. They are executed automatically as part of finishing the current turn.

The JavaScript Turn Model

We can now describe a single turn of JavaScript execution:

The runtime chooses a macrotask.
JavaScript executes synchronously.
Once the call stack is empty, the runtime drains the microtask queue.
Only then can the runtime consider another macrotask.

This is the event loop from JavaScript's perspective. In later articles, we will extend this model to include rendering and the browser's frame lifecycle. loop.

The Mental Model to Keep

When debugging async behavior, ask:

Did we just finish a macrotask?
Are there microtasks pending?
Has the runtime been allowed to choose another macrotask yet?

If microtasks exist, the answer is always:

No, the runtime must wait.

What This Prepares Us For Next

If microtasks are mandatory continuations, then what exactly does await do?

Does it pause execution?
Does it create a new task?
Or does it quietly hook into this same microtask mechanism?

Understanding that requires looking at async functions more closely.

That is the subject of the next article.

This article was originally published on my website.

Claude Design is Replacing Designers?

divyesh vekariya — Thu, 23 Apr 2026 08:07:41 +0000

divyesh vekariya

Apr 23

Is Claude Design Really Laying Off Designers?

#ai #design #claude #uidesign

Comments

7 min read

Polymarket API for Developers: Data, CLOB, and Polygon RPС

Alex — Thu, 23 Apr 2026 08:07:33 +0000

TL;DR: Polymarket is a decentralized prediction market on Polygon where real-world events become tradable probability markets. The Polymarket API gives developers programmatic access to market data, trading infrastructure, and on-chain settlement — the foundation for trading bots, analytics dashboards, and prediction market interfaces.

What is Polymarket?

Polymarket is a non-custodial prediction market on Polygon PoS. Users trade binary outcome tokens in USDC.e, priced $0–$1 based on collective market belief, through a hybrid off-chain order book (CLOB) with on-chain settlement via the Conditional Token Framework (ERC-1155). Markets resolve via UMA’s Optimistic Oracle. Markets span elections, major sports, crypto milestones, geopolitical events, and cultural awards — 2.4 million traders, ~$62B in total volume, NYSE’s parent invested $2B at a $9B valuation in 2025.

Polygon PoS: the settlement layer

All Polymarket contracts run on Polygon PoS (Chain ID 137) — ~110 TPS, ~$0.002 average tx cost, gas under $0.01 per trade. Polygon’s dual-layer architecture matters for how you handle finality: Heimdall manages validators and commits checkpoints to Ethereum every ~30 minutes (full L1 finality), while Bor handles EVM-compatible block production at 2-second block times (soft finality). Use Bor finality to confirm fills in your bots, Ethereum checkpoints for withdrawals. All Polymarket on-chain events — OrderFilled, PositionsMerged, ConditionResolution — are emitted on Bor. Solidity, ethers.js, viem, and Foundry all work without modification.

The four API layers

Gamma API is the public market discovery layer — no auth, no API key. It exposes Events (top-level questions) and Markets (specific tradable outcomes). Each market’s outcomePrices array maps 1:1 to outcomes and represents implied probabilities — 0.62 means a 62% chance of YES. Filter by active status, 24h volume, tags, open/closed state, and more. Always verify enableOrderBook: true before assuming a market has live CLOB liquidity.

CLOB is the trading engine — hybrid-decentralized with off-chain order matching and on-chain EIP-712 settlement. Available via official SDKs (TypeScript, Python, Rust) or raw REST. Authentication is two-tiered: L1 uses wallet signatures to generate API credentials without spending gas, L2 uses those credentials for fast HMAC-signed requests on every order call. Four order types: GTC (rests on book), GTD (time-bound), FOK (all-or-nothing), FAK (fill what’s available, cancel the rest). Before any order is accepted, the CLOB verifies: valid EIP-712 signature, sufficient USDC.e balance, approved CTF Exchange allowances, and valid L2 credentials.

Data API covers user-level analytics — current positions across markets, full trade history with timestamps and sizes, realized and unrealized P&L, and activity feeds per wallet. This layer becomes important once you move beyond execution and start building dashboards or analyzing strategy performance over time.

WebSocket delivers real-time updates over persistent connections — four channels: market (book snapshots, tick updates, last trade price), user (fills, status changes, cancellations), sports (live sports markets), and RTDS (institutional feed). Critical production detail: Polymarket cancels all open orders when an authenticated session goes inactive — bots must send a heartbeat to stay active.

Integration summary

The integration takes you from a blank directory to a working trading client in 10 steps: set up a Polygon wallet and fund it with POL, deposit USDC.e to your Polymarket profile address, derive L2 API credentials from your wallet, run client.setAllowances()once to approve the CTF Exchange, fetch a market from Gamma, inspect the order book, place a limit order, subscribe to WebSocket channels for real-time fills, and set up an OrderFilled event listener on the CTF Exchange for on-chain confirmation. Once complete, you have the foundation for anything from analytics tools to fully automated trading bots.

💡 Want to see the full step-by-step integration guide? Read the full guide on Chainstack Blog

Builder tools

A range of official and community tools are available: the official clob-client (TypeScript) for order placement and API credentials, real-time-data-client for WebSocket subscriptions with built-in reconnect logic, clob-order-utils for low-level EIP-712 order signing, an rs-clob-client in Rust, Polymarket Agents (Python) as a reference implementation for LLM-based autonomous trading, and Goldsky-powered subgraphs for positions, order book, PnL, and open interest over GraphQL. On the infrastructure side, production-grade Polygon RPC with archive access and WebSocket is available via Chainstack.

Considerations

Before building or trading on Polymarket, understand the key risks: market risk (wrong predictions lose the full committed amount), low liquidity in thin markets, oracle settlement delays if outcomes are disputed, geographic restrictions depending on your region, and smart contract risk inherent to any on-chain platform. Only use funds you are prepared to lose, and verify the legal status of prediction markets in your jurisdiction.

Conclusion

The Polymarket API turns prediction markets into programmable infrastructure — fast, low-cost settlement on Polygon, USDC.e-denominated, with clean primitives across Gamma, CLOB, Data, and WebSocket. The same EVM tooling you already use works without modification. The ecosystem is early and most of the interesting tools haven’t been built yet — whether you’re building a trading bot, a probability dashboard, or an analytics pipeline, the architecture is well-documented, the contracts are audited, and the on-chain history is fully transparent.

💡 Read the full article on Chainstack Blog → https://chainstack.com/polymarket-api-for-developers/

Visual Testing with Playwright: The Complete Tutorial

Delta-QA — Thu, 23 Apr 2026 08:05:29 +0000

Visual Testing with Playwright: The Complete Tutorial

Since version 1.22, Microsoft's Playwright includes a native visual testing feature: the toHaveScreenshot() method. It captures screenshots and automatically compares them to reference images, with no external plugin needed.

This is one of the strongest options for development teams wanting to add visual testing to their existing stack. This tutorial covers installation, configuration, best practices, and CI/CD integration.

Installation and first test

Setup is quick with an existing Node.js project:

npm install -D @playwright/test
npx playwright install

Create your first visual test in tests/visual.spec.ts:

import { test, expect } from '@playwright/test';

test('homepage visual test', async ({ page }) => {
  await page.goto('https://your-site.com');
  await expect(page).toHaveScreenshot('homepage.png');
});

First run generates the baseline. Subsequent runs compare against it. That simple to start — complexity comes with real-world cases.

Configuring tolerance

By default, Playwright flags any single-pixel difference. In practice, configure thresholds to avoid false positives:

// playwright.config.ts
expect: {
  toHaveScreenshot: {
    maxDiffPixelRatio: 0.01,
    animations: 'disabled',
    scale: 'device',
  },
}

Handling dynamic content

Three solutions: mask dynamic zones, replace content via page.evaluate(), or hide with injected CSS. Each has tradeoffs between reliability and maintenance.

Stabilizing tests

Wait for network idle, font loading, and critical element visibility before capturing. Disable animations globally in config.

Multi-resolution testing

Use Playwright projects to test Desktop (1920×1080), Tablet (768×1024), and Mobile (iPhone 13) with separate baselines per project.

CI/CD integration

GitHub Actions integration is straightforward. When tests fail, Playwright generates three images: baseline, actual screenshot, and a red-highlighted diff. The HTML report shows them side by side.

Limitations

TypeScript/JavaScript skills required. No built-in review dashboard. Pixel comparison remains basic — anti-aliasing and font rendering differences between browsers generate noise. Baseline management with 200+ tests across 3 browsers means 600+ files to maintain.

For teams wanting visual testing without these technical constraints, no-code solutions like Delta-QA offer an alternative: same result with zero code, zero manual baseline management, and zero false positives.

FAQ

Is Playwright free for visual testing?

Yes, entirely. toHaveScreenshot() is built into Playwright, which is open source.

Playwright or Cypress for visual testing?

Playwright has native visual testing; Cypress needs a plugin. Playwright supports three browser engines vs one for Cypress. For visual testing specifically, Playwright wins.

Can you use Playwright and Delta-QA together?

Yes. Playwright for complex dev tests, Delta-QA for routine visual checks by the QA team.

Previous article: From Manual to Automated Testing: A Guide for Non-Developer QAs

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Google Just Made MCP Enterprise-Grade at Cloud NEXT '26 - Here's What That Means for Android Developers

Vikas Sahani — Thu, 23 Apr 2026 08:02:48 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Google Just Made MCP Enterprise-Grade at Cloud NEXT '26 — Here's What That Means for Android Developers Who Already Use It

Google Cloud NEXT '26 dropped one announcement that most developer write-ups buried under the TPU 8 headlines and the $750M partner fund:

Apigee MCP is now Generally Available.

Any standard API can now be exposed as a discoverable, governed MCP tool — no local server infrastructure required. Combined with ADK v1.0 stable and the A2A protocol hitting production at 150 organisations, Google has just made the Model Context Protocol a first-class enterprise primitive.

For Android developers, this is worth stopping to think about carefully — because the MCP ecosystem already exists at the community layer, and Google just validated the entire pattern from the top down.

I know this because I built AndroJack MCP — a community MCP server that gives AI coding assistants live, verified Android knowledge. Let me show you what Google's announcement actually changes, what it doesn't, and what the Android developer workflow looks like when both layers work together.

The Problem That Started Everything

Here's a number from the 2025 Stack Overflow Developer Survey that should make every Android dev uncomfortable:

35% of all Stack Overflow visits in 2025 were triggered by developers debugging AI-generated code.

Trust in AI coding tools collapsed from 40% to 29% in a single year — despite usage climbing to 84%.

The gap is structural. AI models predict tokens. They were trained on a snapshot of the world. They have no mechanism to know that Navigation 3 went stable in November 2025 after seven years of Nav2. They don't know that Android 16 mandates edge-to-edge enforcement, or that ContextualFlowRow was deprecated in Compose 1.8, or that ACCESS_LOCAL_NETWORK is now a required permission for any app targeting Android 17 API 37 that connects to local IPs.

The result is not bad code. It is confidently bad code. Code that compiles. Code that runs. Code that fails at Play Store review or corrupts your architecture before you notice.

This is the exact problem MCP was designed to solve — connecting AI to live, authoritative data sources rather than having models rely on frozen training snapshots.

What Google Announced at Cloud NEXT '26

The headlining story was the full rebrand: Vertex AI is now the Gemini Enterprise Agent Platform. But under that umbrella, three things matter specifically for the MCP conversation:

1. Apigee MCP — Generally Available

Google's API management platform, Apigee, can now transform any managed API into a discoverable MCP tool. No local MCP server. No custom infrastructure. Just an OpenAPI specification, and your entire enterprise API catalog becomes agent-accessible — with existing governance, security controls, and audit logs intact.

The practical meaning: a company can expose its internal HR APIs, its CRM data, its ERP endpoints — all as MCP tools — through a single managed gateway, and have AI agents consume them safely.

2. ADK v1.0 Stable — Across Four Languages

Google's Agent Development Kit hit v1.0 with stateful multi-step agent support, enhanced debugging tooling, and native Vertex AI Agent Engine integration. ADK now has native A2A protocol support built in — which means agents built with ADK can hand tasks off to agents built in LangGraph, CrewAI, or any other A2A-compatible framework without custom glue code.

3. A2A Protocol in Production at 150 Organisations

Agent-to-Agent communication — where a Salesforce agent can hand a task to a Google agent, which queries a ServiceNow agent, all without any of the three systems understanding each other's internal architecture — is no longer experimental. It is in production.

The Layer Distinction Nobody Is Talking About

Here is the thing Google's announcement does not change: domain-specific MCP tooling.

Apigee MCP solves the enterprise API connectivity problem. It is extraordinary at that. But it cannot tell your AI assistant that:

NavController.navigate(route: String) was removed in Navigation 3 and you need NavDisplay instead
The ACCESS_LOCAL_NETWORK permission is mandatory for Android 17 apps that connect to local IPs
TestCoroutineDispatcher was removed from coroutines-test 1.8+ and will silently break your CI
Material 3 Expressive components shipped at Google I/O 2025 with specific token requirements
The Compose BOM you're targeting has deprecated ContextualFlowRow and your code will break on the next BOM bump

No enterprise API catalog ships this knowledge. It lives in official Android documentation, in release notes, in migration guides — and it changes every month as Compose ships a new BOM, as Android versions progress through beta, as Google Play policy updates.

This is the layer AndroJack MCP operates at.

What AndroJack Actually Does — A Real Workflow

Let me make this concrete. Here is what happens when an Android developer asks Claude (or Cursor, or any MCP-compatible AI) to write a feature using Navigation 3 — without an Android-grounded MCP server:

Developer: "Add a bottom nav with three screens in my Compose app"

AI: Here's how to set it up with NavController and NavHost...

  val navController = rememberNavController()
  NavHost(navController, startDestination = "home") {
    composable("home") { HomeScreen() }
    composable("search") { SearchScreen() }
    composable("profile") { ProfileScreen() }
  }

This code is architecturally dead. Navigation 3 replaced this pattern entirely. The back stack is now a plain Kotlin list. NavDisplay replaces NavController. An Atomic Robot case study documented two LLMs — Gemini and Claude, both with internet access — generating the wrong Navigation 3 API even when explicitly asked about it, because they defaulted to the Nav2 patterns that dominate their training data.

With AndroJack MCP active, the AI must call android_navigation3_guide before generating any navigation code. It retrieves the live Navigation 3 documentation and generates:

// Navigation 3 — correct pattern (stable since Nov 2025)
@Composable
fun AppNavigation() {
  val backStack = rememberNavBackStack(Home)

  NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
      rememberSceneSetupNavEntryDecorator()
    )
  ) { entry ->
    when (entry.key) {
      is Home -> HomeScreen()
      is Search -> SearchScreen()
      is Profile -> ProfileScreen()
    }
  }
}

That is not a style difference. It is the difference between an app that builds correctly today and one that requires an architectural rewrite.

The Android 17 / API 37 Case — Where This Gets Critical Right Now

This is the most time-sensitive thing in this article. Android 17 reached platform stability (Beta 3) on March 26, 2026. The API surface is locked. Developers need to finalize compatibility testing now.

AndroJack v1.7.0 ships android17-compliance.ts — a dedicated tool that covers the breaking changes most AI tools don't know exist yet:

Breaking Change 1: Static Final Field Reflection

// ❌ BREAKS on Android 17 — code AI still generates
val field = MyClass::class.java.getDeclaredField("CONSTANT")
field.isAccessible = true
field.set(null, "new_value") // IllegalAccessException on API 37+

// ✅ What AndroJack guides the AI to generate instead
class MyViewModel(
  private val config: String = BuildConfig.API_URL // injected, not reflected
) : ViewModel()

Breaking Change 2: ACCESS_LOCAL_NETWORK

// ❌ Missing permission — silent failure on Android 17 for LAN apps

// ✅ AndroidManifest.xml — now required for API 37+ LAN access
<uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />

// ✅ Runtime check before local network operations
if (Build.VERSION.SDK_INT >= 37) {
  val granted = ContextCompat.checkSelfPermission(
    context, "android.permission.ACCESS_LOCAL_NETWORK"
  ) == PackageManager.PERMISSION_GRANTED
  if (!granted) {
    launcher.launch("android.permission.ACCESS_LOCAL_NETWORK")
    return
  }
}

Breaking Change 3: SMS OTP — 3-Hour Delay

Apps targeting Android 17 will experience a mandatory 3-hour delay in programmatic SMS OTP reading. Any fintech or auth flow that relied on instant OTP reading needs to be redesigned before targeting API 37.

None of these are in any LLM's training data. Android 17 is too recent. AndroJack's validator catches violations in generated code and returns structured reports with exact line references and fixes before the AI returns code to the developer.

The On-Device AI Angle — Where Google's Cloud NEXT Announcement Directly Connects

Here is where Cloud NEXT '26 and AndroJack converge on something genuinely new.

Google's announcements this week pushed hard on the Gemini Enterprise Agent Platform as the cloud-side layer for agentic AI. But Android has been building the device-side layer simultaneously. Android 16 shipped AICore — a system-level service that manages on-device LLMs. ML Kit Gen AI API lets apps access Gemini Nano through a standard interface.

The architectural pattern that emerges when you combine both:

// Domain layer — the AI assistant doesn't know if this is on-device or cloud
interface AiTextRepository {
  suspend fun summarize(text: String): Result<String>
  fun isAvailable(): Flow<Boolean>
}

// On-device implementation — Gemini Nano via AICore (zero latency, offline, free)
class OnDeviceAiRepository(
  private val generativeModel: GenerativeModel
) : AiTextRepository {
  override suspend fun summarize(text: String): Result<String> = runCatching {
    val response = generativeModel.generateContent("Summarize: $text")
    response.text ?: throw IllegalStateException("No response from on-device model")
  }
  override fun isAvailable(): Flow<Boolean> = flow {
    emit(GenerativeModel.isAvailable())
  }
}

// Cloud fallback — Firebase Vertex AI (Gemini Enterprise layer)
class CloudAiRepository(
  private val vertexAi: FirebaseVertexAI
) : AiTextRepository {
  override suspend fun summarize(text: String): Result<String> = runCatching {
    val model = vertexAi.generativeModel("gemini-3-flash")
    val response = model.generateContent("Summarize: $text")
    response.text ?: throw IllegalStateException("No response from cloud model")
  }
  override fun isAvailable(): Flow<Boolean> = flowOf(true)
}

// Factory — selects the right backend at runtime
class AiRepositoryFactory @Inject constructor(
  @ApplicationContext private val context: Context,
  private val cloudRepository: CloudAiRepository
) {
  suspend fun create(): AiTextRepository {
    return if (GenerativeModel.isAvailable(context)) {
      OnDeviceAiRepository(GenerativeModel.getInstance(context))
    } else {
      cloudRepository // Graceful fallback to Gemini Enterprise cloud
    }
  }
}

This pattern — repository interface, on-device primary, cloud fallback — is what AndroJack's android_on_device_ai_guide tool surfaces for every developer asking how to add AI to their Android app. The on-device layer gives you zero latency, full privacy, zero API cost. The cloud layer (now powered by Google's Gemini Enterprise Agent Platform announced at Cloud NEXT '26) gives you capability overflow for complex tasks.

An AI assistant without AndroJack would generate a direct Vertex AI call and skip the on-device option entirely — missing a major architecture decision. With AndroJack, the AI is grounded in the full picture.

The Bigger Picture: Community MCP and Enterprise MCP Are Not Competing

This is the genuine insight from Cloud NEXT '26 for anyone building in the MCP ecosystem.

Google's managed MCP via Apigee solves breadth — giving enterprise agents access to any API with governance at scale. Community-built MCP servers like AndroJack solve depth — giving AI assistants expert-level, domain-specific knowledge that no API catalog will ever codify.

They operate at different layers of the same stack:

┌─────────────────────────────────────────────────────┐
│              Your AI Coding Assistant               │
├─────────────────────────────────────────────────────┤
│  Community MCP Layer (Domain Depth)                 │
│  └── AndroJack: 22 tools, 31 rules                 │
│      Navigation 3 · Compose BOM · Android 17        │
│      ML Kit · Wear OS · XR · Play Policy            │
├─────────────────────────────────────────────────────┤
│  Enterprise MCP Layer (API Breadth)                 │
│  └── Apigee MCP GA (Cloud NEXT '26)                │
│      Internal APIs · CRM · HR · ERP data           │
├─────────────────────────────────────────────────────┤
│  Agent Orchestration                                │
│  └── A2A Protocol + ADK v1.0 (Cloud NEXT '26)      │
└─────────────────────────────────────────────────────┘

The A2A protocol announcement makes this even more interesting. When agents can hand off tasks to each other, a coding agent grounded by AndroJack (community MCP) could hand a documentation or data lookup task to a Google-managed agent running on Apigee (enterprise MCP) — and neither needs to understand the other's internal structure.

That is not science fiction. It is the architecture Google described as live in production this week at Cloud NEXT '26.

How to Get Started With Both Layers Today

Install AndroJack MCP in 30 Seconds

# In Claude Desktop, Cursor, VS Code, or Windsurf
npx -y androjack-mcp@1.7.1

Or one-click install from the README.

What you get immediately:

22 Android-specific tools across Kotlin, Compose, Navigation 3, Gradle, ML Kit, Wear OS, XR, Play Policy
31 validation rules that check AI-generated code before it reaches you
Android 17 / API 37 compliance checker (new in v1.7.0) — relevant right now for compatibility testing
Level 3 loop-back validation: AI generates code → validator checks it → AI fixes violations → you get clean code

Connect to Google's Managed MCP (via Vertex AI Agent Builder)

Google's Cloud Console now lets you connect Apigee-managed MCP endpoints directly to agents in Vertex AI Agent Builder. If your team has internal APIs that Android code needs to interact with — analytics endpoints, content APIs, internal feature flag services — this is the path.

What I'm Building Next — and Why Cloud NEXT '26 Accelerates It

AndroJack is currently on npm, VS Code Marketplace, MCP Registry (io.github.VIKAS9793/androjack), and the Anthropic Connectors Directory. The next phase is deeper integration with the Google Antigravity IDE — which AndroJack already supports via config — and exploring what an A2A-aware Android coding agent looks like when AndroJack's domain tooling is one node in a larger agent graph.

The ADK v1.0 stable release from Cloud NEXT '26 makes that significantly more tractable. Stateful multi-step agent support and native A2A — that's the substrate for a coding workflow where:

An orchestrator agent receives a feature request
It hands the Android-specific parts to a coding agent grounded by AndroJack
The coding agent validates its output via AndroJack's Level 3 loop-back validator
It hands the infrastructure/API parts to a Gemini Enterprise agent with Apigee MCP access
A2A coordinates the handoff without custom integration code

That is the workflow that makes AI coding assistants actually trustworthy for professional Android development.

The Takeaway

Google Cloud NEXT '26 did not just ship enterprise features. It validated the architectural pattern that the MCP community has been building from the bottom up for the past year.

Managed MCP (Apigee) + Community MCP (AndroJack and others) + A2A orchestration (ADK v1.0) = a complete stack where AI coding agents are grounded in both enterprise data and domain expertise simultaneously.

For Android developers: you do not have to wait for this stack to exist. The community layer is live today. Install AndroJack, and your AI assistant immediately knows about Android 17, Navigation 3, the Compose BOM, on-device AI with Gemini Nano, Play Store policy, Wear OS and XR — grounded in official documentation, not training data frozen six months ago.

The managed enterprise layer that Cloud NEXT '26 delivered is the piece that makes this viable at org scale.

Both matter. Both are now real.

AndroJack MCP is open source on GitHub: github.com/VIKAS9793/AndroJack-mcp

Install: npx -y androjack-mcp@1.7.1

Works with: Claude Desktop · Cursor · VS Code · Windsurf · JetBrains · Google Antigravity · AWS Kiro

No-Code Visual Testing: The Complete Guide for QA Teams

Delta-QA — Thu, 23 Apr 2026 08:02:01 +0000

No-Code Visual Testing: Automate Your Checks Without Writing Code

No-code visual testing is a method that automatically detects visual regressions on a website — a shifted button, a changed color, overflowing text — without writing a single line of code. You record a journey by browsing normally, then the tool replays it and compares screenshots pixel by pixel.

For 15 years, automating a test meant writing code. That's no longer the case. This guide is for QA professionals, product managers, and marketing teams — anyone who checks interfaces daily without being a developer.

The Problem: Automation Has Always Excluded Non-Developers

For a decade, the message has been the same in the software testing industry:

"QA engineers must learn to code to automate their tests."

The result has been a collective failure. Experienced QA teams, with 10 or 15 years in the field, are pushed toward tools like Selenium, Cypress, or Playwright that they don't master. Training is abandoned after a few weeks. Automated tests end up maintained solely by developers. And QA engineers feel sidelined.

An experienced QA excels at functional analysis, test case writing, and exploratory testing. These are skills that take years to build. But traditional automation requires mastering JavaScript, CSS selectors, and code debugging. These are two different jobs.

On one side, the QA knows the product better than anyone. They know which journeys to test, which scenarios are critical, where bugs hide. On the other side, traditional automation demands pure developer skills: writing code, maintaining scripts, managing dependencies. Asking a functional expert to become a developer is like asking an architect to lay the bricks themselves.

This gap is real. And bridging it takes months, even years. No-code testing eliminates this barrier entirely.

How No-Code Visual Testing Works

The concept is simple. The process follows four steps:

Open your website in the testing tool
Browse normally, like a real user (click buttons, fill forms, scroll pages)
The tool records every action automatically and takes a reference screenshot
Replay the scenario later: the tool compares new screenshots to references and highlights every difference

No JavaScript. No CSS selectors. No configuration files. No terminal.

The reference screenshot (called a "baseline") represents the validated state of your site. On each subsequent run, the tool overlays the current state against this reference and automatically detects what changed: a shifted pixel, a modified font, a missing element.

It's exactly what a human would do comparing two versions of a page side by side — except the robot never gets tired, never misses anything, and does it in seconds.

What Your Regular Tests Don't See

A standard functional test checks that elements are present. Is the "Buy" button there? Yes. Does the form work? Yes. Does the menu appear? Yes.

But what the test doesn't tell you is:

The "Buy" button has turned white on a white background — invisible to users
The form overflows its container on mobile
The menu covers the main content of the page

The site "works" technically, but it's visually unusable. This is exactly the blind spot that visual regression testing fills. It checks not whether elements exist, but whether they display correctly — the right color, the right size, in the right place.

From Installation to First Test: The Concrete Workflow

Here's how a no-code visual test works with a solution like Delta-QA:

Installation: Download the app, install it with a double-click. No npm, no terminal, no dependencies. 30 seconds is all it takes.

Recording: Create a new scenario, enter your site's URL. A browser opens. Browse normally on the pages you want to monitor. The tool records every action — every click, scroll, and input.

Execution: Click "Run." The tool replays your actions automatically and takes new screenshots.

Analysis: Differences are highlighted side by side. Green = identical. Red = difference detected. You instantly see what changed, without searching manually.

Time from installation to first test: a few minutes. Not days.

Approach	Setup	First 10 tests	Total
Playwright (code)	1-2 days	1 day	2-3 days
Percy (SaaS + code)	4-8 hours	4 hours	1-2 days
Delta-QA (no-code)	30 minutes	2-3 hours	3-4 hours

No-Code vs Code: An Honest Comparison

No-code is not a replacement for code. It's a complement. Here's an objective comparison.

Creating a product page test with code (Playwright, for example) means writing a script, configuring comparison options, and managing masks for dynamic content. Count 15 to 30 minutes if you're proficient.

With a no-code solution, you open the page, click "Capture," and stop recording. 2 minutes.

Maintenance is also simpler: when a selector breaks in code, you need to debug and fix the script. With no-code, you re-record the step in a few clicks.

But code retains real advantages for certain cases:

Conditional logic: if this promo is visible, test this path; otherwise, test the other
Dynamic data generation: create test users on the fly
Complex assertions: verify all prices in a list are greater than zero
Advanced API integration: validate server responses before testing the interface

These are cases where no-code reaches its limits. And that's normal: both approaches serve different needs.

Who Is No-Code Visual Testing For?

Experienced non-developer QA engineers

This is the primary audience. Professionals with 10+ years of functional experience, irreplaceable domain expertise, who want to automate without depending on the dev team. Their knowledge — what to test, when, and why — is infinitely more valuable than the ability to write a script. No-code finally lets them turn that expertise into automated tests.

Small teams and startups

No dedicated QA, no budget for complex test infrastructure, but a real need to verify the site doesn't break between deployments. The founder who deploys on Friday night and wants to sleep peacefully.

Non-technical teams

Marketing checking that the landing page hasn't shifted after a deployment. Support confirming a fix is in place. The product manager visually validating a feature before shipping.

The Business Impact: A Broken Interface Is Expensive

A visual error is never "just a cosmetic detail." Visual bugs have a real cost on your business:

Conversion drop: an invisible purchase button on mobile means a lost sale. Users don't search — they leave. A single second of display lag can drop your conversion rate by 7%.

Credibility loss: overflowing text, distorted images, misaligned forms — all signal amateurism. Trust built over months collapses in seconds.

High correction cost: detecting a visual bug in production costs 10 to 100 times more than catching it before deployment. Not to mention the reputation damage.

Automated visual testing turns a multi-hour manual check (often rushed due to fatigue) into a process that takes seconds and is 100% reliable.

The Privacy Question

Many visual testing tools require sending your screenshots to the cloud. Your internal dashboards, client data, in-development interfaces — everything goes to external servers, often located in the United States.

This is a real problem for companies subject to GDPR, for regulated industries (banking, healthcare, defense), or simply for teams that want to keep control over their data.

A local solution like Delta-QA keeps everything on your machine. No screenshot ever leaves your computer. It's the only approach that guarantees total sovereignty over your test data — a strong argument against US-based cloud solutions.

The Hybrid Strategy: Best of Both Worlds

The best approach for a complete team combines three testing layers:

Layer 1 — No-code tests (QA team): critical business pages, main user journeys, visual checks after every deployment. Maintained directly by the QA team.

Layer 2 — Coded tests (developers): complex tests with conditional logic, integration tests, dynamic data scenarios. Maintained by the dev team.

Layer 3 — Unit tests (developers): business logic, isolated components. The base of the testing pyramid.

This model lets each role contribute with their skills, without forcing anyone outside their expertise zone. QA does what they do best, devs too. Everyone is productive.

Best Practices for Getting Started

Start small: protect your 5 most critical pages first — homepage, cart, checkout, contact form, flagship product page. These are the pages where a visual bug has the most impact on your revenue.

Test all formats: a site that's perfect on desktop can be completely broken on mobile. Always check both. And if your users use Safari, test cross-browser too.

Build a routine: don't test once a month. Integrate visual testing into every deployment, even minor ones. A small CSS change can have unpredictable consequences.

Involve the whole team: no-code lets QA, designers, and product managers create and maintain tests. Use this to democratize visual quality across your organization.

FAQ

What is no-code visual testing?

It's a method to automatically detect visual changes on a website — shifted buttons, changed colors, missing elements — without writing code. You record a journey by browsing normally, then the tool replays it and compares screenshots pixel by pixel.

Do I need technical skills to use Delta-QA?

No. Delta-QA was designed for non-technical profiles. No code, no framework configuration. If you can browse a website, you can use Delta-QA.

What free tool can I use for visual regression testing?

Delta-QA offers a completely free Desktop version with no scenario or comparison limits. No signup, no credit card, no time limit.

Does no-code replace coded tests?

No. No-code complements coded tests. It's ideal for visual checks and critical journeys. Complex tests with conditional logic remain the domain of code. The best strategy is hybrid.

Where are my screenshots stored with Delta-QA?

Everything stays on your machine. No data is sent to an external cloud. This is essential for GDPR compliance and intellectual property protection.

What's the difference between a functional test and a visual test?

A functional test checks that elements exist and work (the button is clickable). A visual test checks that elements display correctly — the right color, the right size, in the right place. Learn more in our complete visual testing FAQ.

No-code visual testing isn't a passing trend. It's a necessary evolution that gives QA professionals the power to automate their checks without depending on the development team. Domain expertise — knowing what to test, when, and why — has always been more valuable than the ability to write a script. No-code finally lets that expertise translate into automated tests.

Previous article: Visual Testing FAQ: 20 Most Frequently Asked Questions

We build Delta-QA, a visual regression testing tool. Always open to feedback from the community!

Is Claude Design Really Laying Off Designers?

divyesh vekariya — Thu, 23 Apr 2026 08:00:48 +0000

The Truth Behind the 2026 AI Hype

TL;DR: Anthropic's Claude Design crashed Figma's stock and broke the internet. But is it actually a designer-killer — or just the biggest AI hype trick of 2026? Here's the real story, no panic required.

The Friday That Shook the Design World

On a quiet Friday in April 2026, Anthropic pushed Claude Design live. By Monday morning, Figma's stock was in freefall. Twitter was in meltdown. Design influencers were posting their "end of an era" takes. Thousands of junior UX designers were genuinely scared for their jobs.

So let's cut through the noise and answer the real question everyone is typing into Google:

Is Claude Design going to replace designers and eliminate design jobs?

The short answer: not the way you think. The long answer is more nuanced — and far more important for your career.

What Exactly Is Claude Design?

Claude Design is Anthropic's new AI-powered visual design tool, built on top of its Opus 4.7 model. Think of it as a turbocharged version of Google Stitch or Microsoft Designer — you describe what you want, and the AI generates a working visual prototype, one-pager, slide deck, or UI mockup.

Anthropic's own marketing is actually pretty modest. Their stated goal is to let users "make prototypes, slides, and one-pagers." Not to replace senior product designers. Not to redesign entire design systems. Not to kill Figma.

But markets don't read press releases carefully. Figma's stock tanked on the announcement alone — the same knee-jerk reaction we saw when Google Stitch launched, when Microsoft Designer launched, and when every other "AI design tool" was hyped as a Figma killer.

⚠️ Pattern Alert: Every 12–18 months, a new AI tool is declared a "Figma killer." Microsoft Designer (2022), Adobe Firefly (2023), Google Stitch (2025), now Claude Design (2026). Figma is still here. Designers are still employed. The hype cycle repeats.

The Dirty Secret: Claude Design Is Claude Code in a New Suit

What's Actually Under the Hood

Here's the part very few tech journalists are telling you: Claude Design is not fundamentally new technology. It outputs .jsx files — React components — which is exactly what Claude Code has been generating for over a year.

Expert designers who tested both tools side-by-side found that prompting regular Claude Code with a design request produces output that is in the same quality ballpark as Claude Design — sometimes even better. Claude Code's 3D globe animations are actually animated, while the Claude Design demo showed a flat texture painted on a sphere and called it 3D.

In other words: if you've had access to Claude Code, you've basically had Claude Design for months. The "new" product is primarily:

A polished UI wrapper
Some curated .md prompt files baked into the system
A marketing push timed to drive attention and investor confidence at a moment when AI companies are burning through cash

The panic is part of the product.

What Claude Design Actually Does Well

Let's be fair. Claude Design is genuinely useful for a specific audience doing specific things:

Non-designers who need "good enough" output fast — A founder building an MVP, a consultant needing a one-pager, a startup team without a design budget. Real upgrade from where they were.
Rapid prototyping for concept validation — It can generate a clickable UI mockup faster than any human designer can open Figma and set up a frame.
Template-level work, generated on demand — Instead of browsing ThemeForest or TemplateMonster and paying $30, you describe it and get something custom-assembled in seconds.
Slide decks and one-pagers — Exactly what it says on the tin. Solid utility here.

What Claude Design Cannot Do — And Why That Matters

The outputs are what design professionals call "average-plus." That's not an insult — it's a precise technical description. AI design tools are trained on an enormous corpus of existing design work. The model predicts what a "typical good design" looks like based on millions of examples. The result is statistically average: not terrible, not remarkable.

❌ Claude Design Struggles With

Original brand identity
Emotional storytelling through design
Accessibility and contrast nuance
Complex interaction design
Design that reflects a specific culture or audience
Strategic UX decisions
Design systems at enterprise scale
Visual craft and typography mastery

✅ Claude Design Does Well

Fast prototypes from text prompts
One-pagers and slides
Template-style UI generation
React/JSX code output
"Good enough" for no-design-budget teams
Iterating on existing styles
Simple landing pages

Notice something? The "does well" list describes what template websites and Canva have always done — just faster and more conversational. The "struggles with" list is what human designers actually get paid for.

Will Claude Design Replace Designers? The Real Answer

Yes and no — and the distinction matters enormously for your career.

It Will Replace Some Designers

Specifically, those doing pure component drag-and-drop work with no strategic thinking. Those building the same type of dashboard or landing page on repeat using a handful of familiar patterns. Those at the bottom of the skill tier who entered design during the tool-democratization wave of the 2010s and never developed genuine craft, taste, or strategic thinking.

Design as a field inflated significantly over the last decade. Tools got easier. "UI design" became accessible to anyone who could learn Figma. Some of that inflation is now correcting — and AI is accelerating that correction.

It Will NOT Replace Senior Designers

UX strategists, creative directors, brand designers, and anyone who thinks beyond pixels are safe. The reason is simple: AI produces average. Business demands differentiation. The ocean of "AI-generated sameness" is rising fast, which means standing out from it becomes more valuable, not less.

💬 Verdict

Claude Design is a template engine with a conversational interface. It is a real, useful tool for non-designers and for rapid prototyping. It will compress the market for low-skill, repetitive design work. It will not replace designers who think, strategize, craft, and differentiate. The designers most at risk are those who were already replaceable — not because AI is exceptional, but because their work was already algorithmic.

The Hype Machine: Why Companies Need You to Panic

Follow the Money

Frontier AI companies — Anthropic, OpenAI, Google DeepMind — are losing money at scale. They are burning through investor capital at extraordinary rates. To keep that capital flowing, they need to stay top of mind, generate buzz, and create the perception of constant, revolutionary progress.

Announcing a "design tool" achieves several goals simultaneously:

Gets massive media coverage
Drives new subscriptions
Frightens a large professional community (designers) into paying attention
Makes investors feel like innovation is accelerating

This is the same playbook that made Figma's stock drop when Google Stitch launched, when Adobe Firefly launched, when Microsoft Designer launched. Each time, the market overcorrected. Each time, the tool turned out to be a useful-but-limited product that served a different audience than professional designers. Each time, Figma survived.

What Designers Should Actually Do Right Now

A Practical 2026 Roadmap

Learn to use Claude Design and Claude Code immediately. Not because they replace you, but because they eliminate the boring parts of your job, freeing your time for higher-order work. Designers who use AI well will outcompete those who don't.
Move up the value chain. If your entire job is producing Figma screens that match a spec, you are in the vulnerable zone. Push toward UX strategy, research, design leadership, and creative direction.
Develop genuine taste and craft. The AI generates average. If you can produce work that is unmistakably not average — with strong typography, emotional resonance, cultural intelligence — you are differentiated.
Stop competing on speed. You cannot out-speed an AI that generates a prototype in 10 seconds. Compete on quality, insight, and the things that take human experience to achieve.
Design systems specialists: take note. The most vulnerable segment is pure design systems work — building and maintaining component libraries, token systems, and systematic UI. AI can now handle much of this systematically. Diversify your skills.

Who Is At Risk vs. Who Is Safe

🔴 At Risk	🟢 Safe
Drag-and-drop component builders	Senior UX strategists
Junior template designers	Brand & identity designers
Design systems specialists (lower tier)	Creative directors
Repetitive UI producers	UX researchers
"Good enough" generalists	Design leaders

The Bigger Picture: What This Moment Actually Means

We are living through a genuine inflection point — but not the one the hype suggests. AI is not suddenly replacing all designers in 2026. What is actually happening is a skill-tier compression event:

The bottom of the market (low-skill, repetitive, template-level work) is being automated
The top of the market (strategic, craft-driven, irreplaceable creative work) is becoming more valuable
The middle is getting squeezed

"Good enough" is becoming the new floor, not the ceiling. When every startup can generate an "okay" UI with a text prompt, "okay" stops being a competitive differentiator. Clients and companies will increasingly hire human designers only when they need something genuinely original, strategic, and excellent.

That is actually a better world for great designers. It is a harder world for mediocre ones.

Final Verdict: Should Designers Be Worried?

Some of them, yes. Most of them, no — but everyone should be paying close attention.

Claude Design is a genuinely useful tool that democratizes basic design output for non-designers. It is not a skilled designer operating at senior level. Its outputs are polished templates, not creative work. The Figma stock drop was an overreaction; markets do that.

The real signal under all the noise is the same one that has been visible for two years:

The floor for design quality is rising, which means the ceiling becomes the only place worth being.

Use the tools. Master the craft. Think beyond pixels. That is the answer in 2026, and it will still be the answer in 2027.

Thank you for taking time to read the Article.

Enjoyed the read? Drop some 👏 to fuel the next blog. Thanks for the support!

Forem

How MongoDB Executes a find() Query: A Complete Lifecycle Guide

The full journey of a find() query (quick overview)

Stage 1: The Client Sends a Query Over the Wire

Stage 2: Authentication Check

Stage 3: Authorization — Can You Read This Collection?

Stage 4: Query Parsing and BSON Validation

Stage 5: The Query Planner Enumerates Candidate Plans

Stage 6: Plan Cache Lookup — The Fast Path

Stage 7: Multi-Plan Trial — The Index Race

What about full collection scans (COLLSCAN)?

Stage 8: Index Scan (IXSCAN) or Collection Scan (COLLSCAN)

If an index is used (IXSCAN)

If no index is used (COLLSCAN)

How to spot a problem

Stage 9: The Storage Layer — WiredTiger Cache and Disk

Checking cache performance

Stage 10: Results Returned to the Client

What if there’s more data?

The Complete Picture — All 10 Stages

Closing notes: Key Takeaways for Production

How ORBIT Solves the Langflow CVE‑2026‑33017 Vulnerability

🔴 What Happened with Langflow

🛡️ How ORBIT's MCP Gateway Would Have Prevented It

1. Strict Schema Validation (OWASP MCP‑01)

The Hidden Attack Surface of Modern Cloud Apps in the Age of AI

What “Attack Surface” Means in Modern Cloud Applications

The Hidden Layers of the Cloud Attack Surface

Security at the Speed of AI

An Attack Story: The "SmartAssist" Compromise

The Solution: A Zero Trust, Defense-in-Depth Approach

Security as a Feature

Graph Algorithms for Coding Interviews: When to Use BFS, DFS, or Dijkstra

The three algorithms every interviewer expects you to know

BFS — Breadth-First Search

DFS — Depth-First Search

Dijkstra's Algorithm

The decision framework

What interviewers actually look for

How to study so graph algorithms actually stick

FAQ

Port Exhaustion, Context Switching, and Why "HttpClientFactory" Exists (.NET)

The two problems in one sentence

1. How HttpClient is tied to sockets and ports

Ephemeral ports and TIME_WAIT

The classic anti-pattern

2. What IHttpClientFactory fixes

3. Other libraries and approaches (same plumbing, nicer surface)

Typed clients (first-party)

Refit

Flurl

RestSharp

Polly and resilience

When HTTP is the wrong tool

4. Context switching: what it has to do with HTTP calls

OS thread context switches

Blocking async code

Async I/O is not “free,” but it scales better

5. HttpClient dos and don’ts (best practices)

Do

Don’t

6. Practical checklist

7. Closing thought

Further reading (official docs)

Microtasks: Why Promises Run First

The Tempting but Incomplete Explanation

Running the Experiments

A Hypothesis: Promises Are Just Higher-Priority Tasks

The Rule That Must Exist

Reframing Microtasks Properly

Why This Rule Must Exist

The Draining Behavior

The JavaScript Turn Model

The Mental Model to Keep

What This Prepares Us For Next

Claude Design is Replacing Designers?

Is Claude Design Really Laying Off Designers?

Polymarket API for Developers: Data, CLOB, and Polygon RPС

What is Polymarket?

Polygon PoS: the settlement layer

The full journey of a `find()` query (quick overview)

1. How `HttpClient` is tied to sockets and ports

Ephemeral ports and `TIME_WAIT`

2. What `IHttpClientFactory` fixes

5. `HttpClient` dos and don’ts (best practices)