DEV Community: Saquib Shahid

NexusGraph — Transform Any Text into a Stunning AI Knowledge Graph (Gemma 4 + D3.js)

Saquib Shahid — Sun, 10 May 2026 11:12:50 +0000

What I Built

NexusGraph is an AI-powered knowledge graph explorer that transforms any text into a stunning, interactive force-directed graph visualization.

Paste an article, research paper, meeting notes, or any content — and watch as Gemma 4 extracts entities, discovers relationships, and builds a beautiful animated knowledge graph in real-time.

✨ Key Features

🧠 AI-Powered Entity Extraction — Gemma 4 identifies people, organizations, concepts, technologies, events, and places from any text
🔗 Relationship Discovery — Automatically maps how entities connect with descriptive relationship labels
🎬 Real-Time Streaming — Nodes and edges appear one-by-one via Server-Sent Events, creating a mesmerizing build animation
🖱️ Interactive Graph — Click, drag, zoom, and pan. Hover over nodes to highlight connections. Click any node to see its details and relationships
🔍 Explore Deeper — Select any node and ask Gemma 4 to expand it with additional sub-entities and connections
💬 Ask Gemma 4 — Ask natural language questions about the graph and get contextual AI-powered answers
📊 Category Visualization — Nodes are color-coded by type (person, concept, technology, organization, etc.) with glowing effects
📥 Export — Download your knowledge graph as a PNG image
🌍 Multilingual — Works with text in 35+ languages thanks to Gemma 4's multilingual training

The Stack

Backend: Node.js + Express
AI: Gemma 4 31B Dense via OpenRouter
Visualization: D3.js force-directed graph
Streaming: Server-Sent Events (SSE)
Frontend: Vanilla HTML/CSS/JS — zero frameworks, zero bloat

Demo

🔗 Live Demo → https://nexusgraph-production.up.railway.app

Try clicking one of the built-in examples ("AI & Machine Learning", "History of the Internet", or "The Solar System") to see it in action instantly!

How It Looks

The app analyzes the "AI & Machine Learning" example and extracts 21 entities and 22 relationships, building this interactive graph:

Code

saquiblancework / NexusGraph

NexusGraph AI Explorer

Transform any text into an interactive AI-powered knowledge graph using Gemma 4.

NexusGraph is an innovative tool that leverages the power of Google's Gemma 4 model to analyze unstructured text and automatically generate interactive, visual knowledge graphs.

Built for the DEV.to Gemma 4 Challenge, this application extracts key entities and relationships from any given text, displaying them in a dynamic, explorable visualization.

✨ Features

Text-to-Graph Analysis: Paste any article, document, or essay, and Gemma 4 will extract meaningful entities and their relationships.
Interactive Visualization: Explore the generated knowledge graph dynamically.
Deep Exploration: Click on any node to "Explore Deeper." The app prompts Gemma 4 to expand the graph with more details about that specific entity.
Ask Questions: Ask questions about the analyzed text, and Gemma 4 will answer using the context of both the original text and the generated knowledge graph structure.
SSE…

View on GitHub

How I Used Gemma 4

Why Gemma 4 31B Dense?

I chose the Gemma 4 31B Dense model because knowledge graph extraction requires deep reasoning that smaller models can't match:

Complex entity extraction — Identifying that "Dartmouth Conference" is an event, "Geoffrey Hinton" is a person, and "Transformer Architecture" is a technology requires nuanced understanding
Relationship reasoning — Generating specific relationship labels like "pioneered" or "defeated" (not generic "related to") demands strong language comprehension
Structured JSON output — Reliably producing valid JSON with nested objects and consistent IDs requires instruction-following capability that the 31B model handles excellently
Long context — The 256K context window handles lengthy articles and papers without truncation

Three Intentional Integration Points

NexusGraph uses Gemma 4 in three distinct, purpose-built ways — not just a chat wrapper:

1. Analyze (/api/analyze) — The core pipeline. Gemma 4 receives carefully engineered prompts that instruct it to:

