DEV Community: DeadLocker

Why I Stopped Using LangGraph

DeadLocker — Thu, 23 Apr 2026 16:54:32 +0000

Most small LLM applications don't need a state graph framework. I know this because I used LangGraph in 8 out of 10 AI projects I built—and eventually replaced it in most of them.

I want to be clear upfront: LangGraph is well-built software. The team behind it is sharp, the abstractions are thoughtful, and for genuinely complex multi-agent workflows, it earns its place. This isn't a takedown. It's a case for matching tools to problem size.

What Pulled Me In

The graph metaphor is compelling. Nodes for LLM calls, edges for transitions, a typed state object flowing through everything. When I first saw LangGraph's architecture diagram, it felt like someone had finally imposed order on the chaos of LLM non-determinism. As someone with a traditional software engineering background, that was reassuring.

My first project was a document processing pipeline—upload PDFs, extract information, run multiple analysis passes, generate reports. Real branching logic, real dependencies between steps, real error handling concerns. LangGraph handled it well. I could visualize the flow, trace state through the graph, and reason about the whole system by looking at the diagram.

For that use case, it was the right tool.

Where It Turned

The friction didn't come from a single failure. It accumulated gradually as overhead.

The first sign was when I added multi-document comparison to that pipeline. My rigidly typed state object—clean and purposeful in v1—suddenly needed to handle lists of documents, keyed dictionaries of extracted data, and conditional type guards everywhere. Every node had to branch on "one document vs. many." The state schema became a maintenance burden.

Then I started a new project: a simple chatbot. Answer questions over a knowledge base, remember conversation history, escalate to humans when confidence is low. I reached for LangGraph out of habit and built a state graph with nodes for retrieval, context assembly, response generation, confidence scoring, and escalation—plus conditional edges to route between them.

When I stepped back and looked at what I'd built, the mismatch was clear.

The code worked. But I had wrapped a linear pipeline with one branch in a state machine framework that required me to maintain type definitions, node signatures, and graph topology every time I wanted to tweak a prompt or adjust a threshold. The overhead of the framework was exceeding the complexity of the actual problem.

The issue was that I'd been confusing "structured" with "complex." These applications weren't complex—they were sequential operations dressed up in graph because the framework made them feel more rigorous.

The Question Worth Asking First

Before reaching for LangGraph on any given project, ask one question: do I have a genuinely complex workflow with many conditional paths and coordination between agents, or am I building a pipeline?

A chatbot is a pipeline. Retrieve context, generate response, check confidence. A document processor is a pipeline. Extract, transform, output. A summarization tool is a pipeline. Feed in text, get summary. These are sequences of operations with maybe a branch or two. They don't need a state graph—they need well-structured code with clear separation of concerns.

If the answer is "pipeline," you don't need LangGraph. You need functions, interfaces, and dependency injection.

What I Replaced It With

I switched to the Vercel AI SDK with a hexagonal architecture—ports and adapters. The core idea is simple.

LLM providers become adapters behind a shared interface:

// packages/adapters/src/llm/types.ts
import type { EmbeddingModel, LanguageModel, Tool } from "ai";

export interface LLMProvider {
  largeModel: LanguageModel;
  mediumModel: LanguageModel;
  smallModel: LanguageModel;
  embeddingModel: EmbeddingModel;
  webSearchTool?: { name: string; instance: Tool };
}

OpenAI, Gemini, Ollama—they all implement this. Domain code never knows which one is running.

Agents take a model through constructor injection:

// packages/core/src/agents/SummaryAgent/agent.ts
import { generateText, type LanguageModel } from "ai";

export class SummaryAgent {
  constructor(private readonly model: LanguageModel) {}

  async summarize(params: { ... }): Promise<string> {
    const { text } = await generateText({
      model: this.model,
      prompt: "...",
    });
    return text;
  }
}

No graph, no state schema, no framework runtime. A class that takes a model and does its job. Swap Gemini for Ollama by changing what you inject. The agent doesn't change.

Memory and embeddings follow the same pattern:

// packages/adapters/src/memory/createFirestoreMemory.ts
import { type EmbeddingModel, embed } from "ai";

export function createFirestoreMemory(...) {
  const embedFn = (text: string) =>
    embed({ model: embeddingModel, value: text }).then((r) => r.embedding);
  return new FirestoreAgentMemory(db, embedFn, collectionName);
}

The domain layer gets a memory interface. It doesn't know Firestore is involved or which embedding model is running.

