DEV Community: Moksh Gupta

Building a Python MCP Server from Scratch - A Practical GitHub API Guide

Moksh Gupta — Fri, 19 Jun 2026 08:53:46 +0000

The Model Context Protocol has gone from a niche Anthropic project to industry-standard infrastructure in under two years - hitting 97 million monthly SDK downloads and earning a permanent home under the Linux Foundation. Every major AI coding tool now speaks MCP natively, yet most tutorials either list pre-built servers to install or recite the spec without building anything real.

This guide walks you through writing a Python MCP server from zero: defining tools, resources, and prompts, testing with the MCP Inspector, and wiring it into Claude Desktop or Claude Code. The working example targets the GitHub API - a practical starting point you can extend for any project that needs live external data inside an AI assistant.

Prerequisites: Python 3.10+, uv or pip, and Claude Desktop or Claude Code installed.

What an MCP Server Actually Does

MCP is a JSON-RPC protocol that gives an AI client a standardized way to call external services. The client - Claude, Cursor, or any compliant tool - sends a request and your server handles it, regardless of what language it is written in.

Every MCP server exposes three core primitives. Tools are callable functions the AI can invoke to take action or fetch data. Resources are read-only data endpoints the AI can pull from - similar to files or database records. Prompts are reusable instruction templates stored on the server and referenced by name, useful for standardizing workflows across a team.

For transport, this guide uses stdio - the server runs as a subprocess and communicates over stdin/stdout. This works out of the box with Claude Desktop and Claude Code. For production or remote deployments, Streamable HTTP is the alternative.

Setting Up the Project

Create a fresh directory and install the MCP SDK with the [cli] extra, which includes the dev server and inspector launcher:

mkdir github-mcp-server
cd github-mcp-server
uv init .
uv add "mcp[cli]" httpx

If you prefer pip, run pip install "mcp[cli]" httpx instead. Your project needs just three files: server.py, pyproject.toml (if using uv), and an optional .env for your GitHub token.

A Minimal Tool in 10 Lines

Before diving into the full server, start with the simplest possible working example. This lets you confirm the SDK is wired up correctly before adding any real logic:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello-mcp")

@mcp.tool()
def greet(name: str) -> str:
    """Return a personalized greeting. Use this when asked to greet someone."""
    return f"Hello, {name}! Your MCP server is working."

if __name__ == "__main__":
    mcp.run(transport="stdio")

Run uv run mcp dev server.py to launch the MCP Inspector at http://localhost:5173. Navigate to the Tools tab, call greet with any name, and confirm the response. Three things matter here: FastMCP handles all JSON-RPC plumbing, the @mcp.tool() decorator auto-generates a schema from your type hints, and the docstring is what the AI reads to decide whether to call this tool - write it clearly.

Building the GitHub Tools Server

Now replace that minimal example with a real server. This version exposes two tools: one that fetches repository metadata and one that lists open issues, both backed by live GitHub API calls via httpx.

import os, logging, sys, httpx
from pydantic import BaseModel
from mcp.server.fastmcp import FastMCP

logging.basicConfig(stream=sys.stderr, level=logging.INFO)
logger = logging.getLogger(__name__)

mcp = FastMCP(
    "github-tools",
    instructions=(
        "This server provides tools to interact with the GitHub API. "
        "Use get_repo_info to fetch repository metadata. "
        "Use list_open_issues to retrieve open issues for a repository."
    ),
)

GITHUB_TOKEN = os.environ.get("GITHUB_TOKEN", "")

def _github_headers() -> dict[str, str]:
    headers = {
        "Accept": "application/vnd.github+json",
        "X-GitHub-Api-Version": "2022-11-28",
    }
    if GITHUB_TOKEN:
        headers["Authorization"] = f"Bearer {GITHUB_TOKEN}"
    return headers

class RepoInfo(BaseModel):
    full_name: str
    description: str | None
    stars: int
    forks: int
    open_issues: int
    language: str | None
    url: str

@mcp.tool()
async def get_repo_info(owner: str, repo: str) -> RepoInfo:
    """
    Fetch metadata for a GitHub repository including stars, forks, and open issue count.
    Args:
        owner: GitHub username or organization (e.g. 'anthropics')
        repo: Repository name (e.g. 'claude-code')
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/repos/{owner}/{repo}",
            headers=_github_headers(),
            timeout=10.0,
        )
        response.raise_for_status()
    data = response.json()
    return RepoInfo(
        full_name=data["full_name"],
        description=data.get("description"),
        stars=data["stargazers_count"],
        forks=data["forks_count"],
        open_issues=data["open_issues_count"],
        language=data.get("language"),
        url=data["html_url"],
    )

@mcp.tool()
async def list_open_issues(owner: str, repo: str, limit: int = 10) -> str:
    """
    List open issues for a GitHub repository, ordered by most recently updated.
    Args:
        owner: GitHub username or organization
        repo: Repository name
        limit: Max issues to return (1-30, default 10)
    """
    limit = max(1, min(limit, 30))
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/repos/{owner}/{repo}/issues",
            headers=_github_headers(),
            params={"state": "open", "per_page": limit, "sort": "updated"},
            timeout=10.0,
        )
        response.raise_for_status()
    issues = response.json()
    if not issues:
        return f"No open issues found for {owner}/{repo}."
    lines = [f"Open issues in **{owner}/{repo}** (showing {len(issues)}):\n"]
    for issue in issues:
        lines.append(f"- #{issue['number']}: {issue['title']}")
    return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

A few deliberate design choices are worth noting. Returning a Pydantic model from a tool gives the AI a typed, structured response it can reference field by field - far more reliable than parsing a formatted string. For string-return tools, catching exceptions and returning an error message is safer than letting them propagate, since an unhandled exception under stdio can kill the entire connection. Always clamp numeric inputs like limit - the AI will occasionally send 0, 100, or a string.

Adding Resources and Prompts

Resources let the AI read data passively. Here is one that reports whether a GitHub token is configured, and a dynamic one that fetches a repo's README:

@mcp.resource("config://github-tools/status")
def server_status() -> str:
    """Report whether the server has a GitHub token configured."""
    auth_status = "authenticated" if GITHUB_TOKEN else "unauthenticated (rate-limited to 60 req/hr)"
    return f"GitHub Tools MCP Server\nStatus: {auth_status}"

@mcp.resource("github://repos/{owner}/{repo}/readme")
async def get_readme(owner: str, repo: str) -> str:
    """Fetch the raw README content for a repository."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/repos/{owner}/{repo}/readme",
            headers={**_github_headers(), "Accept": "application/vnd.github.raw+json"},
            timeout=10.0,
        )
        if response.status_code == 404:
            return "No README found for this repository."
        response.raise_for_status()
        return response.text

Prompts are stored instruction templates any MCP client can call by name. This one structures a code review request around the GitHub tools we defined:

@mcp.prompt()
def review_pull_request(owner: str, repo: str, pr_number: int) -> str:
    """Prompt template for reviewing a GitHub pull request."""
    return (
        f"Please review pull request #{pr_number} in {owner}/{repo}. "
        f"Start by fetching the repository info with get_repo_info, "
        f"then list the open issues to understand the project context. "
        f"Focus your review on correctness, performance, and adherence to the project's patterns."
    )

Testing with the MCP Inspector

The fastest way to validate your server is with the built-in inspector - no Claude required. Run uv run mcp dev server.py and open http://localhost:5173.

Set your GITHUB_TOKEN in the Environment Variables section before connecting. Then test tools in the Tools tab, verify resources in the Resources tab, and confirm prompts show up in the Prompts tab. If anything fails, the Logs panel shows the raw JSON-RPC exchange, which is the most direct way to pinpoint the issue.

Connecting to Claude Desktop

Open the Claude Desktop config file - on macOS at ~/Library/Application Support/Claude/claude_desktop_config.json, on Windows at %APPDATA%\Claude\claude_desktop_config.json. Add your server under mcpServers:

{
  "mcpServers": {
    "github-tools": {
      "command": "uv",
      "args": [
        "run", "--with", "mcp[cli]", "--with", "httpx",
        "python", "/absolute/path/to/github-mcp-server/server.py"
      ],
      "env": {
        "PYTHONUNBUFFERED": "1",
        "GITHUB_TOKEN": "your_github_token_here"
      }
    }
  }
}

Use uv run rather than a bare python command - Claude Desktop spawns its own shell environment without your PATH, so bare python will often fail. Fully quit and restart Claude Desktop after saving. A plug icon in the input box confirms the server connected.

Connecting to Claude Code

For Claude Code, use the claude mcp add CLI command. The -- separator is required to separate the server name from the launch command:

claude mcp add github-tools \
  -e GITHUB_TOKEN=your_token \
  -e PYTHONUNBUFFERED=1 \
  -- uv run --with "mcp[cli]" --with httpx python /absolute/path/to/server.py

To share the server config with your team, use --scope project. This writes an .mcp.json file to the repository root and prompts team members to activate it when they open the project. Run claude mcp list to confirm registration.

References

Original article: https://devtoollab.com/blog/build-mcp-server-python
MCP Python SDK: https://github.com/modelcontextprotocol/python-sdk
FastMCP documentation: https://gofastmcp.com
MCP specification (Linux Foundation): https://spec.modelcontextprotocol.io
httpx documentation: https://www.python-httpx.org
GitHub REST API reference: https://docs.github.com/en/rest

Node.js vs Bun vs Deno 2 in 2026: Which JavaScript Runtime Should You Actually Use?

Moksh Gupta — Thu, 18 Jun 2026 05:34:55 +0000