Extract 10-25 entities with categories, descriptions, and importance scores (1-10)
Map relationships with descriptive labels and strength scores
Output strict JSON schema for programmatic parsing

// Structured prompt engineering for reliable graph extraction
const ANALYZE_PROMPT = `You are an expert knowledge graph builder...
OUTPUT FORMAT — respond with ONLY this JSON:
{
  "nodes": [{"id": "snake_case_id", "label": "...", "category": "person|concept|...", "importance": 8}],
  "edges": [{"source": "node_id_1", "target": "node_id_2", "label": "relationship verb", "strength": 7}]
}
RULES:
- Extract 10-25 nodes for optimal visualization
- Every node MUST connect to at least one other node
- Use specific relationship labels — never "related to"`;

2. Explore (/api/explore) — When a user clicks "Explore Deeper" on any node, Gemma 4 generates a sub-graph with 5-10 additional entities specifically related to that concept, while being aware of existing nodes to avoid duplicates.

3. Ask (/api/ask) — Context-aware Q&A. Gemma 4 receives both the original text AND the extracted graph structure, enabling it to answer questions like "What's the connection between Geoffrey Hinton and modern LLMs?" with graph-aware reasoning.

The SSE Streaming Architecture

Instead of waiting for the full response and rendering everything at once, I stream the graph to life:

User Input → Gemma 4 (extract JSON) → Parse → SSE Stream nodes one-by-one → SSE Stream edges → Done

Each node arrives as an individual SSE event with a 120ms delay, triggering a D3.js elastic spring animation. The result is a mesmerizing "graph building itself" effect that makes the AI feel alive.

// Stream nodes one by one for animation effect
for (const node of graph.nodes) {
  await delay(120);
  sseWrite(res, { type: 'node', data: node });
}

This isn't just eye candy — it gives users real-time feedback during the 10-30 second analysis, turning wait time into an engaging experience.

What I Learned

Gemma 4's instruction-following for structured JSON is remarkably reliable — I rarely needed to retry for parse errors
The 31B Dense model strikes the perfect balance between quality and speed for this use case
Prompt engineering matters more than model size — specific examples and strict format rules dramatically improved extraction quality.

I Tested Gemma 4 and GPT-4o-mini on Indian Language Tasks — The Results Surprised Me

Saquib Shahid — Sun, 10 May 2026 08:31:40 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

I asked GPT-4o-mini to explain artificial intelligence in Bengali, as if teaching a 15-year-old student.

It sent me back the original Bengali prompt. Word for word.

That single moment — a major AI model completely failing a language spoken by 230 million people — is what this article is about.

India has 1.4 billion people, 22 officially recognised languages, and hundreds of dialects. Yet nearly every AI benchmark is English-first. When developers talk about model quality, they are almost always talking about performance on Western language tasks. So I ran a direct, practical comparison: Gemma 4 (31B via OpenRouter) vs GPT-4o-mini (via ChatGPT) — five prompts, five real Indian-language scenarios, zero cherry-picking.

Here is what actually happened.

The Setup

I used Gemma 4 31B through OpenRouter's free tier and GPT-4o-mini through the standard ChatGPT free account. Same prompts, same conditions, both tested within the same hour to avoid any model update differences. I evaluated each response on three things: script correctness (did it use the right writing system), linguistic naturalness (does this sound like how people actually speak), and cultural fit (does it understand Indian context, not just translate words).

I also want to be upfront: I am a native Hindi speaker, and I used my own judgment for Hindi/Hinglish responses. For Bengali, I evaluated based on script correctness and structural coherence — and that Bengali failure in Prompt 5 is visible to anyone, native speaker or not.

Prompt 1: Hinglish — the real test of Indian language understanding

The prompt:

Mujhe ek chhoti si poem likhni hai apne best friend ke liye jo kal foreign ja raha hai. Poem mein thoda emotion ho, thoda humor bhi. Help karo yaar, Hindi-English mix mein theek hai.

