Core Philosophy
Nadoo Flow Core is built on a foundation of carefully considered design principles that prioritize developer experience, performance, and maintainability.Our Mission: Provide a workflow orchestration framework that is powerful enough for complex enterprise applications, yet simple enough for rapid prototyping.
Guiding Principles
1. Minimal Dependencies
“Less is exponentially more” - Rob PikeWe believe in keeping the dependency tree as small as possible. With only 2 core dependencies (Pydantic and typing-extensions), we:
- Reduce security vulnerabilities
- Minimize version conflicts
- Speed up installation
- Simplify deployment
- Improve long-term maintainability
2. Async-First Architecture
“Concurrency is not parallelism” - Rob PikeBuilt on Python’s native Benefits:
asyncio, every component is designed for non-blocking execution:- Handle thousands of concurrent workflows
- Efficient resource utilization
- Natural fit for I/O-bound operations
- Compatible with modern Python ecosystem
3. Type Safety Through Pydantic
“Explicit is better than implicit” - Zen of PythonWe use Pydantic v2 throughout for:
- Runtime type validation
- Automatic serialization/deserialization
- Clear API contracts
- Better IDE support
- Self-documenting code
4. Protocol-Based Design
“Program to interfaces, not implementations” - Gang of FourOur multi-backend architecture uses Python protocols:This enables:
- Backend swapping without code changes
- Gradual migration paths
- Framework independence
- Testing flexibility
5. Composability Over Inheritance
“Favor composition over inheritance” - Design PatternsWe prefer small, composable units:This approach:
- Reduces complexity
- Increases flexibility
- Improves testability
- Enables runtime composition
Architectural Decisions
Why Not Just Use LangChain?
LangChain is excellent for rapid prototyping, but we built Nadoo Flow Core for different use cases:| Aspect | LangChain | Nadoo Flow Core |
|---|---|---|
| Target Audience | AI researchers, prototypers | Platform builders, enterprises |
| Dependency Philosophy | Batteries included (50+ deps) | Bring your own batteries (2 deps) |
| Customization | Use pre-built components | Build your own components |
| Learning Curve | Steep (LCEL complexity) | Gentle (simple abstractions) |
| Use Case | Quick AI experiments | Production workflows |
Why Multi-Backend?
Future-Proofing
Future-Proofing
The AI landscape changes rapidly. Today’s best framework might be tomorrow’s legacy code. Multi-backend design ensures your workflows remain portable.
Best Tool for the Job
Best Tool for the Job
Different backends excel at different tasks:
- Native: Maximum control and performance
- LangGraph: Complex state machines
- CrewAI: Multi-agent collaboration
- A2A: Google Cloud integration
Gradual Migration
Gradual Migration
Start simple with the native backend, then migrate to specialized backends as your needs evolve—without rewriting your workflows.
Why Nodes?
Nodes provide the perfect abstraction level:- Functions: Too simple, lack state and lifecycle
- Nodes: Perfect balance of simplicity and power
- Classes: Too complex for workflow building
Design Patterns
1. Builder Pattern for Workflows
2. Strategy Pattern for Execution
3. Decorator Pattern for Node Enhancement
4. Observer Pattern for Monitoring
Performance Philosophy
Optimize for the Common Case
Most workflows are I/O-bound, not CPU-bound. We optimize for:
- Network calls (APIs, databases)
- File operations
- User interactions
- LLM completions
Memory Over Speed
We prioritize memory efficiency over raw speed:
- Streaming instead of buffering
- Lazy evaluation where possible
- Cleanup after node execution
- Bounded queues for streaming
User Experience Philosophy
Progressive Disclosure
Start simple, add complexity as needed:Fail Fast, Fail Clearly
Documentation as First-Class Citizen
Every public API includes:- Type hints for IDE support
- Docstrings with examples
- Parameter descriptions
- Return value documentation
Future Vision
Where We’re Going
1
Visual Builder
No-code interface for workflow creation while maintaining code-first approach
2
Distributed Execution
Native support for distributed workflow execution across multiple machines
3
More Backends
Integration with AutoGen, Semantic Kernel, and other emerging frameworks
4
Workflow Marketplace
Share and reuse workflow templates and custom nodes
What We Won’t Do
Community Philosophy
Open Source, Open Development
- Transparent roadmap: Community input shapes our direction
- Clear contribution guidelines: Everyone can contribute
- Responsive maintenance: Issues and PRs addressed quickly
- Backward compatibility: Your code keeps working
Learning Resources
We believe in comprehensive documentation:- Tutorials: Start from zero
- How-to guides: Solve specific problems
- Reference: Complete API documentation
- Explanations: Understand the why
Summary
Nadoo Flow Core is more than code—it’s a philosophy of building workflow systems that are:
- Simple to understand and use
- Flexible enough for any use case
- Reliable in production
- Performant at scale
- Maintainable over time
Join us: If these principles resonate with you, we’d love your contributions, feedback, and ideas. Together, we’re building the foundation for the next generation of AI applications.