Loading project...
Loading project...
Plug-and-play chatbot engine for any Node.js application
A concise look at the project, its purpose, and its value.
ChatBot Foundation is a production-ready chatbot engine library for Node.js applications. It provides out-of-the-box support for prompt management, conversation memory, tool calling, streaming responses, and session lifecycle management.
Node.js developers who want to add chatbot capabilities to their applications without building AI infrastructure from scratch.
Developers can integrate a fully-featured chatbot in hours instead of weeks. The engine handles all the complex parts — memory management, tool execution, streaming, error handling — so teams focus on building conversation logic and features.
Every time I built a chatbot feature for a project, I found myself rewriting the same infrastructure: prompt templates, conversation history, tool routing, streaming setup. ChatBot Foundation packages all that reusable infrastructure into a single plug-and-play library.
Adding AI chatbot features to an application requires solving the same infrastructure problems every time: managing conversation context, handling token limits, implementing streaming, wiring up tool calls, and ensuring reliable error recovery. Teams waste weeks building this foundation before they can start on actual chatbot features.
The impact: Development teams spend 60-70% of chatbot development time on infrastructure rather than conversation logic. Each project reinvents the wheel. Production issues from memory leaks, context overflow, and streaming errors are common. Small teams often abandon chatbot features due to complexity.
ChatBot Foundation provides a clean, extensible API that wraps LangChain and OpenAI capabilities with sensible defaults. Developers configure their chatbot through a simple options object — prompt template, available tools, memory type — and get a fully working chatbot with streaming, session management, and error handling.
What this project can do
Built-in memory management with multiple strategies — buffer, summary, or custom — for maintaining context across turns.
Define tools with Zod schemas and the AI automatically calls them with validated parameters when needed.
Native SSE streaming support for real-time token-by-token responses without blocking the event loop.
Configure your chatbot in 5 lines of code — engine, memory, tools, and you're ready to chat.
Version-controlled prompt templates with variable injection and conditional logic for dynamic responses.
Automatic session creation, timeout handling, and cleanup. No manual session management needed.
Swap AI providers (OpenAI, Anthropic, etc.) without changing chatbot logic — provider abstraction built in.
Every interaction logged with timing, token usage, tools called, and errors. Winston integration out of the box.
Visual walkthrough of the project
How the system is designed and how components interact
ChatBot Foundation uses a layered architecture: the Engine layer orchestrates conversations, the Provider layer abstracts AI models, the Memory layer manages conversation state, and the Tool layer handles external integrations. Each layer implements a clean interface, allowing developers to swap implementations without touching other layers.
Visual overview of system design, data flow, and key processes
How a user message flows through the Engine, Provider, Memory, and Tool layers to produce a response.
Sequence showing how the system handles a request with multiple AI provider fallback and tool execution.
The technologies used to build this project
The hard problems that needed solving
How the system is designed for speed and scale
All responses support streaming via SSE. Users see tokens as they're generated rather than waiting for full responses, improving perceived performance significantly.
Conversation memory uses a sliding window approach by default. Only recent messages and summarized context are sent with each request, minimizing token usage and cost.
The Express adapter uses connection pooling for database-backed memory stores, preventing connection exhaustion under load.
Layered design allows independent scaling of components. Memory can be backed by different stores (in-memory, Redis, database) based on performance needs.
How the system is protected
All user inputs validated through Zod schemas before reaching the AI engine. Malformed or malicious inputs are rejected early.
Each tool has permission requirements. The engine checks tool authorization before execution, preventing unauthorized actions.
Built-in rate limiting support through middleware. Developers can set per-session or per-user limits on AI requests.
Winston-based logging captures all interactions. Sensitive data can be redacted through configurable filters.
Sessions have configurable timeouts and auto-cleanup. Expired sessions are automatically garbage collected.
What I learned building this project and what I'd do differently
I initially abstracted the AI provider layer from day one. This was premature — I only used OpenAI. The abstraction added complexity without benefit. A better approach would be to start concrete and abstract when a second provider is actually needed.
Building streaming-first changed the architecture significantly. Callbacks and async generators required different error handling patterns than request-response. But the UX improvement made it worth the complexity.
Early versions had loose tool validation and the AI occasionally generated invalid or dangerous parameters. Switching to Zod schemas with runtime validation eliminated this class of bugs completely.
I'd add built-in support for multi-modal models (image understanding), a plugin system for third-party tools, and a dashboard for monitoring conversations and token usage.
Other projects you might find interesting
I build AI-powered conversational systems. Let's discuss how I can add intelligent chat to your product.