This was my first real test. Hinglish — the casual Hindi-English code-switching that dominates Indian WhatsApp conversations, college campuses, and everyday speech — is arguably the most important register for any model serving Indian users. It is not "broken Hindi." It is a distinct, expressive communication style with its own rhythm.

GPT-4o-mini's response:

Tu ja raha hai door, par yaari wahi rahegi,
Time zone alag hoga, par bakchodi daily chalegi. 😄
Kal tak jo chai pe duniya solve karte the,
Ab tu foreign jaake "bro accent" mein bolega shayad re.
...
Distance sirf maps pe hota hai mere bhai,
Best friend toh wahi rehta hai… chahe duniya ke kisi bhi side chala jaye. ❤️

Gemma 4's response:

Kal ek naya chapter shuru hoga teri life ka,
Tu ja raha hai door, apne sapno ki raah par.
Proud hoon main tera, ki tune yeh mukaam paaya,
Par dil thoda udaas hai, kyunki tu door chala gaya.
...
Fly high, stay humble, and shine like a star,
Hamesha yaad rakhna, I'm always here, no matter how far.

Verdict: Both models handled Hinglish naturally and confidently — neither switched to formal Hindi or Devanagari, and neither produced stilted translated-sounding text. The difference is tone. GPT-4o-mini leaned into banter and humour ("bakchodi daily chalegi", "bro accent" mein bolega). Gemma 4 went emotional and poetic. Both are genuinely good Hinglish.

This is a tie, but it reveals something important: both models have absorbed enough real Indian internet text to produce natural code-switching. That was not guaranteed.

Prompt 2: Formal Hindi — where the gap becomes obvious

The prompt:

Please write a professional email in Hindi to a senior colleague (addressing them as "Aap") requesting a 30-minute meeting to discuss a project update. The tone should be respectful but not overly formal — natural office Hindi.

This is a practical task that millions of Indian office workers face daily. The key test: does the model understand that "formal Hindi" means Devanagari script, proper honorifics, and a structured format — not a transliteration?

GPT-4o-mini's response:

Namaste Sir/Ma'am,
Aasha karta hoon aap theek honge.
Main project ke latest updates aur kuch important points discuss karna chahta tha. Agar aapke schedule mein possible ho, toh kya hum is week 30-minute ki ek meeting schedule kar sakte hain?
Dhanyavaad.

It wrote the entire email in Roman script. This is a significant failure. If you send a "Hindi email" written in Roman transliteration to a senior colleague in an Indian corporate environment, it does not read as professional — it reads as an informal WhatsApp message. The structure is fine. The language is fine. But the script choice undermines the entire purpose.

Gemma 4's response:

Subject: Project [Project Name] के updates के संबंध में मीटिंग के लिए अनुरोध