What This Actually Changed

The difference isn't code length—it's that complexity stays proportional to the problem.

Testing became straightforward. Pass a mock model into an agent constructor and test the logic. No graph runtime to simulate, no state transitions to set up.

Provider swaps are config changes. Switching from OpenAI to Gemini meant updating one file in packages/adapters. Zero changes to agent code.

Adding features is low friction. A new step in a pipeline means writing a function and calling it. No state schema updates, no node signature changes, no topology verification.

Onboarding is fast. The codebase uses patterns every TypeScript developer already knows—constructors, interfaces, composition. No library-specific mental model required.

When LangGraph Is Still the Right Call

There are cases where LangGraph's value is clear:

Multi-agent systems with complex coordination. When agents need to share state and route to each other based on dynamic conditions, a graph model is a natural fit.
Workflows with heavy human-in-the-loop patterns. LangGraph's checkpointing and interrupt/resume capabilities are purpose-built for this.
Complex decision trees with many conditional branches. If your flow diagram looks like a subway map, a graph framework earns its keep.

If you're building one of these, LangGraph is likely the right choice.

But if you're building a chatbot, a RAG pipeline, a summarization tool, or a document processor—verify that you're solving your actual problem, not the framework's problem.

The Heuristic

Start with plain functions and dependency injection. Add a framework when the complexity of your coordination logic genuinely exceeds what straightforward code can express.

For most small LLM applications, you'll never reach that point.

I Joined My First Job and the Homepage Took Forever to Load

DeadLocker — Sat, 21 Mar 2026 05:44:49 +0000

Thinking back to my first real frontend job still stings.

I wasn't a total coding newbie—I had a CS degree and plenty of full-stack school projects. But professional work? Zero experience. No production traffic, and no QA breathing down my neck about real users bouncing.

When I joined, the e-commerce homepage felt brutally slow. QA kept dropping the same messages week after week:

"Homepage lagging again 😭"

"Hero + product grid take forever."

"Users are leaving because of the 3s+ delay."

I'd open the reports, see those agonizing waterfalls, and just feel paralyzed.

The stack looked modern on paper: S3 + CloudFront + Single Page App (SPA). To make it "modular," we used iframes for sections like recommendations or banners. In theory, it was plug-and-play. In practice, it was a heavy, fragile mess.

I could sense something was off, but I didn't have the vocabulary yet to explain why: every iframe was exposing a massive, redundant dependency graph that our monolith had hidden.

The seductive simplicity of the monolith

A single SPA feels clean when you first build it. One repo, one deployment. If you need to reuse a feature elsewhere, an iframe seems like a pragmatic shortcut: wrap the app, drop it in, ship fast.

That's the trap. An iframe doesn't just embed a UI; it embeds a runtime. We weren't just dropping a "banner" into the page; we were dropping an entire massive React ecosystem into a tiny window. Every "modular" section was forcing the browser to boot up a whole new instance of our giant store app.

The system was technically modern and architecturally overloaded at the same time. The iframes didn't create this overload—they made it impossible to ignore.

1. The weight problem: too much code for too little UI

This is usually where the pain shows up first.

A user opens a simple promotion page, but the browser ends up downloading the entire store application: product listing logic, product detail logic, event handling, routing, shared components — and whatever else had quietly accreted over time.

That means you pay the cost of the whole mall just to visit one kiosk.

A monolithic SPA often creates this problem because its bundle grows with the number of features, not with the size of the page the user is actually viewing. In practice, that leads to:

larger JavaScript payloads
longer parse and execution time
slower first interaction
more memory pressure on weaker devices

The iframe made the mismatch visible. Instead of loading a tiny, purpose-built promotion surface, the browser had to initialize a full app inside an embedded context. The user sees one feature, but the machine does full-system work. We had one big system masquerading as several smaller ones.

Core performance lie: the UI looks small, but the runtime cost is large—and the iframe architecture exposed this lie by forcing us to pay that cost multiple times on one page.

2. The invisible content problem: what crawlers can't easily see

The second failure mode is less visible, which is why teams often ignore it for too long.

The crawlability problem started with our client-rendered SPA architecture.
A client-rendered SPA already makes indexing fragile — search engines can execute JavaScript, but relying on that for your core product surface is a bet you probably shouldn't make. The iframe compounded this by adding another layer of indirection on top of an already shaky foundation.

