From Sequential Bottlenecks to Reactive Solutions: A Programming Journey

The Problem Every Programmer Faces

add(5, 3)      # Wait for addition
square(7)      # Wait for squaring  
sum(1:100)     # Wait for summation

This works, but creates a fundamental bottleneck: each function blocks the next, even though they're completely independent. Your program wastes time waiting when it could be working.

The Reactive Insight

What if instead of waiting for results, you could say: "Here's the work to do, and here's what to do when it's finished"? This is the core insight of reactive programming—transforming blocking operations into non-blocking ones through callbacks.

Building the Solution in Softanza

Let's solve this step by step, transforming our blocking problem into a reactive solution:

# Step 1: Initialize the reactive system
oRs = new stzReactive()
oRs {
    Init()  # Connect to libuv event loop
    
    # Step 2: Define our functions (same logic, no changes needed)
    f1 = func x, y { return x + y }
    f2 = func x { return x * x }
    f3 = func arr { 
        sum = 0
        for i = 1 to len(arr) sum += arr[i] next
        return sum
    }
    
    # Step 3: Transform functions into reactive versions
    Rf1 = MakeReactive(f1)
    Rf2 = MakeReactive(f2) 
    Rf3 = MakeReactive(f3)
    
    # Step 4: Queue all work with success handlers
    Rf1.CallAsync(
        [5, 3],                                   # Parameters
        func result { ? "Addition result: " + result }, # What to do when done
        func error { ? "Addition error: " + error }     # What to do if it fails
    )
    
    Rf2.CallAsync(
        [7],
        func result { ? "Square result: " + result },
        func error { ? "Square error: " + error }
    )
    
    Rf3.CallAsync(
        [1:100],
        func result { ? "Sum result: " + result },
        func error { ? "Sum error: " + error }
    )
    
    # Step 5: Execute everything in parallel
    Start()
}

# Output (in any order):
# Addition result: 8
# Square result: 49  
# Sum result: 5050
# Executed in 0.01 second(s)

What Just Happened?

The Transformation Process

1. System Setup: stzReactive() provides the infrastructure for non-blocking operations
2. Function Wrapping: MakeReactive() doesn't change your logic—it adds async capabilities
3. Callback Pattern: Instead of result = function(params), you use function.CallAsync(params, successHandler, errorHandler)
4. Parallel Execution: Start() processes all queued operations simultaneously

The Execution Flow

Traditional:  f1 → wait → f2 → wait → f3 → wait
Reactive:     f1, f2, f3 → all execute together → handlers called as they finish

Behind the scenes, libuv's thread pool picks up your functions and runs them in parallel. As each completes, its result queues back to the main thread where your success handler executes.

The Paradigm Shift

You've moved from imperative waiting ("do this, then this, then this") to declarative handling ("when this is done, do that"). Your program never blocks—it describes what should happen and lets the reactive system coordinate the execution.

Key Benefits Realized

• Concurrency: All three operations run simultaneously
• Responsiveness: Main program never freezes waiting
• Scalability: Adding more operations doesn't slow down completion
• Error Isolation: Each operation has its own error handling

The same logical operations that took sequential time now complete in roughly the time of the slowest individual operation—a dramatic efficiency gain through the power of reactive programming.

Cite

Mansour Ayouni. "From Sequential Bottlenecks to Reactive Solutions: A Programming Journey". Softanza narrations, 2025. https://mayouni.github.io/stzsite/en/narrations/stzreactive-from-sequential-bottlenecks-to-reactive-solutions.html

Not run: its code does not load as written. The article is published as written; its blocks are illustrations. The code of the articles is Haro code. Where an article was written before the language took its present name, the name was changed and nothing else. Genre, area and series read from the file's name, the year from its first commit: derived, until the article carries its own header. The file on GitHub(opens in a new tab)