Dear [Colleague's Name] जी,

आशा है कि आप ठीक होंगे।

मैं आपसे Project [Project Name] की current progress के बारे में चर्चा करना चाहता/चाहती हूँ। मुझे कुछ updates साझा करने हैं और आगे के steps के लिए आपका feedback और मार्गदर्शन चाहिए।

क्या आपके पास इस हफ्ते 30 मिनट का समय होगा? आप अपनी सुविधा के अनुसार कोई भी दिन और समय बता दें, मैं उस हिसाब से calendar invite भेज दूँगा/दूँगी।

धन्यवाद

Proper Devanagari script. A subject line. The natural Hindi-English hybrid that Indian offices actually use ("current progress", "feedback" embedded in Hindi sentences). The gender-aware "दूँगा/दूँगी" without being prompted. This is what a real professional Hindi email looks like.

Verdict: Gemma 4 wins clearly. It understood that "formal Hindi" is a script and register choice, not just a tone choice.

Prompt 3: News Translation — and an unexpected insight

The prompt:

Translate the following paragraph into Hindi. The translation should sound natural to a native Hindi speaker, not like a word-for-word translation: "The Supreme Court today dismissed the petition challenging the new data protection law, stating that the government had followed due process. The ruling is expected to impact millions of internet users across the country."

Both models produced accurate, readable translations. But Gemma 4 did something GPT-4o-mini did not: it explained its linguistic choices.

GPT-4o-mini:

आज सुप्रीम कोर्ट ने नए डेटा प्रोटेक्शन कानून को चुनौती देने वाली याचिका खारिज कर दी। कोर्ट ने कहा कि सरकार ने इस कानून को लागू करने में सभी जरूरी प्रक्रियाओं का पालन किया है। माना जा रहा है कि इस फैसले का असर देशभर के करोड़ों इंटरनेट उपयोगकर्ताओं पर पड़ेगा।

Clean. Accurate. Natural.

Gemma 4:

सुप्रीम कोर्ट ने आज नए डेटा प्रोटेक्शन कानून को चुनौती देने वाली याचिका को यह कहते हुए खारिज कर दिया कि सरकार ने निर्धारित कानूनी प्रक्रिया का पालन किया है। इस फैसले का असर देश भर के करोड़ों इंटरनेट यूज़र्स पर पड़ने की संभावना है।

Then it added something remarkable — a breakdown of why specific word choices were made:

"खारिज कर दिया" — standard legal term for "dismissed" in Hindi journalism
"निर्धारित कानूनी प्रक्रिया" — captures "due process" professionally rather than literally
"करोड़ों" — noting that "millions" in English maps to "crores" in Indian cultural reference, not "लाख"

That last observation is genuinely sharp. A direct translation of "millions" to "दस लाख" would be technically correct and feel completely wrong to a native reader. Gemma 4 caught that without being asked.

Verdict: Gemma 4 wins — same translation quality, but with deeper linguistic self-awareness.

Prompt 4: Cultural context — the WhatsApp wedding message

The prompt:

Write a heartfelt wedding congratulations message in Hindi for a close friend. It should feel warm and genuine — the kind of message an Indian person would actually send on WhatsApp, not a translated greeting card.

GPT-4o-mini gave one warm, natural Hinglish message. Good tone, genuine feel, appropriate for close friends.

Gemma 4 gave three options — labelled "Deeply Emotional", "Sweet and Simple", and "Playful/Desi" — with a tip section that included culturally specific advice: use "Mere bhai" for a guy friend, "Meri jaan" for a girl friend, and add a personal memory line like recalling who said they'd get married first.

The "Desi" option included the phrase "finally tu bhi 'phass' gaya" — which is authentic Indian friend-group humour that no greeting card would ever produce. That level of cultural specificity is hard to fake.

Verdict: Gemma 4 wins — not just for giving more options, but for demonstrating that it understands how Indian friendships actually communicate.

Prompt 5: Bengali — and the failure that says everything

The prompt was written in Bengali script, asking both models to explain AI to a 15-year-old student in simple Bengali.

GPT-4o-mini's response: It returned the original Bengali prompt, with the English translation below it. No explanation. No attempt. Just the input, echoed back.

This is not a minor miss. Bengali is the seventh most spoken language in the world. It is the official language of West Bengal and Bangladesh. Asking an AI model to respond in Bengali is not an exotic edge case — it is a basic requirement for serving a massive, real user population.

Gemma 4's response was a detailed, properly structured Bengali explanation covering what AI is, how machine learning works (using the analogy of teaching a child to recognise cats), and real-world examples including YouTube recommendations and ChatGPT. Written entirely in proper Bengali script. Age-appropriate. Clear.

Here is a direct excerpt from Gemma 4's Bengali response:

এটি কীভাবে কাজ করে? চলো একটা উদাহরণের মাধ্যমে বুঝি: মনে করো, তুমি একটা ছোট বাচ্চাকে শেখাচ্ছ যে 'বিড়াল' দেখতে কেমন। তুমি তাকে অনেকগুলো বিড়ালের ছবি দেখালে এবং বললে, "দেখো, এটা বিড়াল।" AI-এর কাজ করার পদ্ধতিও ঠিক তেমন।

A cat-recognition analogy to explain machine learning, in Bengali, for a teenager. That is genuinely good pedagogy.

Verdict: Gemma 4 wins by default — GPT-4o-mini did not attempt the task.

The Overall Scorecard

Task	Gemma 4	GPT-4o-mini
Hinglish poem	Natural, emotional	Natural, humorous
Formal Hindi email	Devanagari script, structured ✅	Roman script only ❌
News translation	Accurate + linguistic insight ✅	Accurate only
WhatsApp wedding message	3 culturally aware options ✅	1 good option
Bengali explanation	Excellent, full response ✅	Failed — echoed prompt ❌

Gemma 4: 4 wins, 1 tie. GPT-4o-mini: 0 wins, 1 tie, 2 clear failures.

Why does Gemma 4 perform better here?

This is informed speculation, not a technical deep-dive.

Google has been building Indian language products for years — Google Translate, Google Search in Indic scripts, Google Assistant in Hindi. That corpus and institutional knowledge almost certainly shaped Gemma's training data in ways a model primarily optimised for English-language internet text would not replicate.

Gemma 4's choice to use Devanagari without being asked, its "करोड़ों vs लाख" observation, and its ability to produce three contextually distinct registers in a single response all point to a model that has deeply absorbed how Indian languages actually function — not just what Indian language text looks like.

The practical verdict

Use Gemma 4 when:

Your users communicate in Hindi, Bengali, or other Indic languages
You need correct script output, not just Roman transliteration
Cultural nuance matters — greetings, office communication, social messages
You are building any product for Indian users

GPT-4o-mini still holds its own for:

Casual Hinglish content — it is genuinely good here
English-first tasks with occasional Hindi
Contexts where Roman script is acceptable

The most important finding is not that one model "won." It is that the gap is large enough to matter for real product decisions. If you are building a Hindi chatbot, a regional language assistant, or anything targeting Indian users, defaulting to GPT-4o-mini because it is familiar could mean your users get their own prompts echoed back at them.

That is not a UX problem. That is a trust problem.

Getting started with Gemma 4

All of this testing was done at zero cost:

Gemma 4 31B: Free via OpenRouter — no credit card required
Gemma 4 2B/4B: Available on Google AI Studio for free
Run locally: Download from Hugging Face and run with ollama

The Gemma 4 Challenge runs through May 24 — if this sparked an idea for something you want to build for Indian language users, now is the time.

All responses in this article were captured from actual model runs. Nothing was edited or paraphrased — you are reading what the models actually produced.

A2A + MCP — The Two Protocols That Were the Actual Story of Google Cloud NEXT '26

Saquib Shahid — Fri, 24 Apr 2026 22:37:59 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Hey, I'm Saquib. I've been deep in the backend trenches for a couple of years now, mostly building out Node and Go microservices. Like pretty much every dev in 2026, I spent the last few months messing around with AI. Wiring LLMs into APIs. Breaking stuff. Fixing it. Getting a prototype working on the first try and immediately assuming something is horribly wrong.

When Google Cloud NEXT '26 kicked off, I actually blocked out some calendar time to watch. My feed was absolutely flooded with hot takes on the Gemini Enterprise Agent Platform and the new 8th-gen TPUs. Everyone also had a very loud opinion about that "75% of Google's code is AI-generated" stat.

But honestly? I kept getting distracted by two boring acronyms.

A2A and MCP.

They barely got any stage time. No hype reel. But I genuinely think they were the most important things announced at the whole event. Let me try to explain why.

the problem nobody wanted to say out loud

Every vendor on stage was showing off agents. Salesforce has Agentforce. ServiceNow's got one. SAP too. Microsoft Copilot, obviously. Google's Gemini Enterprise. Basically everyone is shipping agents right now. Which is fine.

But the question I kept coming back to was way less glamorous: how do any of these things actually talk to each other?

In a normal backend setup, when two microservices need to chat, we have a playbook. REST, gRPC, Kafka queues, OpenAPI specs. The whole mess is solved. It's boring and it works.

But with agents? A year ago, the answer was they just didn't. Or worse, they did it through some horrible custom webhook adapter that someone is going to have to babysit from a Slack DM at 2am. Every system spoke its own language. Integration wasn't a feature—it was somebody's entire job.

A2A and MCP fix that exact problem. Google finally stopped treating them like research experiments and started treating them like actual infrastructure.

the mental model that finally made it click

I had to read the docs a few times before I really got it. Here is the summary I wish I had on day one.

MCP is HTTP for agents. A2A is DNS plus HTTP for agents talking to other agents.

MCP (Model Context Protocol) was Anthropic's baby originally. It standardizes how a model reaches out to your tools and databases. Before MCP, if you wanted Gemini to query a database, you had to write a bunch of glue code and pray the model didn't invent a table name. Now, the model speaks MCP, the server speaks MCP, and they just shake hands.

A2A (Agent2Agent) came from Google and got donated to the Linux Foundation. It standardizes how one agent talks to another autonomous agent.

The A2A docs say it best: build with whatever framework, equip with MCP, and communicate with A2A. They aren't competing standards. MCP is how your agent talks down to the database. A2A is how it talks sideways to another agent. That realization saved me a massive headache.

okay, so what did google actually ship?

A lot of this trickled out before NEXT, but the conference is where they put it all together into an actual strategy.

On the MCP side, we got fully managed servers for things like BigQuery, Cloud SQL, and Pub/Sub. You don't deploy anything. You just point your agent at an endpoint. They also turned Apigee into an MCP bridge. This means any REST API you already built instantly becomes a discoverable agent tool with your existing auth layered on top. As a guy who spent way too long last year hand-wrapping APIs for LLMs, that was a huge relief. Auth is all IAM-backed now too, so no more passing API keys around.

On the A2A side, it hit production grade with LangGraph and CrewAI support. Donating it to the Linux Foundation was a big move. They also announced Agent Registry (basically DNS for your internet of agents) and Agent Gateway.

Put it all together, and Google is basically saying they don't need to own the agent itself. They just want to own the highways the agents drive on.

show me the code

I hate architecture diagrams. I need to see the actual implementation. So here is a really minimal setup: a planner agent analyzing data, handing work off to a reporter agent in a completely different service.

Planner first. We'll set it up to hit BigQuery via MCP:

# planner_agent.py
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import MCPToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams

# Point at Google Cloud's managed BigQuery MCP server.
# No infra to deploy. Auth handled by IAM.
bigquery_tools = MCPToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://bigquery.googleapis.com/mcp/v1",
    ),
)

