NestJS + LangChain vs HazelJS

TL;DR

• NestJS + LangChain is the default “production AI backend” recipe for many TypeScript teams.
• It works — and it creates two frameworks, two config stories, and a lot of glue between HTTP and AI.
• HazelJS is built so controllers, agents, RAG, memory, and workflows share one module system and DI container.
• Keep Nest + LangChain if you already invested heavily and AI is a thin layer.
• Switch (or start new) on HazelJS when agents/RAG are the product.

Who this is for

Teams that:

• Run NestJS APIs and added LangChain for RAG/agents
• Feel pain from dual paradigms (Nest providers vs LangChain runnables)
• Want auth, caching, observability, and agents under one roof

Not ideal if:

• You only need a few LLM calls in Nest controllers (raw OpenAI SDK may be enough)
• You depend on LangChain ecosystem plugins HazelJS does not mirror yet
• You are Python-first (LangChain’s gravity is stronger there)

The glue-code problem

A typical Nest + LangChain setup looks like:

NestJS module
  └─ Controller / Guard / Pipe
       └─ Service
            └─ LangChain chain / agent / retriever
                 └─ Vector store, embeddings, tools, memory

Every new AI feature means bridging:

• Nest DI ↔ LangChain constructors
• Nest config ↔ LangChain env/secrets
• Nest logging/OTel ↔ LangSmith or custom LLM traces
• Nest auth context ↔ tool execution identity

HazelJS collapses that bridge: agents and HCEL chains are providers in the same graph as your HTTP layer.

Side-by-side

Code: glue vs native

Nest service wrapping LangChain (illustrative glue):

// Nest provider manually constructs LangChain pieces
@Injectable()
export class ChatService {
  private chain: any;

  constructor(private config: ConfigService) {
    const model = new ChatOpenAI({ apiKey: this.config.get('OPENAI_API_KEY') });
    const retriever = /* wire vector store */;
    this.chain = RunnableSequence.from([
      /* prompt */,
      retriever,
      model,
    ]);
  }

  async ask(input: string) {
    return this.chain.invoke({ input });
  }
}

HazelJS HCEL in the same DI world:

import { Injectable } from '@hazeljs/core';
import { AIService } from '@hazeljs/ai';

@Injectable()
export class ChatService {
  constructor(private ai: AIService) {}

  async ask(input: string) {
    return this.ai.hazel
      .prompt('Answer using docs: {{input}}')
      .rag('engineering-docs')
      .agent('support-specialist')
      .execute(input);
  }
}

Support agent without a separate executor framework:

import { Agent, Tool } from '@hazeljs/agent';

@Agent({
  name: 'support-desk',
  enableMemory: true,
  enableRAG: true,
  systemPrompt: 'Resolve tickets with tools when needed.',
})
export class SupportDeskAgent {
  @Tool({
    description: 'Create a ticket',
    parameters: [{ name: 'title', type: 'string', required: true }],
  })
  async createTicket(input: { title: string }) {
    return { id: 'T-100', title: input.title };
  }
}

Decision guide

When NestJS + LangChain is better

• Your org standardized on LangSmith / LangGraph and training is done
• You need a LangChain integration HazelJS does not ship yet
• Political cost of introducing another framework exceeds glue-code cost

HazelJS is the better default when time-to-production agent API and one observability/auth story matter more than LangChain ecosystem breadth.

Related comparisons

• HazelJS vs NestJS — framework-only view
• HazelJS vs LangChain — AI library view (coming in this cluster)
• Support agent example — production pattern reference

Next steps

1. Docs: Agent package
2. Docs: RAG and RAG vs Agentic RAG
3. Agent OS guide
4. Installation
5. GitHub