In 2026, the JavaScript runtime landscape looks very different from just two years ago. Trigger.dev switched to Bun and reported a 5x throughput improvement on identical hardware. Anthropic acquired Bun and uses it in Claude Code's CLI. Deno 2 shipped real Node.js compatibility, bringing enterprise teams on board. And Node.js 24 quietly added native TypeScript execution alongside a production-ready built-in test runner.

The question developers now face is not "should I switch?" - it is "which runtime fits which job?" This guide covers where each runtime actually wins in 2026, backed by numbers.

What Each Runtime Shipped Recently

Node.js 24 reached Active LTS status with a major quality-of-life upgrade: --experimental-strip-types is now stable, letting you run .ts files directly without a separate build step. The require(esm) interop is also stable in v24, ending years of CommonJS and ESM friction. The built-in node:test module gained coverage reporting, mocking support, and describe/it APIs. V8 13.6 makes JSON serialization up to 2x faster on large objects.

Bun 1.3 is still the all-in-one runtime - it packs a package manager, bundler, and test runner into a single binary, running on JavaScriptCore (Safari's engine) for lower memory and faster cold starts than V8. It added a built-in Redis client in 1.3, joining a native SQLite driver. The bun compile command produces single-file executables, making it the cleanest option for distributing CLI tools. Anthropic's acquisition signals long-term institutional backing.

Deno 2.8 completed the Node.js compatibility work started in v2.0. It now handles package.json, node_modules, npm workspaces, and most CommonJS packages with little friction. New additions include deno audit, a dx command similar to npx, self-extracting compiled binaries, and stabilization of the Temporal API.

Performance Benchmarks

On a plain REST endpoint with no database, Bun with Hono handles around 110,000 requests per second. Deno reaches roughly 85,000 req/s, while Node.js with Express lands near 50,000 req/s. In realistic apps with database calls and middleware, the gap narrows but Bun still leads at around 14,320 req/s versus Node's 5,240.

Cold start times tell an equally clear story. A hello-world process starts in 8-15ms with Bun, 40-60ms with Deno, and 60-120ms with Node.js. On AWS Lambda, Bun averages a 156ms cold start compared to Node's 245ms - a 35% difference that adds up quickly in pay-per-invocation billing.

Memory usage follows the same pattern. An idle Bun process uses around 18MB; Deno uses roughly 30MB; Node.js around 40MB. At 5,000 concurrent WebSocket connections, Bun uses 620MB versus Node's 890MB - a meaningful difference when running many processes per server.

Package install speed is where Bun is the clear standout. An 847-package monorepo installs in 1.2 seconds with bun install versus 32 seconds with npm. On a 1,847-dependency project, the gap grows to 47 seconds versus 17-20 minutes.

TypeScript Support - The Real Practical Difference

All three runtimes can execute TypeScript without a separate compile step in 2026, but their handling of TypeScript features differs significantly.

Bun and Deno support enums, decorators, and TypeScript namespaces natively out of the box. Node.js 24's strip-types mode only removes type annotations - it does not transform TypeScript syntax, so enums and decorators still require a bundler like tsx or esbuild.

Deno also offers something Bun and Node.js do not: deno check server.ts runs a full tsc pass and surfaces type errors before runtime. Both Bun and Node.js strip types silently, meaning type errors go undetected until they crash at runtime - unless you run a separate tsc step.

Built-in Tooling Comparison

Bun and Deno both cut down the toolchain setup required for new projects. A fresh Bun project comes with TypeScript support, a test runner, and a bundler - no installs needed. Deno ships a linter, formatter, test runner, doc generator, and compiler as built-in subcommands.

Node.js 24 has been closing this gap. Its built-in node:test module now supports coverage, mocking, and describe/it APIs - making it a practical Jest replacement. But there is still no built-in bundler or linter, so tools like esbuild and ESLint remain part of the standard workflow.

Writing an HTTP Server in Each Runtime

Bun and Deno both use the web-standard Request/Response API, making code portable to Cloudflare Workers, edge functions, and browser Service Workers. Node.js uses its own HTTP module by default.

Node.js 24: createServer() from node:http, run with node --experimental-strip-types server.ts
Bun: Bun.serve({ fetch(req) {...} }), run with bun run server.ts
Deno: Deno.serve((req) => {...}), run with deno run --allow-net server.ts

The Bun and Deno APIs align with how you write handlers in edge environments, which makes code more portable across deployment targets.

Production Readiness - Known Gaps

Bun's main production concern is stability in long-running services. Memory leaks have been reported and partially patched through Bun 1.1.x, but developers continue to flag instability in processes running for days. There is no formal LTS program, so breaking changes can ship at any version. The ongoing Zig-to-Rust rewrite adds short-term uncertainty.

Deno's main challenge is ecosystem coverage. Developer adoption sits at roughly 2.4% versus Node.js's 42.65%. npm compatibility covers about 90-95% of packages, but native addons and Node-internal-dependent packages remain hit-or-miss. Next.js and Remix are not fully supported.

Node.js's limitations are more familiar: slower cold starts, no built-in bundler, and slower package installs. ESM/CommonJS migration friction, while improved in v24, still causes headaches on large codebases. TypeScript enum and decorator support still requires a build tool.

When to Use Which Runtime

Here is a practical decision guide based on use case:

Serverless and edge functions - Bun (8ms cold start, 35% faster Lambda)
High-throughput REST APIs - Bun (2-3x req/s in real apps, lower memory per process)
CLI tools and scripts - Bun for single-file compiled binaries; Deno for sandboxed execution
Enterprise and regulated workloads - Node.js (30-month LTS, OpenJS Foundation governance)
Existing Node.js codebases - Node.js (ecosystem lock-in is real; switch only with measurable benefit)
TypeScript-first greenfield projects - Deno (built-in type checking, web standards first)
Security-sensitive applications - Deno (default-deny permissions; Bun has no sandbox; Node's model is opt-in)
Real-time and WebSocket servers - Bun (2.8x more messages/sec at 5,000 connections)
Monorepo tooling - Bun (1.2s vs 32s install on an 847-package repo)
Edge CDN deployment - Deno (Deno Deploy is first-class; no Bun equivalent)

How to Install and Try Each Runtime Today

# Node.js via nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
nvm install --lts

# Bun
curl -fsSL https://bun.sh/install | bash

# Deno
curl -fsSL https://deno.land/install.sh | sh

Running a TypeScript file in each:

# Node.js 24 - strips types only, no enums or decorators
node --experimental-strip-types script.ts

# Bun - full TypeScript support
bun run script.ts

# Deno - runs without type checking
deno run script.ts

# Deno - with full type checking before run
deno check script.ts && deno run script.ts

To benchmark your actual server, install autocannon and test under real load before committing to a runtime.

Conclusion

The JavaScript runtime space in 2026 is no longer a single-winner conversation. Bun, Node.js, and Deno have each carved out distinct strengths - and the ecosystem is better for it. Bun pushed the industry to take cold start times and install speed seriously. Deno proved that TypeScript-first and security-by-default were viable design choices. Node.js responded by shipping a native test runner, built-in fetch, and TypeScript stripping.

Pick the runtime that removes the most friction for your specific workflow. If you are running a high-throughput API that starts frequently, Bun's numbers are hard to argue with. If you are maintaining a large enterprise codebase with strict audit requirements, Node.js LTS is the path of least resistance. If you are writing TypeScript-heavy serverless functions or CLIs, Deno's zero-config type checking is genuinely pleasant.

Run the benchmarks that matter for your actual application - five minutes of autocannon on your real endpoint is worth more than any comparison table.

References

Original article: https://devtoollab.com/blog/javascript-runtime-comparison
Node.js official documentation: https://nodejs.org/
Bun official documentation: https://bun.sh/
Deno official documentation: https://deno.com/
nvm (Node Version Manager): https://github.com/nvm-sh/nvm

DevToolLab Launches a Free Discord Community for Developers

Moksh Gupta — Wed, 17 Jun 2026 10:05:25 +0000

Building a developer toolkit is one thing, but creating a community around it is a different challenge. DevToolLab has expanded to 500+ browser-based utilities, and now there is a dedicated space where developers can connect, ask questions, and share what they are working on. The DevToolLab Discord server is open and free to join today.

What the Discord Server Is Actually For

The server has four core purposes. You can get direct help when a tool behaves unexpectedly. You can suggest new tools or request features - the best ideas have always come from developers who hit a real workflow gap. You can share what you are building and get feedback from peers. And you get early announcements: updates get posted in the server before they appear anywhere else.

How to Join the DevToolLab Discord Server

Joining takes under a minute. Go to discord.gg/zzNzd9ssG in your browser. If you do not yet have a Discord account, creating one is free and does not require email verification to start reading. Once inside, accept the server rules and post a brief intro in the introductions channel. All channels are open to every member with no paid tiers.

Why Discord Works Well for a Developer Community

Discord was chosen over Slack and forums for practical reasons. Threaded replies keep technical discussions organized without cluttering the main channel. Search is fully open with no login required, so useful answers from months ago remain accessible. And Discord is already part of the daily routine for a large percentage of developers, which reduces friction to participate.

About DevToolLab

DevToolLab is a free collection of 500+ browser-based utilities built for developers who need quick results without installing anything. The toolset covers JSON formatting, base64 encoding, URL tracking, password generation, webhook inspection, and dozens of other everyday tasks. The Discord server extends the platform into a community - a place where users and the team can actually communicate.

Tools Worth Bookmarking Before You Join

Several DevToolLab tools come up regularly in community help threads. The Webhook Receiver generates a live URL for inspecting HTTP payloads without writing handling code. The Pastebin tool creates shareable links with syntax highlighting for 30+ languages. The Code to Image Converter produces clean PNGs from snippets for posting in Discord. The JSON Formatter cleans up API responses before you paste them into a help request.

References

Original article: https://devtoollab.com/blog/devtoollab-discord-community
DevToolLab Discord Server invite: https://discord.gg/zzNzd9ssG
DevToolLab X Account: https://x.com/devtoollab
DevToolLab GitHub Account: https://github.com/DevToolLab
DevToolLab LinkedIn Account: https://www.linkedin.com/company/devtoollab

Claude Fable 5 Went Offline in 72 Hours: What Developers Need to Know About the US Export Control Shutdown

Moksh Gupta — Mon, 15 Jun 2026 17:14:31 +0000

Anthropic launched Claude Fable 5 on June 9, 2026. Three days later, on June 12, a US government export control directive arrived at 5:21 p.m. ET ordering Anthropic to suspend access to the model. By that evening, every API call to claude-fable-5 and claude-mythos-5 returned an error. No grace period. No migration window. No workaround at the API layer.

This is what happened, what drove it, and what you need to do if your application was running on either model.

What Claude Fable 5 and Mythos 5 Were

Claude Fable 5 was Anthropic's most capable publicly available model at launch - designed for complex reasoning, code analysis, and research tasks. Claude Mythos 5 is the underlying architecture that Fable 5 is built on, minus an additional safety classifier layer. Mythos 5 was already limited to a narrower enterprise and research audience before the shutdown happened.

The safety architecture in Fable 5 is worth understanding. In high-risk domains like cybersecurity and biology, an extra classifier layer monitors active sessions. If it detects potential misuse, it automatically reroutes that session to Claude Opus 4.8 instead of the full Fable 5 model. Anthropic said this fallback triggers in fewer than 5% of sessions. Mythos 5 has no equivalent fallback.

Both models had been live for exactly three days when the shutdown order arrived.

The Jailbreak Claim That Set Off the Chain of Events

Shortly after Fable 5 launched, AI researcher Pliny the Liberator published a claimed jailbreak using a coordinated multi-agent strategy. The approach used multiple AI instances working in combination to probe the edges of Fable 5's classifier - something a single session could not do effectively on its own. The claim was that this technique produced output useful for developing cyberattack tooling and stack exploits.

Anthropic disputed the framing publicly. In a statement covered by SecurityWeek, the company said the technique does not satisfy its definition of a true jailbreak - which requires bypassing core safeguards and delivering meaningful capability uplift toward high-risk activities, not just producing tangentially related output.

Amazon's internal security team reached a different conclusion. Amazon CEO Andy Jassy - who is simultaneously Anthropic's largest investor, a board participant, and the operator of the cloud infrastructure running both models - personally escalated the findings to Treasury Secretary Scott Bessent. That escalation triggered the regulatory review that produced the June 12 directive.

The Export Control Directive That Forced a Global Shutdown

The directive Anthropic received on June 12 was unusually broad in scope. It ordered suspension of access to both models for any foreign national - whether they were located inside or outside the United States. That definition extended to Anthropic's own foreign national employees working in its US offices.

The compliance problem was immediate and structural. Anthropic does not have real-time nationality verification in its API pipeline. Reliably determining which of millions of active API sessions belonged to foreign nationals was not feasible within the directive's window. The only path to compliance was to shut both models down for all users, everywhere.

CNBC confirmed the shutdown happened the same evening the directive arrived. Anthropic published an official statement at anthropic.com/news/fable-mythos-access, describing the situation as stemming from a "misunderstanding" and confirming it is working with the government to restore access. The company also confirmed it had not received specific technical details about the national security concerns underpinning the directive.

Which Anthropic Models Are Still Available

The export control directive named only claude-fable-5 and claude-mythos-5. All other Anthropic models are unaffected and operating normally.

Claude Opus 4.8, Sonnet 4.6, and Haiku 4.5 are all accepting requests. The Anthropic models overview page at platform.claude.com/docs/en/about-claude/models/overview reflects live model status and is the authoritative reference for current availability.

If your production traffic runs on any model identifier other than the two named endpoints, your application is unaffected by this shutdown.

How to Migrate from Claude Fable 5 to Opus 4.8

Any application calling claude-fable-5 or claude-mythos-5 will receive errors at the infrastructure level. Retry logic and timeout handling will not resolve this - the models are disabled on Anthropic's side, not yours.

The direct replacement is claude-opus-4-8. This is the same model Fable 5 itself used as its internal safety fallback for flagged sessions, which means output quality for the large majority of production use cases will be comparable.

For applications where Opus 4.8 costs or latency are a concern and Fable 5 was primarily used for general reasoning - not top-end capability - claude-sonnet-4-6 is a viable intermediate option.

If your model identifier is spread across a codebase, a targeted search will surface all locations before errors reach users:

# Find all claude-fable-5 and claude-mythos-5 references
grep -rn "claude-fable-5\|claude-mythos-5" . \
  --include="*.py" \
  --include="*.ts" \
  --include="*.js" \
  --include="*.json" \
  --include="*.env"

If you store your model identifier in a config file or environment variable rather than hardcoded literals, this is a one-line change. If it is scattered across files, the grep output gives you a complete list to work through.

The Structural Tension This Incident Exposed

Several things about this sequence are worth noting beyond the immediate operational impact.

The compliance problem Anthropic faced is structurally difficult to solve. Export control law was designed around physical goods with trackable supply chains. Applying it to API endpoints serving millions of requests daily from users across every country - with no reliable real-time nationality signal in the authentication layer - creates an enforcement problem that "just verify users" does not cleanly solve. The mechanism Anthropic will use to restore access while remaining compliant has not been made public yet.

The Amazon escalation path deserves attention. Amazon is simultaneously Anthropic's primary cloud infrastructure provider, its largest investor, a board participant, and a direct competitor in the AI model market through Amazon Bedrock. That overlap of roles puts Amazon in a position where it has responsibility for reporting security concerns, financial interest in Anthropic's performance, and a competitive stake in Anthropic's market position. The June 12 events are the first time that combination became visible as a public incident with direct operational consequences for developers.

Anthropic's "misunderstanding" framing is technically defensible based on its own definitions. But the government issued the directive regardless, and the result for developers was the same: both models went dark three days after launch with no grandfathered access period.

When Will Claude Fable 5 Return

Anthropic has confirmed it is working with the government toward restoring access. The most plausible resolution paths are either Anthropic deploying nationality verification at the API layer - technically achievable but requiring engineering work and likely terms-of-service changes - or the government narrowing the directive to a scope that does not require global shutdown.

Neither path is fast. Export control negotiations typically move on a timeline of weeks to months. The practical recommendation: migrate to Opus 4.8 now, treat Fable 5's return as an upgrade opportunity rather than something to block on, and monitor status.anthropic.com for live updates.

For teams that specifically need Fable 5's top-end reasoning capability and cannot substitute, there is no workaround at present. The shutdown is at Anthropic's infrastructure level and cannot be circumvented with a different API key or region header.

Timeline of Events

June 9, 2026 - Claude Fable 5 and Mythos 5 launch publicly
June 12, 2026 (morning) - Pliny the Liberator publishes claimed Fable 5 jailbreak
June 12, 2026 (afternoon) - Amazon researchers report findings; Andy Jassy escalates to Treasury Secretary Bessent
June 12, 2026 (5:21 p.m. ET) - US export control directive arrives at Anthropic
June 12, 2026 (evening) - Anthropic disables both models globally
June 13, 2026 - Anthropic publishes official statement; disputes jailbreak characterization

Conclusion

Migrate to claude-opus-4-8 now. It was already Fable 5's internal fallback and covers the overwhelming majority of production use cases without significant quality degradation. If Fable 5 returns, switching back is a one-line change.

Monitor status.anthropic.com for live updates, and keep an eye on the official Anthropic news page for any announcements about the path to restored access.

References

Source article: https://devtoollab.com/blog/claude-fable-5-shutdown
Anthropic official statement: https://www.anthropic.com/news/fable-mythos-access
Anthropic model status: https://status.anthropic.com/
Anthropic models overview: https://platform.claude.com/docs/en/about-claude/models/overview
CNBC coverage: https://www.cnbc.com/2026/06/12/anthropic-disables-access-to-fable-5-and-mythos-5-to-comply-with-government-directive.html
SecurityWeek - Anthropic disputes jailbreak: https://www.securityweek.com/anthropic-disputes-fable-5-ai-jailbreak/

Cognitive Debt: The Hidden Cost of Letting AI Write Your Code

Moksh Gupta — Sun, 14 Jun 2026 18:19:21 +0000

In early 2026, Anthropic researchers ran an experiment with 52 junior developers. Half used an AI assistant to learn an unfamiliar Python library. The other half worked without one. Both groups finished the task. But when tested on how well they understood the code they had just written, the AI-assisted group scored 50% on a comprehension quiz - versus 67% for the unassisted group.

That 17-percentage-point gap has a name: cognitive debt. It is one of the most important concepts in software engineering right now, and most developers are not paying enough attention to it.

What Is Cognitive Debt?

Cognitive debt describes the growing gap between the volume of code that exists in a system and the amount that any developer genuinely understands. It is not a new term, but it crystallized across multiple research streams in early 2026.

Addy Osmani (Google Chrome) described it as "comprehension debt" - the hidden cost that accumulates when code becomes cheap to generate but understanding still requires deliberate effort. Margaret-Anne Storey (University of Victoria) formalized the concept in a March 2026 arXiv paper, framing it as a team-level problem and extending it into a Triple Debt Model: technical debt in the code, cognitive debt in the people, and intent debt - the missing rationale that both humans and AI agents need to safely work with code.

Cognitive Debt vs. Technical Debt

These two ideas are easy to conflate, but they are fundamentally different problems.

Technical debt lives in the code - it shows up as slow builds, tangled dependencies, and failing tests. Cognitive debt lives in people - it surfaces as an inability to explain, debug, or extend code that the team themselves wrote.

The critical difference: technical debt announces itself through friction. Cognitive debt breeds false confidence. Your tests are green, velocity looks fine, and nobody realizes the system is fragile until something breaks in production and the team cannot reason through why.

What the Research Shows

The Anthropic study found more than just a comprehension gap. Developers who delegated fully to AI - asking it to write code - scored below 40% on comprehension. Developers who used AI as a learning tool - asking it to explain concepts - scored above 65%, matching or beating the no-AI group. The tool is not the problem. The usage pattern is.

A METR study added another dimension: experienced developers working on their own large codebases took 19% longer to complete tasks when using AI-assisted tools versus working without them. Before the study, those same developers expected AI would speed them up by 24%. After the study, they still believed it had sped them up by 20%. The confidence that AI tools produce appears to be partially disconnected from actual performance.

A June 2025 MIT Media Lab study used EEG brain scans to compare LLM-assisted writing versus search-assisted writing versus unassisted writing. Brain connectivity - the measure of how actively and broadly neural networks are engaged - scaled down as tool support increased. LLM-assisted work produced the output but not the neural engagement behind it.

Finally, a February 2026 study by Sankaranarayanan introduced an "Explanation Gate" - requiring developers to explain AI-generated code before integrating it. The unrestricted AI group had a 77% failure rate on a maintenance task after a 30-minute AI blackout. The Explanation Gate group had a 39% failure rate. One simple intervention cut the failure rate nearly in half.

How Cognitive Debt Accumulates

There are three core mechanisms.

First, AI eliminates productive struggle. Learning science shows that difficulty during study - retrieval practice, working through confusion - is what drives long-term retention. When you paste an error message into a chat interface and receive a fix, the bug is resolved but the learning moment is bypassed.

Second, there is a generation-comprehension gap. AI can produce 200 lines of working code in 30 seconds. Building a genuine mental model of those 200 lines and how they interact with the rest of your system takes considerably longer. Most developers skip that step. GitClear's analysis of 211 million changed lines found code duplication increased eightfold in 2024, while refactoring - the activity most closely linked to deep code understanding - dropped from 25% of changed lines in 2021 to under 10% in 2024.

Third, automation complacency is a well-documented failure mode in aviation and nuclear power. Sustained automation use erodes the ability to catch what the automation gets wrong. A 2026 study found developers accept faulty AI reasoning 73.2% of the time.

Warning Signs You Are Accumulating Cognitive Debt

Here are signals worth watching for:

You cannot explain a design decision in code review without saying "the AI suggested it."
Your productivity drops sharply when AI tools are unavailable due to rate limits or outages.
There are files in your own codebase you mentally route around because you do not fully follow them.
You paste error messages into chat without first forming a hypothesis about the cause.
You can build new features easily but struggle to debug code that is six months old.
You accept AI solutions without being able to articulate why they work.

The Counter-Arguments Are Worth Taking Seriously

Not everyone agrees that AI-induced skill erosion is a real problem, and the pushback deserves honest engagement.

Every abstraction layer in history - assembly to C, C to Python, Python to frameworks - was accused of de-skilling developers. Each one expanded the developer population and enabled new categories of software. AI may follow the same pattern.

The Anthropic study also contains its own counter-argument: developers who used AI for learning scored as well as the no-AI group. The problem is passive delegation, not AI tools themselves. Used as a Socratic tutor, AI may actually accelerate skill development. And Stack Overflow's 2026 data shows 64% of developers now use AI specifically to learn - up from 37% in 2024.

A Practical Protocol for Fighting Cognitive Debt

The research literature and practitioner experience converge on a few high-leverage interventions.

Apply the Explanation Gate. Before integrating any AI-generated code, explain it - why it works this way, and what would break if a specific part changed. Sankaranarayanan's study showed this cuts maintenance failure rates dramatically with no measurable impact on initial productivity.

Attempt problems before consulting AI. Spend 15 to 30 minutes working through a problem independently. The wrong hypotheses and partial approaches during that time are where schema formation happens. When you then consult AI, you arrive with a framework for evaluating its answer.

Ask "why?" more than "write this." Prompts like "explain the time complexity of this approach" or "what are the tradeoffs between these two implementations" build understanding. The code AI produces is the output. The understanding you build by interrogating it is the asset.

Schedule no-AI days. Reserve one day per week for unassisted work. The goal is calibration - measuring your actual skill level and identifying the gaps that have opened since last time.

Design before you generate. Use AI to reason through architecture and tradeoffs before writing any code. Then generate implementation to fill in a design you already understand, rather than receiving a design embedded in code you do not.

How to Audit Your Team's Cognitive Debt

Run this exercise quarterly. No special tooling required.

Ask three engineers to independently whiteboard the architecture of a shared system. Where the diagrams diverge is where cognitive debt has accumulated.

Pick a 50-line function that was AI-generated and committed more than two weeks ago. Ask the author to explain it without looking at it. Track whether they can recover the reasoning.

Give an engineer a bug report for AI-generated code they have not touched before, with AI access removed, for 20 minutes. Observe whether they form and test hypotheses independently or stall immediately.

The Broader Industry Picture

The individual-level concern is real, but the structural concern may be larger. A codebase where developers have deep understanding is fundamentally different from one where working code was generated and accepted without thorough review. The first can be extended and maintained. The second accumulates brittleness that is only visible during incidents, migrations, and onboarding.

Stack Overflow's 2025 survey (49,009 respondents across 166 countries) found developer trust in AI accuracy fell from 40% to 29% year-over-year, and overall favorability dropped from 72% to 60%, even as adoption continued rising. Developers are noticing something. Cognitive debt is part of what they are noticing.

Conclusion

AI coding tools offer genuine productivity gains. They also carry a measurable comprehension cost that does not appear in standard metrics until it becomes a crisis. The gap between those two outcomes comes down to one thing: whether you keep the explanation work as your own responsibility.

Code you can generate but not explain is a liability shaped like an asset. Attempt before delegating. Explain before integrating. Ask "why?" more than "write this." The source code is what the AI produces. The mental model is what only you can build.

References

Source article: https://devtoollab.com/blog/cognitive-debt-ai-coding
Anthropic study (Shen and Tamkin, 2026): https://arxiv.org/abs/2601.20245
Margaret-Anne Storey cognitive debt paper: https://arxiv.org/abs/2603.22106
Addy Osmani on comprehension debt: https://addyosmani.com/blog/comprehension-debt/
MIT Media Lab brain study: https://www.media.mit.edu/publications/your-brain-on-chatgpt/
GitClear code quality analysis: https://www.gitclear.com/ai_assistant_code_quality_2025_research
Stack Overflow Developer Survey 2025: https://survey.stackoverflow.co/2025

WebAssembly in 2026: A Practical Guide to Wasm and WASI for Modern Developers

Moksh Gupta — Sun, 14 Jun 2026 18:01:05 +0000

Google Sheets recalculates cells twice as fast after shifting its compute engine to WebAssembly. Figma cut initial load time by 3x. Shopify executes custom checkout rules compiled from Rust to Wasm at the CDN edge - all in production, serving millions of users every day.

WebAssembly started as a way to bring C++ into the browser. Today, in 2026, it is a universal binary runtime that executes in browsers, edge networks, serverless functions, and even AI inference pipelines. The W3C ratified Wasm 3.0 as a formal standard in September 2025, and WASI Preview 2 is now stable. The tooling has matured to a point where it genuinely works.

Over 70% of developers now evaluate or actively use Wasm outside the browser, per CNCF survey data. This is no longer a niche experiment.

What Is WebAssembly?

WebAssembly is a compact binary instruction format designed to run inside a sandboxed virtual machine. That VM is embedded in every major browser, in standalone runtimes like Wasmtime, and on cloud platforms from Cloudflare Workers to AWS Lambda.

Key properties that make it worth your attention:

Near-native speed - Wasm runs at 80-95% of native performance with no JIT warmup delay. The binary arrives structured for fast parsing, unlike JavaScript that must be parsed and compiled on every load.
Language-agnostic - Rust, C/C++, Go, Python, AssemblyScript, C#, and Kotlin all compile to Wasm. Your team picks the language; the runtime only sees the .wasm binary.
Deterministic execution - The same Wasm binary produces identical results whether it runs in Chrome, Firefox, Node.js, or Wasmtime on ARM or x86.
Sandboxed by default - A Wasm module starts with zero permissions. No filesystem, no network, no system calls unless the host runtime explicitly grants them.

Wasm does not replace JavaScript. It runs alongside it. JavaScript manages the DOM, events, and most application logic. Wasm handles the parts where JavaScript hits a performance ceiling.

A Quick Look at Wasm's History (2017-2026)

Wasm shipped in all four major browsers in 2017 as a W3C MVP. In 2019 it became an official W3C standard. The real transformation happened in 2020 with the announcement of WASI, which let Wasm escape the browser entirely.

WasmGC shipped in all major browsers in 2024, enabling garbage-collected languages like Kotlin and Java to target Wasm without bringing their own GC. In September 2025, Wasm 3.0 was ratified. February 2026 brought WASI 0.3.0 with native async I/O using futures and streams - the last major gap between Wasm and conventional server runtimes.

The ecosystem feels like it "arrived" recently because WASI and the Component Model are what turned Wasm from a browser trick into a production server runtime.

Real-World Adoption: Companies Already Running Wasm in Production

Figma compiled its C++ rendering engine to Wasm using Emscripten. The result: 3x faster load times across all document sizes. This was a full production rewrite, not a proof of concept.

Google Sheets migrated its calculation engine to WasmGC, achieving 2x faster recalculation. Sheets with millions of cells now finish in under a second.

Shopify Functions allows merchants to write custom discount and checkout logic in Rust, compiled to Wasm, executed at the edge inside a strict 10ms time budget. No Node.js function could reliably meet that ceiling at scale.

Adobe Premiere Rush brings video editing to the browser via Wasm-compiled media pipelines. No plugin, no Electron wrapper - just a browser tab running compute-heavy codecs at near-native speed.

WASI: Taking Wasm Beyond the Browser

A plain Wasm module running in the browser has no access to the filesystem, sockets, clocks, or any OS resource. That works fine for in-browser computation but rules out server applications and CLI tools.

WASI - the WebAssembly System Interface - solves this. It is a standardized interface that gives Wasm modules portable, capability-gated access to OS resources. A Wasm binary compiled for WASI runs on any WASI-compatible runtime without modification.

As Solomon Hykes, co-founder of Docker, noted: if WASM+WASI had existed in 2008, Docker might not have needed to be invented. The portability problem that containers solve is the same one WASI addresses - with a much smaller footprint.

WASI 0.3.0 (February 2026) added native async I/O with futures and streams, making Wasm viable for real-world servers handling concurrent connections.

The Component Model: Polyglot Composition Without Glue Code

Before the Component Model, connecting a Rust module to a Python module meant manually writing type conversion glue across the memory boundary. In practice, cross-language Wasm compositions were too painful to maintain.

The Component Model introduces WIT (WebAssembly Interface Types) - a language-neutral interface definition format. A Rust library and a Python library, both compiled to Wasm components, can call each other's functions through automatically generated, type-safe bindings. No manual marshaling.

This enables genuinely polyglot applications. Your crypto library can be Rust, your data pipeline can be Python, your business logic can be TypeScript via Javy - all composing without a translation penalty. Tools like cargo-component and wit-bindgen ship today.

Edge Computing: Why Wasm Wins on Cold Start

The performance advantage of Wasm amplifies at the edge, where cold start latency is often the binding constraint.

A container starts in 50-500ms. A Node.js Lambda in 200-400ms. A Wasm module in 1-5ms. Memory per instance is roughly 1MB for Wasm vs 10MB+ for a container. At the scale of thousands of isolated tenant functions, that gap is enormous.

Cloudflare Workers, Fastly Compute@Edge, and Vercel Edge Functions all support Wasm today. AWS Lambda Wasm functions show 10-40x improvement in cold-start times compared to container equivalents.

WebAssembly vs JavaScript: A Practical Decision Framework

The choice is not ideological. It is about where JavaScript's speed ceiling becomes your bottleneck.

Use Wasm for: image and video processing, cryptographic operations, AI/ML inference in the browser, physics simulations, game engines, and serverless functions with strict latency budgets.

Use JavaScript for: DOM manipulation, event handling, JSON parsing, calling APIs, server-side rendering, and standard CRUD application logic.

In practice, 5-10% of an application's code - the hot paths - benefits from Wasm. The rest should stay in JavaScript where the ecosystem, tooling, and debugging experience are stronger.

Building with Wasm: Three Practical Starting Points

Rust to Wasm - The Production Path

Rust is the dominant choice for production Wasm. It has no garbage collector (no GC pauses inside your module), zero-overhead abstractions, and the wasm-pack toolchain that handles compilation, JS bindings, and npm packaging in one command.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup target add wasm32-unknown-unknown
cargo install wasm-pack
cargo new --lib wasm-hello && cd wasm-hello
wasm-pack build --target web

The output pkg/ directory contains the .wasm binary, a JS glue file, and TypeScript types ready for import.

AssemblyScript - For TypeScript Developers

AssemblyScript is a TypeScript-like language that compiles directly to Wasm. If your team is JavaScript-native and wants Wasm without learning a new paradigm, this is the lowest-friction entry point.

npm init
npm install --save-dev assemblyscript
npx asinit .
npm run asbuild

Performance and safety guarantees are lower than Rust, but for moving a hot path out of JavaScript quickly, AssemblyScript is a solid pragmatic choice.

Server-Side Wasm with Wasmtime

For running Wasm outside the browser with WASI, Wasmtime is the reference runtime from the Bytecode Alliance. It implements WASI Preview 2 and the Component Model.

curl https://wasmtime.dev/install.sh -sSf | bash
rustup target add wasm32-wasip2
cargo build --target wasm32-wasip2 --release
wasmtime target/wasm32-wasip2/release/my-app.wasm

The same .wasm binary you run locally in Wasmtime runs unchanged on Cloudflare Workers or AWS Lambda.

Language Support in 2026

Rust and C/C++ are production-ready. AssemblyScript and Go (via TinyGo) are stable. C# via Blazor is production-ready and used by 43% of .NET developers. Kotlin/Wasm is stable with WasmGC. Python (via Pyodide) is emerging for browser-based data science. JavaScript/TypeScript via Javy is experimental but useful for embedding a tiny JS runtime inside Wasm.

Limitations Developers Should Know About

Most Wasm guides skip over these. Here is an honest look at the gaps.

No native multithreading in WASI. Server-side Wasm still lacks a proper parallel compute model. High-throughput servers and CPU-parallel workloads are not good Wasm candidates today.

Memory overhead at scale. Each Wasm instance has a minimum memory footprint. Running thousands of isolated modules can use more total memory than shared-runtime alternatives.

DOM access requires a JS bridge. In the browser, Wasm cannot touch the DOM directly. All DOM operations go through JavaScript. If DOM manipulation is your bottleneck, Wasm will not help.

Debugging experience lags. Production builds strip debug info. Source maps exist but lag behind native tooling. The practical workaround is running logic through cargo test in a native binary for unit testing.

Large module startup cost. Very large Wasm binaries - ML models, for example - have real instantiation overhead. Streaming compilation and wasm-opt mitigate this, but it is not zero.

Conclusion

WebAssembly in 2026 is a mature production runtime, not a browser experiment. Wasm 3.0 is a W3C standard. WASI Preview 2 is stable. Figma, Google, Shopify, and Adobe run it at scale.

Most developers do not need to rewrite anything today. The practical approach: identify the 5-10% of your codebase that is genuinely performance-constrained, and evaluate whether Wasm closes that gap. Start with wasm-pack and the Rust quickstart - the round-trip from source to a callable JavaScript function is shorter than you expect.

References

Original article: https://devtoollab.com/blog/webassembly-guide
Wasmtime runtime: https://wasmtime.dev/
wasm-pack documentation: https://rustwasm.github.io/docs/wasm-pack/
AssemblyScript: https://www.assemblyscript.org/
Bytecode Alliance (WASI/Component Model): https://bytecodealliance.org/
Cloudflare Workers Wasm support: https://workers.cloudflare.com/
Shopify Functions: https://shopify.dev/docs/apps/functions

JSONata Explained: Query and Transform JSON Without the Boilerplate

Moksh Gupta — Sat, 13 Jun 2026 18:26:41 +0000

Working with complex JSON payloads can quickly become a nightmare. You end up chaining .map(), .filter(), and .reduce() calls across multiple lines just to pull out a few nested values. Add optional chaining to avoid crashes and the code becomes nearly unreadable.

There is a cleaner way - JSONata. It is a compact, purpose-built query and transformation language for JSON data. Think of it as XPath for XML, but designed from the ground up to work with JSON objects and arrays.

What is JSONata?

JSONata is an open-source project originally created by Andrew Coleman at IBM. It gives developers a declarative syntax to extract and reshape JSON data without writing procedural JavaScript loops. Where vanilla JS might take 15 lines, a JSONata expression often takes one.

It is available as an npm package and integrates naturally into Node.js and TypeScript projects.

Simple Path Navigation

The foundation of JSONata is its dot-notation path traversal. Given a nested JSON object, you simply trace the path to the value you need:

customer.address.city

This returns the city value without any need for null checks or defensive coding. JSONata handles missing properties gracefully by returning undefined rather than throwing errors.

Automatic Array Mapping

When JSONata encounters an array during path traversal, it automatically maps across all items. There is no need to write an explicit .map() call:

customer.orders.product

This returns an array of all product names from every order in one clean expression.

Inline Filtering

You can filter arrays directly using bracket notation with a condition:

customer.orders[price > 1000].product

This returns only the products from orders where the price exceeds 1000. No .filter() callback required.

Built-in Aggregation Functions

JSONata ships with a solid set of built-in functions for math, strings, and arrays. Aggregating a set of values is straightforward:

$sum(customer.orders.price)

Other useful functions include $count(), $average(), $string(), $round(), and many more.

Restructuring JSON Output

One of JSONata's most powerful features is the ability to declare an entirely new output shape. You define the target structure and map source values into it:

{
  "customerName": customer.name,
  "totalSpent": $sum(customer.orders.price),
  "orderCount": $count(customer.orders)
}

This is especially useful in Backend-For-Frontend (BFF) patterns where you need to slim down a bloated API response before it reaches the client.

JSONata vs Vanilla JavaScript

JavaScript can do everything JSONata does - but at a cost. JSONata wins on:

Conciseness: Data reshaping expressions shrink dramatically.
Declarative style: You describe the output shape, not the iteration steps.
Safety: JSONata expressions are sandboxed, making them safer to expose to non-engineers for custom data extraction.

JSONata vs jq

If you live in the terminal, jq is a great tool. But for Node.js and React applications where you need embedded transformation logic, JSONata offers syntax that feels more natural to JavaScript developers and integrates directly into application code.

Getting Started in Node.js

Installing JSONata takes one command:

npm install jsonata

Here is a basic usage example:

const jsonata = require('jsonata');

const data = {
  customer: {
    name: "John Doe",
    orders: [
      { id: 1, item: "Laptop", price: 1200 },
      { id: 2, item: "Phone", price: 800 }
    ]
  }
};

const expression = jsonata('customer.orders[price > 1000]');
const result = await expression.evaluate(data);
console.log(result);

Real-World Use Case - API Response Formatting

A common pattern is using JSONata in a BFF layer to strip unnecessary fields from a third-party API response before forwarding it to the frontend. Instead of writing custom mapping functions for every endpoint, you define a single JSONata expression that reshapes the response declaratively.

Real-World Use Case - Sales Data Aggregation

JSONata handles grouped aggregations well. You can compute totals and averages across nested transaction arrays using $sum() and $average() in a single expression, without writing complex reduce() logic.

Real-World Use Case - Dynamic Config Parsing

JSONata can dynamically resolve environment-specific values from a shared configuration object. By injecting the environment name into the expression, you get clean, environment-specific output without branching logic in your application code.

Advanced Feature - Custom Functions

JSONata lets you define lambda functions directly inside your expression payload. This is useful for tasks like formatting currency values or applying custom business logic to each item in an array, all within a single self-contained expression.

Advanced Feature - Conditional Fallbacks

Ternary expressions in JSONata make it easy to handle missing or unexpected values from external APIs:

customer.address.zipCode ? customer.address.zipCode : "No ZIP code provided"

This keeps your transformation logic clean and avoids runtime failures.

Advanced Feature - Recursive Processing

JSONata supports recursive self-calling functions, which makes it possible to traverse and process tree structures like file directory hierarchies of arbitrary depth - without any imperative loop logic.

Conclusion

If your work involves API integration, data pipelines, or payload manipulation, JSONata is a tool worth adding to your toolkit. It replaces verbose imperative JavaScript with concise, readable, declarative expressions that are easier to maintain and reason about.

Start with simple path expressions and work up to custom functions and recursive transforms - the learning curve is gentle and the payoff is significant.

References

Original article: What Is JSONata? Learn How to Query JSON Like a Pro - DevToolLab
JSONata official site: https://jsonata.org
JSONata npm package: https://www.npmjs.com/package/jsonata
JSONata documentation: https://docs.jsonata.org

Top Ngrok Alternatives for Developers in 2026 - Free, Open-Source, and Self-Hosted

Moksh Gupta — Sat, 13 Jun 2026 17:42:46 +0000

If you're building APIs, testing webhooks, or working with third-party integrations, you've probably needed to expose a local server to the internet. Ngrok has long been the go-to tool for this, but rising costs, session limits, and the demand for self-hosted control have pushed many developers to seek out alternatives. This guide covers the most reliable Ngrok replacements available in 2026 - from managed services with free tiers to fully self-hosted open-source tools.

What to Look for in a Tunneling Tool

Not all tunneling tools are created equal. Before picking one, consider these key criteria: connection reliability, latency and throughput, support for protocols beyond HTTP (TCP, UDP, WebSocket), custom domain support, request inspection capabilities, and whether a self-hosted or open-source option is available. Your specific workflow and infrastructure constraints should drive the final decision.

Quick Comparison: Ngrok Alternatives at a Glance

Here is a summary of how the main alternatives stack up across important features:

Pinggy - No install, SSH-based, free tier, custom domains, TCP + WebSocket support
Cloudflare Tunnel - Enterprise-grade security, no bandwidth limits on free plan, Cloudflare ecosystem integration
inlets - Open core, Kubernetes-friendly, self-hostable, automatic SSL
Pagekite - Mature and simple, flexible pricing, self-hosted option
Tunnelto - Team-focused, real-time inspector, API integration
Serveo - Zero install via SSH, quick and free, limited features
Localtunnel - Fully open-source, easy CLI, WebSocket support
frp - Feature-rich, multi-protocol, load balancing, dashboard
Expose - Open-source, Laravel-friendly, real-time dashboard
Telebit - AGPL-licensed, auto HTTPS, SSH tunnels, self-hostable
Bore - Rust-based, minimal, very fast, self-hosted
sish - SSH authentication, HTTP/TCP tunneling, custom domains

Commercial Services with Free Tiers

These managed tools handle infrastructure for you and offer free plans suitable for most development use cases.

1. Pinggy

Pinggy is a strong Ngrok competitor that works entirely over SSH - no client installation needed. It offers a generous free tier with HTTPS, TCP, and WebSocket tunneling, plus an in-browser request inspector with filtering. Custom domains and end-to-end encryption round out a well-designed package. Ideal for developers who want a zero-setup workflow with solid debugging tools.

2. Cloudflare Tunnel

Formerly known as Argo Tunnel, Cloudflare Tunnel integrates deeply with the Cloudflare platform - giving you DDoS protection, automatic SSL, built-in analytics, and a zero-trust security model. The free plan has no bandwidth cap, making it a compelling option for developers already using Cloudflare for DNS or CDN. Best suited for production-grade or security-sensitive environments.

3. inlets

inlets offers an open-source core under the MIT license alongside a commercial Pro version for advanced use cases. It supports HTTP and TCP tunneling, integrates with Kubernetes, and handles automatic SSL via Let's Encrypt. It works well even behind restrictive firewalls and can be self-hosted. A natural fit for cloud-native teams.

4. Pagekite

Pagekite is one of the older tunneling solutions, and its maturity shows. Configuration is straightforward, HTTPS is supported, and it follows an open-core model that allows self-hosting. The pay-what-you-want pricing is a nice touch for indie developers and small teams who need a predictable, no-surprises tool.

5. Tunnelto

Tunnelto targets developer teams with features like real-time traffic inspection, custom subdomains, TCP tunneling, and built-in API integration. Collaboration features make it more useful in multi-developer environments where multiple people need visibility into request flows.

6. Serveo

Serveo has a narrow but useful appeal: it requires absolutely no client installation and operates purely over SSH. It supports HTTP and TCP forwarding with custom subdomain options. Limitations apply on the free tier, but for a quick one-off tunnel session, it is hard to beat for simplicity.

Open-Source and Self-Hosted Options

If you need full control over your infrastructure, these fully open-source tools are worth considering.

7. Localtunnel

Localtunnel is a lightweight, MIT-licensed option with a simple CLI and WebSocket support. It can be self-hosted and is quick to set up:

npm install -g localtunnel
lt --port 3000

A solid pick for developers who want a no-frills, open-source tunneling solution.

8. frp - Fast Reverse Proxy

frp (Apache-2.0) is a powerful self-hosted proxy that supports TCP, UDP, HTTP, HTTPS, and WebSocket. It includes load balancing, custom domains, encryption, a monitoring dashboard, and a plugin system. If you need advanced networking control, frp is likely the most feature-complete open-source option on this list.

9. Expose

Expose is a PHP/Laravel-friendly open-source tool (MIT) that also works with any web framework. It supports custom subdomains, request logging and replay, and a real-time dashboard. Self-hosting is Docker-based and well-documented. A good fit for PHP developers who want observability built in.

10. Telebit

Telebit (AGPL-3.0) is a security-oriented tunneling tool with automatic HTTPS via Let's Encrypt, SSH tunnel support, and custom domain handling. It has a clean CLI and can be self-hosted. Well-suited for developers who prioritize encrypted tunnels and straightforward configuration.

11. Bore

Bore is a minimal, Rust-powered tunneling tool designed for speed and simplicity. Setting up a server and connecting a client takes just two commands:

cargo install bore-cli
bore server
# client side:
bore local 8000 --to your-bore-server:7835

Its MIT license and low resource footprint make it ideal for self-hosted setups where performance matters.

12. sish

sish is an SSH-based tunneling server that supports HTTP, HTTPS, and TCP with custom domain routing and WebSocket traffic. Authentication is handled entirely over SSH, keeping the setup simple and secure. A clean choice for developers comfortable in the terminal who want self-hosted tunneling.

How to Pick the Right Tool for Your Setup

Choosing the right Ngrok alternative depends on a few practical questions:

Do you want managed hosting or full self-hosted control?
What protocols do you need beyond HTTP?
How much traffic will you be routing?
Do you have existing infrastructure (Cloudflare, Kubernetes, Docker) to integrate with?
What is your budget - free tier, subscription, or one-time self-host cost?
How important is request inspection and debugging?

Answering these will quickly narrow the list to two or three strong candidates.

Conclusion

In 2026, developers have a wider choice of tunneling tools than ever. For a managed, zero-config experience, Pinggy and Cloudflare Tunnel lead the pack. For open-source flexibility, frp and sish are the most capable self-hosted options. And for lightweight use cases where you want something minimal and fast, Bore and Localtunnel are reliable standbys.

The right tool ultimately depends on your project requirements, infrastructure preferences, and how much management overhead you are willing to accept.

References

Original article: https://devtoollab.com/blog/best-ngrok-alternatives
Ngrok official site: https://ngrok.com/
Pinggy: https://pinggy.io/
Cloudflare Tunnel: https://www.cloudflare.com/products/tunnel/
inlets: https://inlets.dev/
Pagekite: https://pagekite.net/
Localtunnel on GitHub: https://github.com/localtunnel/localtunnel
frp on GitHub: https://github.com/fatedier/frp
Expose on GitHub: https://github.com/beyondcode/expose
Bore on GitHub: https://github.com/ekzhang/bore
sish on GitHub: https://github.com/antoniomika/sish

Understanding XML Structure: A Practical Guide for Developers

Moksh Gupta — Fri, 12 Jun 2026 18:49:14 +0000

JSON and GraphQL dominate modern web development, but XML (eXtensible Markup Language) is far from obsolete. Enterprise integrations, legacy systems, healthcare standards, and financial protocols still rely heavily on XML. If you work across diverse stacks, understanding XML is a skill that pays dividends.

This guide covers the core syntax, validation techniques, parsing approaches, and best practices - with code you can put to work right away.

Why XML Still Matters in 2026

XML has been around since 1996 and continues to thrive in specific domains. It handles deeply nested hierarchical data well, supports robust native schema validation, and manages mixed document-oriented content better than most alternatives. If you're dealing with SOAP APIs, Android layouts, SVG, DOCX/XLSX files, HL7 healthcare records, or FIX financial protocols, you're already in XML territory.

The Core Building Blocks of an XML Document

At its core, XML is a tree of nodes serialized as text. Every well-formed document starts with a declaration that tells the parser the version and character encoding - UTF-8 is the standard choice. From there, the document is composed of nested elements, attributes, and optionally text content.

Elements - The Tree Nodes

Elements are the primary structural unit in XML. They wrap your data in opening and closing tags. XML is case-sensitive, so a tag and a tag are treated as two completely different elements. Every opened element must have a corresponding closing tag to keep the document well-formed.

Attributes - Metadata on Elements

Attributes sit inside an opening tag and carry metadata about the element rather than the primary data itself. A good rule of thumb: use attributes for identifiers, types, or units (like currency), and use child elements for the actual payload data. This separation keeps your parsers predictable and your document structure clean.

Self-Closing Elements

When an element has no content or child nodes, you can collapse the open and close tag into a single self-closing form. This reduces verbosity without sacrificing clarity.

CDATA Sections - Handling Special Characters

When you need to embed raw content - such as HTML snippets, JSON blobs, or code fragments - inside an XML node, CDATA sections let you do it safely. Everything between the CDATA delimiters is treated as raw text by the parser, so characters like < and & don't need escaping and won't break the document.

Schema Validation - A Real Advantage Over JSON

One of XML's strongest selling points is first-class schema validation without external libraries. DTDs (Document Type Definitions) are the older approach, letting you declare which elements and attributes are valid in a document. XSD (XML Schema Definition) is the modern standard - more verbose, but it supports proper data types including strings, dates, integers, and regex patterns. Enterprise systems use XSDs to validate incoming payloads before they ever reach application logic.

Namespaces - Avoiding Naming Conflicts

When combining XML outputs from multiple sources or APIs, element name collisions become a real problem. Namespaces solve this by associating elements with a unique URI prefix. Each element belongs to a specific namespace context, so two different info elements from two different schemas can coexist in the same document without conflict.

Parsing XML in Practice

Parsing XML as raw strings is a recipe for bugs. Use proper parser APIs instead. In browser and Node.js environments, the DOMParser API converts XML text into a queryable document object. You can then use querySelector-style methods to locate specific elements and extract their content or attributes. For more complex querying, XPath is the right tool - it lets you write powerful expressions to target elements by structure, attribute values, or content, similar to how CSS selectors and SQL work together.

Best Practices for XML Development

Keep element names descriptive and consistent - pick camelCase or kebab-case and stick to it throughout the document. Structure nesting to mirror the real-world relationships in your data. On the security side, always disable external entity processing to block XXE (XML External Entity) injection attacks. Validate all input against a strict schema, set resource limits on parser memory consumption, and sanitize any user-supplied data before it gets written into XML output.

XML vs. JSON - When to Choose What

JSON wins for web API responses and lightweight configuration. XML wins when you need native schema validation, namespace support, mixed content (text and markup together), or when integrating with enterprise systems and industry-standard protocols. If the system on the other end speaks XML, XML is the right choice - no abstraction layer needed.

Real-World Domains That Rely on XML

XML is the foundation of SOAP-based enterprise integrations, healthcare data exchange via HL7 and FHIR, securities trading with the FIX protocol, and modern office file formats like DOCX and XLSX. Android developers work with XML daily for layout files and manifests. SVG graphics are XML under the hood.

Conclusion

XML's longevity comes from solving real problems that JSON and newer formats don't fully address - strict validation, namespace management, and mixed content support. Understanding its structure and tooling makes you a more effective developer when working across enterprise, healthcare, or any legacy-adjacent domain.

References

Source article: XML Structure Explained - DevToolLab
XML to JSON Converter - DevToolLab
OWASP XML Security Cheat Sheet
JSON.org
GraphQL

Top 12 Playit.gg Alternatives for Low-Latency Game Server Hosting in 2026

Moksh Gupta — Fri, 12 Jun 2026 18:21:18 +0000

Multiplayer gaming has come a long way, and so have the tools that keep your servers accessible. Playit.gg has served gamers well as a no-port-forwarding proxy solution, but it is not the only option. Whether you are running a Minecraft world for your friend group, a Terraria server, or any other multiplayer environment, there are smarter and sometimes faster solutions available in 2026.

This guide covers 12 tested alternatives across four categories: tunneling services, dedicated game hosting, virtual LAN solutions, and remote play platforms.

Quick Comparison Table

Solution	Type	Free Tier	Custom Domains	Latency
Pinggy	Tunneling	Yes	Paid	Low
Ngrok	Tunneling	Yes	Paid	Medium
Portmap.io	Tunneling	Yes	Paid	Low
PageKite	Tunneling	Yes	Yes	Low
LocalXpose	Tunneling	Yes	Paid	Low
Aternos	Hosting	Yes	No	Low
Tailscale	VPN	Yes	N/A	Very Low
ZeroTier	VPN	Yes	N/A	Very Low
SoftEther VPN	VPN	Yes	N/A	Low
Radmin VPN	VPN	Yes	N/A	Very Low
Parsec	Streaming	Yes	N/A	Low
Shadow	Cloud PC	No	N/A	Low

Why Consider Moving Away from Playit.gg?

Playit.gg works as a global proxy that bridges your local server to the internet without any router configuration. That said, developers and gamers look for alternatives when they need lower baseline latency, custom domains, better UDP protocol support, or higher uptime guarantees.

Section 1 - Tunneling and Port-Forwarding Tools

These solutions punch a secure tunnel from your local machine to the internet, giving remote players a public address to connect to.

Pinggy

Pinggy is a minimal-footprint tunneling tool that runs comfortably on low-powered hardware like a Raspberry Pi. There is no daemon to maintain - just a single terminal command. It supports custom domains on paid plans and keeps CPU overhead extremely low.

Best For: Hosting game servers on constrained or embedded hardware.

Ngrok

Ngrok remains the gold standard for quick tunnel setup. A single command exposes your local server, and a built-in dashboard lets you inspect all incoming traffic in real time. The free tier uses randomly generated URLs, but paid plans unlock persistent custom subdomains.

Best For: Temporary sessions, developer testing, and one-off gaming events.

Portmap.io

Portmap.io is built on OpenVPN infrastructure and lets you route traffic through geographically distributed relay servers. Crucially, it handles both TCP and UDP traffic - a hard requirement for most fast-paced shooters and survival games.

Best For: Competitive gaming where low ping and protocol flexibility matter.

PageKite

PageKite is an open-source tunneling tool that provides persistent named tunnels. Your server address stays the same between restarts. It also supports failover across multiple backends, which keeps sessions alive if your primary connection drops.

Best For: Servers that need a stable, permanent address over long periods.

LocalXpose

LocalXpose differentiates itself with end-to-end encryption and DDoS protection built directly into the free tier. Free users can claim custom subdomains rather than dealing with randomly assigned URLs each session.

Best For: Security-conscious communities that want persistent subdomains without upgrading to a paid plan.

Section 2 - Dedicated Game Server Hosting

Instead of tunneling through your local machine, these services host your game server on dedicated infrastructure.

Aternos

Aternos provides completely free, ad-supported Minecraft servers with one-click modpack and plugin installation. The trade-off is that servers shut down automatically when all players leave, and available RAM is limited to casual use.

Best For: Small friend groups who play Minecraft occasionally and do not want to maintain a machine.

Paid Game Server Hosts

Services like Apex Hosting and Nitrado offer 24/7 uptime, DDoS mitigation, and substantial resource allocations starting around $5 to $15 per month. For growing gaming communities, eliminating home hardware limitations is well worth the subscription cost.

Best For: Established communities that need reliable, always-on servers.

Section 3 - VPN and Virtual LAN Solutions

These tools simulate a local area network across the internet, so multiplayer works exactly as it would on a home LAN.

Tailscale

Tailscale uses the WireGuard protocol to build a peer-to-peer mesh network between all connected devices. Traffic goes directly between players rather than through a central server, producing the lowest possible latency. Setup requires only a Google or Microsoft login.

Best For: Small friend groups who want enterprise-grade security with near-LAN latency.

ZeroTier

ZeroTier acts like a global virtual switch. It handles complex NAT traversal automatically and supports up to 100 devices on the free tier, making it well suited for large clans playing older titles that expect a LAN connection.

Best For: Large groups and LAN-style games that do not natively support internet play.

SoftEther VPN

SoftEther is a full-featured, open-source VPN platform that supports nearly every major protocol including OpenVPN and L2TP. It is capable of tunneling through restrictive firewalls found in corporate or university environments. The configuration process is complex and requires meaningful technical knowledge.

Best For: Advanced users who need to bypass strict network-level restrictions.

Radmin VPN

Radmin VPN is a free, Windows-only virtual LAN tool with minimal background overhead and no device limits on the free plan. It is the practical modern replacement for LogMeIn Hamachi for classic PC LAN gaming.

Best For: Large Windows-only groups playing classic or legacy LAN titles.

Section 4 - Remote Play and Game Streaming

These tools take a different approach - rather than hosting a server, they stream the game screen directly to participants.

Parsec

Parsec lets one person run the game locally while friends connect to stream the display and send controller inputs over the internet. It supports up to 60 FPS at 4K resolution with very low input latency, making it viable for couch co-op titles that lack native online multiplayer.

Best For: Local co-op games played remotely.

Shadow

Shadow provides a full high-end Windows PC in the cloud, connected via a 1 Gbps enterprise uplink. You run your game server and client from their infrastructure, completely bypassing local hardware limits and ISP throttling.

Best For: Gamers with underpowered machines or heavily restricted home internet connections.

Conclusion

In 2026, the ecosystem of game server connectivity tools is broader and more capable than ever. For quick throwaway sessions, Ngrok or Pinggy are the fastest paths to getting friends connected. For permanent low-latency setups, Tailscale and ZeroTier are the engineering-first choices. If you want a persistent world running around the clock, a paid dedicated host is the most reliable path.

Most of these tools offer usable free tiers, so the best approach is to test a couple and benchmark the actual ping your players experience.

References

How to Convert JSON to XML Without Breaking Your Integration

Moksh Gupta — Thu, 11 Jun 2026 18:45:51 +0000

Working with modern APIs means living in JSON. But the moment your project touches a legacy enterprise system - a bank, a government service, or a SOAP endpoint that hasn't changed in a decade - you're suddenly dealing with XML. The challenge isn't just swapping syntax; it's understanding where the two formats are structurally incompatible, and what breaks silently when you ignore that.

Why JSON and XML Don't Simply Map to Each Other

JSON is compact and type-aware - it distinguishes between numbers, booleans, strings, and arrays natively. XML is verbose, treats all content as text, and has no concept of arrays. It only has repeated sibling elements. This gap is where most conversion bugs are born. A JSON array with just one item can silently become a plain object if your converter doesn't handle the edge case explicitly.

The Three Biggest Conversion Pitfalls

First is array ambiguity - XML has no array type, so a JSON array becomes repeated sibling elements. A single-item array is indistinguishable from a plain object unless your converter explicitly preserves the list context. Second is type erasure - XML flattens numbers, booleans, and strings into plain text, destroying the type information that many downstream systems depend on. Third is the single root element rule - JSON can have multiple top-level keys, but every valid XML document must have exactly one root element wrapping everything else.

Handling Arrays the Right Way

Always nest array items inside a named parent element. A JSON users array should produce a parent element containing individual child elements. This structure makes the list unambiguous to any downstream XML parser and prevents silent data loss during round-trips.

Escaping Special Characters

Characters that are perfectly valid inside a JSON string will break an XML parser immediately. Your conversion logic must escape these four: less-than becomes <, greater-than becomes >, ampersand becomes &, and double-quote becomes ". Skipping even one of these is one of the most common causes of cryptic integration failures.

Sanitizing JSON Keys for XML Element Names

JSON allows keys that are illegal as XML element names - ones that start with a digit, contain spaces, or use special characters. Your conversion logic must sanitize keys before they become tags. A standard strategy is prefixing digit-starting names with an underscore, so "1st" becomes "_1st", and stripping or replacing any other disallowed characters.

Real-World Example - SOAP API Integration

When your application needs to talk to a SOAP service, your JSON payload must be wrapped inside an XML envelope shaped to match the service WSDL schema. Map each JSON field to the correct XML element name, and use the repeating-child pattern for any arrays inside. SOAP services validate the envelope structure strictly before processing any data, so getting this structure right is not optional.

Recommended Libraries by Language

Avoid building an XML serializer from scratch. In Node.js, xml2js provides a Builder API that manages encoding and root elements cleanly. In Python, dicttoxml converts a dictionary directly to XML with a configurable root tag. For Java enterprise applications, Jackson XmlMapper is the standard choice. For quick browser-based conversions during development, DevToolLab JSON to XML Converter (https://devtoollab.com/tools/json-to-xml) is fully client-side - no data is ever sent to a server.

Conclusion

JSON to XML conversion is an unavoidable reality for any team working with enterprise integrations. The key rules are straightforward: always wrap output in a single root element, handle arrays explicitly using named parent tags, escape reserved XML characters, and sanitize JSON keys before they become element names. Apply these consistently and your integration will hold up in production.

References

Original article: JSON to XML Conversion Complete Developer Guide 2026 - https://devtoollab.com/blog/json-to-xml-conversion-guide
XML to JSON Conversion Best Practices - https://devtoollab.com/blog/xml-to-json-conversion-best-practices
Essential Developer Tools 2026 - https://devtoollab.com/blog/essential-developer-tools
xml2js on npm - https://www.npmjs.com/package/xml2js
Jackson XmlMapper - https://github.com/FasterXML/jackson-dataformat-xml

XML to JSON Conversion - Avoiding the Pitfalls That Actually Bite You

Moksh Gupta — Thu, 11 Jun 2026 17:37:41 +0000

Converting XML to JSON looks deceptively simple - until your pipeline silently drops attribute data, crashes on single-item responses, or passes "true" as a string into a boolean check. The structural gap between XML and JSON is wider than most developers expect. This guide covers the real conversion challenges that matter in production code.

Why XML and JSON Don't Map Cleanly

XML carries concepts that JSON simply doesn't support natively - attributes, mixed-content nodes, namespaces, and implicit ordering. A direct parse without any configuration will technically produce output, but that output will be inconsistent and fragile. Understanding where the model breaks down is the first step toward writing a conversion that actually holds up.

XML Concept	JSON Equivalent	The Problem
Attributes (id="123")	Properties	No native attribute concept
Single vs. multiple child elements	Value vs. Array	Single item becomes a string, multiple become an array
All text is a string	Typed values	"true" and "42" need real type conversion
Namespaces (soap:Body)	No equivalent	Naming collisions without careful handling

Handling XML Attributes Without Losing Data

XML attributes - things like id, role, or currency - encode real business data, yet most XML parsers drop them by default. The standard convention is to prefix attribute keys with @ so they land as regular JSON properties alongside text content.

In fast-xml-parser for Node.js, set ignoreAttributes: false and attributeNamePrefix: "@". The default behavior silently discards attribute data, which is a common source of hard-to-debug data loss in API migrations.

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: "@",
  textNodeName: "#text",
  parseAttributeValue: true
});

const json = parser.parse(xmlString);

The Array Problem - The Bug That Catches Everyone

XML doesn't distinguish between a single child element and a collection of child elements. This means a one-item list parses to a plain string, while a two-item list parses to an array - and your array.map() call works fine in testing and fails in production when a single-item edge case arrives.

The fix is to declare known collection tags explicitly using the isArray callback in fast-xml-parser, or to write a post-processing normalization step that enforces array types on known plural keys like products, items, users, and orders. Pick one approach and apply it consistently across your pipeline.

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: "@",
  isArray: (tagName) => {
    const alwaysArrayTags = ['product', 'item', 'user', 'order', 'role'];
    return alwaysArrayTags.includes(tagName);
  }
});