planner = LlmAgent(
    name="sales_planner",
    model="gemini-3.1-pro",
    instruction=(
        "You analyze sales data in BigQuery and prepare a brief "
        "for the reporter agent. Findings as bullet points only."
    ),
    tools=[bigquery_tools],
)

Notice what's missing there. There are no BigQuery SDK imports or crazy prompt schemas. The managed MCP server just exposes the database as an agent tool. When I ran this the first time, I kept looking for the missing step. There isn't one.

Next, we expose the reporter agent over A2A:

# reporter_server.py
from a2a.server import A2AServer
from a2a.types import AgentCard, AgentSkill

# The Agent Card is the "business card" that other agents fetch.
# Served at /.well-known/agent-card.json automatically.
card = AgentCard(
    name="QuarterlyReporter",
    description="Turns sales briefs into formatted exec reports.",
    version="1.0.0",
    url="https://reporter.example.com",
    skills=[
        AgentSkill(
            id="write_exec_report",
            name="Write executive report",
            description="Takes bullet findings and produces a polished report.",
            input_modes=["text"],
            output_modes=["text", "application/pdf"],
        )
    ],
)

server = A2AServer(agent_card=card, handler=my_report_handler)
server.run(host="0.0.0.0", port=8080)

That Agent Card is the magic part. It's just a tiny JSON doc at a predictable URL. It tells any other agent from any cloud exactly what this bot can do and how to authenticate. It's basically robots.txt for AI.

