nebu will remain CLI-focused with Unix pipes. It will NOT become a gRPC orchestrator or service manager.
For complex orchestration (gRPC, multi-language, distributed pipelines), use flowctl.
"Nebu felt cool and minimal being able to string together processors on the command line versus having to write a pipeline file to keep track of services"
nebu follows the Unix philosophy:
- Do one thing well - Extract data from Stellar, stream it as JSON
- Composable - Chain processors with pipes,
jq,grep,awk - Minimal - No service management, no port allocation, no process orchestration
- Fast to prototype - Get results in 2 minutes, not 2 hours
The original GRPC_PROCESSORS.md proposed making nebu an orchestrator. This would require:
- Service lifecycle management (start, stop, health checks)
- Port allocation and discovery
- gRPC client/server setup
- Pipeline YAML configuration
- Process monitoring
This duplicates flowctl's functionality and adds complexity to nebu.
| Aspect | nebu | flowctl |
|---|---|---|
| Purpose | Stellar data extraction | General pipeline orchestration |
| Target User | Developers prototyping, analysts exploring data | DevOps running production pipelines |
| Communication | Unix pipes (stdin/stdout, JSON) | gRPC (protobuf, type-safe) |
| Setup Time | 2 minutes (install + run) | 10-30 minutes (write pipeline YAML, deploy) |
| Complexity | Minimal (spawn process, pipe data) | Full orchestration (service manager, control plane) |
| Multi-Language | Go only (currently) | Any language via containers |
| Use Case | Quick analysis, ad-hoc queries, testing | Production indexers, distributed systems, monitoring |
- Wire format: Newline-delimited JSON via Unix pipes (stdin/stdout)
- Internal: Protobuf structs from Stellar SDK for type safety
- Language: Go only (currently)
- Why JSON? Easy to debug with
cat,jq,grep. Works with DuckDB, shell scripts, any language.
- Wire format: Native protobuf over gRPC streams
- Internal: Protobuf-generated types
- Language: Any (Python, Rust, TypeScript, Go, etc.)
- Why Protobuf? Type safety, binary efficiency, streaming performance
Key difference: nebu uses JSON for interoperability (any tool can consume it). flowctl uses protobuf for type safety and performance (controlled environment).
- Prototyping a new processor or pipeline
- One-off analysis ("show me USDC transfers in ledger range X")
- Piping to
jq, DuckDB, or shell scripts - Single-machine pipelines
- Simple Go processors
- Fast iteration (no YAML, no service management)
- Production pipelines with SLA requirements
- Multi-language processors (Python, Rust, TypeScript)
- Distributed systems (multiple machines)
- Need observability (metrics, health checks, tracing)
- Complex DAG topologies (fan-out, fan-in)
- Service lifecycle management required
For simple processors: Stay with nebu CLI mode (Go, stdin/stdout, JSON)
For complex processors: Build as flowctl components from the start:
- Python, Rust, TypeScript, etc.
- gRPC with protobuf definitions
- Full type safety and streaming
- Deployed as containers or processes
No tight coupling: nebu and flowctl are independent projects with different goals.
In the future, nebu processors could optionally be packaged as flowctl components:
nebu export token-transfer > flowctl-component.yaml- flowctl wraps nebu processor in a process/container
- Users get choice: CLI simplicity or orchestration power
But this is not required - both tools work independently.
nebu is a data extraction tool optimized for speed and simplicity.
flowctl is a service orchestrator optimized for production and complexity.
Use the right tool for the job.