# Goals

# Simplicity

The original idea was "compose pipelines by simply wiring up functions", or to put it another way: "Don't DSL me, bro!" While some complexity has crept in with things like error handling, starting & stopping stages, and handling backpressure, the goal is to stay as close to that original plan as possible.

# Versatility

Keeping the plugin interface simple & loose allows for things to be wired up in all kinds of weird and sometimes dangerous ways. Supporting that kind of creativity trumps preventing users from shooting themselves in the foot.

# Hackable

The plugin development story must be simple and not be too onerous. One of the benefits of targeting a JavaScript runtime is its built-in visual debugger that is already familiar to web developers. Being able to opt in to more type safety with TypeScript is another one.

# Function Over Form

Avoid the temptation of "cool", whether that be some kind of slick GUI or trying to support an environment or use case that very few will use. The focus should be to run on traditional compute (servers, workstations) solving "real" problems.

# Non-Goals

# Performance

LogBus will probably lose most performance contests. However, it is performant enough to handle many use cases. The struggle of resisting the urge to port to Rust is real 🫠

# Time

Events make their way through the pipeline using an EventEmitter which is one limiting factor. The other being V8's single thread of execution by default. While spawning multiple workers is a way to leverage multiple CPU cores, having multiple threads operating on the same EventEmitter is considered too complicated to be worth the effort. Launching multiple LogBus processes is the recommended approach for maximizing CPU cores when that level of throughput is needed. More performant EventEmitter implementations and support for launching worker threads may be considered based on demand & developer bandwidth.

# Space

The memory story is currently pretty weak. Memory usage will be a function of the pipeline definition and events per second (EPS). As of late 2025, a simple pipeline at low EPS consumes roughly 100MB of resident memory while a more complicated pipeline with an EPS O(hundreds) consumes roughly 200MB.

# Secure by Default

As with most things in life, context is everything. LogBus leaves security considerations up to the user. While it should support best practices, it should not impose them on its users. While there is support for backing off when backpressure is detected, there is no circuit breaker support. Some things to be mindful of when defining your pipeline:

• Some plugins (eg js) will eval() functions. Make sure that is trusted.
• Some plugins (eg read-http) will listen on a port. Lock that down as needed.
• Some plugins (eg send-email) could easily flood a downstream system. Pay special attention to how sinks are configured.