Finally, we make them talk:

# orchestrator.py
from a2a.client import A2AClient, A2ACardResolver

# Discover what the reporter can do.
resolver = A2ACardResolver(base_url="https://reporter.example.com")
card = await resolver.get_agent_card()

# Open a client against it.
reporter = A2AClient(agent_card=card)

# Run the planner...
findings = await planner.run("Analyze Q1 2026 revenue by region.")

# ...and hand off to the reporter over A2A.
task = await reporter.send_task(
    message={"parts": [{"type": "text", "text": findings}]},
)

# A2A tasks have a real lifecycle so we stream updates back.
async for update in reporter.stream_task(task.id):
    print(update.status, update.artifacts)

Three files and we have a working cross-service handoff. The crazy part is that the reporter could be running on AWS or it could be a Salesforce agent. The planner code wouldn't need to change at all.

the detail most write-ups miss

A lot of the coverage I've seen just says "these are cool." True. But the interesting part is the underlying design.

A2A is basically stealing every good idea from how the early web scaled. Agent Cards live at /.well-known/agent-card.json. That's RFC 8615, the same pattern we use for security.txt. They're using JSON-RPC 2.0 over HTTP and Server-Sent Events. If your system speaks HTTP, it speaks A2A.

Tasks have a normal lifecycle too. Submitted, working, completed. It's the same shape as AWS Step Functions or GitHub Actions. It's boring—and coming from backend land, that's basically the nicest thing I can say about a tech. Clever protocols usually die because nobody wants to actually implement them. MCP and A2A are predictable.