Type Inference - Don't Let "42" Stay a String

XML stores everything as text. Without explicit type parsing, boolean flags come through as "true" strings, numeric IDs come through as "123" strings, and your downstream code has to compensate - or silently misbehaves. Most parsers offer a parseTagValue: true option that handles the common cases automatically.

For custom logic, a simple helper that checks for "true", "false", numeric strings, and empty values covers most real-world needs. Pair it with trimValues: true to strip whitespace from element text.

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: "@",
  parseAttributeValue: true,
  parseTagValue: true,
  trimValues: true
});

Real-World Case - Stripping a SOAP Envelope

A common XML-to-JSON task is migrating from a SOAP-based service to a REST JSON API. The SOAP response wraps the actual payload in soap:Envelope and soap:Body containers that you need to navigate past before extracting your data.

The pattern is straightforward: parse the full XML with attribute support enabled, drill into the envelope wrapper using optional chaining, and remap the inner payload to a clean flat JSON structure. Always declare collection tags like Role as arrays during the parse step - not as a post-processing fix.

function soapToRest(soapXml) {
  const parser = new XMLParser({
    ignoreAttributes: false,
    attributeNamePrefix: "@",
    parseAttributeValue: true,
    parseTagValue: true,
    isArray: (name) => name === 'Role'
  });
  const parsed = parser.parse(soapXml);
  const rawUser = parsed?.['soap:Envelope']?.['soap:Body']?.User;
  if (!rawUser) throw new Error('Could not locate User in SOAP body');
  return {
    user: {
      id: rawUser['@id'],
      name: rawUser.Name,
      email: rawUser.Email,
      roles: rawUser.Roles.Role.map(r => r.toLowerCase())
    }
  };
}

Real-World Case - Migrating XML Config to JSON Config

When migrating apps from XML-based configuration (Spring, Maven, legacy enterprise apps) to JSON config, type inference becomes critical. A port value of 5432 stored as XML text must become a JSON number, not the string "5432", or your app will reject it at startup.

Enable parseTagValue: true during parsing and validate the output schema before replacing your config files in production. Type mismatches in config migrations are easy to introduce and annoying to debug.

Libraries and Tools

For Node.js, fast-xml-parser gives you fine-grained control over attribute handling, array normalization, and type inference. For Python, xmltodict paired with json.dumps() handles most straightforward cases.

For quick one-off conversions without writing code, the DevToolLab XML to JSON converter processes files locally in the browser - no data is sent to a server.