That's the distinction worth making: the SPA made content invisible by default. The iframe made it harder to fix by scattering content across multiple embedded contexts.
If you strip out the iframe but keep a fully client-rendered product page, you still have a crawlability problem. The fix isn't just "remove the iframe" — it's "server-render the content, whether it's on the main page or the endpoint the iframe points to."

The part I got wrong

For a while, I assumed the main problem was "performance" in the generic sense.

So I looked for the usual suspects: network latency, image sizes, CDN headers, cache behavior. Those mattered — but they were not the whole story.

The deeper issue was architectural shape.

The app had too many responsibilities, too much shared code, and too many surfaces crammed inside one deployment unit. The iframe didn't create this problem—it revealed it by making us instantiate our monolith multiple times. It exposed one big system that we had been pretending was several smaller ones.

That was the mistake: blaming the messenger instead of the message.

I had to admit I didn't have the answer yet — and then ask for time to fix the system instead of just firefighting its symptoms.

So I went to my manager with a proposal: give the site a diet.

Not a vague "let's optimize." A real plan.

reduce the bundle
remove unused modules
split pages into smaller pieces
improve the build pipeline
stop making every page carry the weight of every other page

That conversation mattered as much as the code changes.

Sometimes ownership starts when you stop waiting for permission to understand the system.

What actually helped — and what we didn't do yet

I want to be honest about the scope here.
We didn't tear the monolith down completely. We didn't migrate to micro-frontends or rebuild from scratch. What we did was make the system smaller, cleaner, and easier to reason about — so that the next architectural decision wouldn't feel impossible.

Think of it as load-bearing surgery before the real renovation.

1. Tree shaking and dead-code removal

We stripped away modules that were bundled but never used.

This sounds mundane, but dead code isn't harmless. It still has to be discovered, bundled, transmitted, parsed, and often evaluated. Every unused import is a small tax on runtime.

2. SWC for faster builds

We introduced SWC to improve build speed.

That didn't just save developer time. It changed behavior. When builds are slow, people batch changes, avoid refactors, and hesitate to split code. When builds are fast, iteration feels cheaper. That makes architectural cleanup more realistic.

SWC didn't directly shrink our bytes, but it gave us the 10x faster build loops we needed to aggressively experiment with code-splitting without losing our minds.

3. Page splitting and better code splitting

Instead of making every page carry the whole app, we split features into smaller delivery units.

The rule was simple: if a user doesn't need a feature to view the current page, don't make them download it now.

This is where the unit of deployment matters. If the app surface is large, the bundle shouldn't pretend otherwise.

The results

The transformation wasn't subtle.

Deployment time dropped from 10 minutes to about 2.

Loading time fell from more than 3 seconds to under 1 second.

Those aren't vanity metrics. They change how teams work. Faster deploys mean faster feedback. Faster feedback means more confidence. More confidence leads to better architecture decisions because people are no longer afraid to touch the code.

And better architecture decisions compound.

The lesson: optimize by shrinking what you ask the browser to carry

Here's the real takeaway.

If your app is big enough to contain multiple product experiences, promotion systems, and routing behaviors, then embedding it via iframe for modular reuse is usually the wrong default—not because iframes are bad, but because they force you to pay the full cost of your monolith multiple times.

Not because iframes are inherently bad.

Not because SPAs are inherently bad.

But because a bloated monolith embedded multiple times on one page creates a multiplicative performance disaster.

A better architecture usually does one or more of these:

serves distinct product experiences as distinct pages with properly split bundles
uses SSR or prerendering where crawlability matters
splits bundles by route and by feature so no page carries weight it doesn't need
keeps iframes for truly isolated embeds with minimal shared dependencies, not as a way to reuse a full application
reduces shared runtime between unrelated surfaces

The goal is simple: make the browser load only what the user needs, let search engines see what matters, and make failures local instead of global.

That's the bet I'd make again.

Not that every frontend should be micro-frontends.

Not that every SPA should be thrown out.

But that when your app starts behaving like a whole ecosystem, the right move is to make the monolith small enough that embedding it doesn't break your performance.

Conclusion

The hardest part of this project wasn't the bundle size or the deployment time. It was admitting that the architecture was making the load-time slower and the product worse.

Once I stopped treating the problem as a series of isolated bugs, I could see the pattern: too much code, too much coupling, and an iframe strategy that multiplied those sins instead of solving them.

I used AI assistance for this post, but the experiences and ideas are genuine.