stuff I'm still not sold on

Look, I'm not totally sold yet.

The security surface area here is terrifying. An agent that can auto-discover other agents and pass tasks around is an absolute nightmare for prompt injection or data exfiltration. I'd need a very solid threat model before letting this touch real production data.

Debugging is also going to be awful. Google says everything lands in Cloud Audit Logs. Cool. But tracing a failed task across three different agents built by three different vendors? Prepare for a lot of late nights.

Also, the spec is still moving. A2A is at the Linux Foundation, which means it will evolve. If you build heavily on it today, you will probably be rewriting parts of it next year.

what I'd actually do this week

If you want to get ahead of this, here is my unsolicited advice.

Go run the A2A Python quickstart. It takes maybe an hour and you get a working agent in 50 lines. Then hook a basic agent up to a managed MCP server. BigQuery is probably the easiest to test. Read a real Agent Card—just go look at the JSON and see how the auth and skills are structured. It grounds the whole concept. Just don't overbuild right away. Start with two agents and see what breaks.

Next '26 was Google quietly admitting that no single company will own the agent ecosystem. So they're building the infrastructure instead. A2A is the DNS. MCP is the HTTP. If you learn these protocols now, future-you is going to be really happy about it. That's my bet anyway.

If you are building with A2A or MCP, drop a comment. I'd love to swap notes, especially if you've hit weird OAuth snags between managed MCP servers and non-Google clients. I definitely spent a few hours stuck on that this week.

— Saquib

BrewOS 3000: The $47M Enterprise Coffee Platform That Has Never Made Coffee

Saquib Shahid — Thu, 09 Apr 2026 17:34:58 +0000

This is a submission for the DEV April Fools Challenge, Best Ode to Larry Masinter

What I Built

In 1998, Larry Masinter published RFC 2324 — the Hyper Text Coffee Pot Control Protocol. It defined a new HTTP method (BREW), a new status code (418 I'm a Teapot), and exactly zero practical applications. It was an April Fools joke. It became immortal.

BrewOS 3000 is my love letter to that joke.

It is a NASA mission-control-grade enterprise coffee procurement dashboard that:

Accepts your blood type (affects roast compatibility)
Requires you to select your Existential Mood State (Monday is a valid option)
Makes you pass a CAPTCHA to add milk ("Spell COFFEE backwards")
Asks you to agree that "coffee is a human right and you accept all karmic responsibility for choosing decaf"
Runs a live WebSocket diagnostics log that — I cannot stress this enough — logs [17:22:32] Querying Larry Masinter's ghost... 404
Tracks six real-time metrics including Bean Entropy, Grind Latency, and Quantum Roast Index
Executes a full 8-step async brew sequence with blockchain verification
Always fails with HTTP 418.

Every single time. Without exception. By design.

I am a teapot
Short and stout, here is my spout
Your coffee: denied

🔗 Live demo: htcpcp.vercel.app

Demo

htcpcp.vercel.app

![BrewOS 3000 dashboard showing brew parameters, live diagnostics log reading "Querying Larry Masinter's ghost... 404", and six real-time telemetry metrics in a dark CRT-style terminal UI]

SYSTEM UPTIME: 09:02:28 · ONLINE · NEVER BREWED

Code

saquib-shahid / htcpcp

Dev April fool challenge

title	BrewOS 3000: The $47M Enterprise Coffee Solution That Has Never Brewed a Cup
published	false
description	My submission for the DEV April Fools Content Challenge - Best Ode to Larry Masinter
tags	webdev, humor, javascript, aprilfools, react

🚀 The $47M Mission

Picture this: The year is 2021. Our CEO waited an agonizing four minutes for a latte at a hipster coffee shop. In a moment of pure unadulterated hubris, he decided what the world really needed was not another barista, but a distributed coffee infrastructure platform powered by Web3, Machine Learning, and arbitrary venture capital.

We raised $47M in Series B funding. We hired 200 engineers. We spent two years rewriting our microservices in Rust.

And we have never made a single cup of coffee.

Welcome to [BrewOS 3000], my wildly over-engineered submission for the DEV April Fools Content Challenge 2024 under the "Best Ode to Larry Masinter"…

View on GitHub

How I Built It

Stack: React + Vite, Tailwind CSS v4, deployed on Vercel.

Fonts: Bebas Neue for headers, Share Tech Mono for everything that needed to feel like a submarine terminal. Both doing serious work here.

The aesthetic: Full dark CRT mission-control theme. Amber-on-black. Scanline overlay. Real-time metrics that fluctuate via setInterval to make it look like the servers are working incredibly hard to do nothing.

The brew sequence is a React state machine — eight async steps with artificial delays, each one logging to the live diagnostics panel. Steps include:

Validating blood type against NASA coffee manifest
Verifying bean provenance on-chain
Checking municipal brew permit
Milk authorization CAPTCHA
Blockchain roast consensus (always times out)
Biometric mood analysis
Running 47 pre-flight safety checks
Attempting to brew → 418

The diagnostics log streams these in real time. The progress bar hits 99% and turns red. The 418 modal takes over the screen with the full RFC citation and the haiku.

I originally planned a real Node/Express HTCPCP backend, but realized the true startup move is to fake the entire infrastructure client-side to save on compute costs. We call this "serverless". Investors love it.

Keyboard shortcuts exist, because of course they do. Press B to initiate brew. Press Escape to acknowledge your failure and try again.

Prize Category

Best Ode to Larry Masinter.

Here's why this earns it:

RFC 2324 is one of the greatest pieces of technical writing in internet history. It's a fully specified protocol, complete with BREW and WHEN methods, error codes, and a clause prohibiting the addition of milk "to an Assam Darjeeling". It introduced 418 I'm a Teapot as a serious-looking status code for a joke that has since survived every attempt to remove it from the web. Developers rallied. The code stayed. Larry Masinter won.

BrewOS 3000 does not merely reference RFC 2324. It implements it — faithfully, reverently, and completely uselessly. The BREW request fires. The 418 returns. The teapot wins. Every time.

This is the only correct way to honor a man who made the internet laugh for 28 years and counting.