At this stage, you've gotten a good taste of how to whip up a file-handling controller, and hitch it to a service that reads and writes files to disk. But the question that often arises is why do I need to do this reactively?

With imperative programming, the process of taking inputs, building intermediate collections and other steps often leaves us with lots of intermediate states--some of it potentially blocking in bad places.

Using the functional style as we've explored so far moves away from the risk of inefficiently building up this state, and switches to building a stream of data instead. And Reactor's operations let us have one stream feed another in lots of different ways. We can merge streams, filter streams, and transform streams.

When we engage in reactive programming, the level of abstraction moves up a level. We find ourselves focusing on creating tiny functions to perform various operations, and chaining them together. We think more along integration of the items in our streams rather than the lower-level implementation details.

By building up these flows of chained operations, tying inputs to outputs, Reactor is able to do the heavy lifting of invoking code when needed, and requesting/releasing resources as effectively as possible.

Additionally, by having an inherently asynchronous, non-blocking nature, our framework of choice (Reactor) is able to manage talking to the scheduler for us. We can focus on what happens during the flow while the framework handles when it happens.

For yet another metaphor to describe reactive operations chained together, imagine a train with lots of cars. Each car is a different operation to be applied to our data, and we can easily see the order in which things must happen. We can carefully lay out each car with its defined purpose, but nothing moves until the locomotive moves. And then, the whole chain of cars moves as expected. Adding/removing/inserting cars is the nature of building a reactive data flow.

To summarize, reactive programming helps us in the following:

• Avoid inefficient, intermediate state
• Focus on building streams of data
• Gives us ability to merge, filter, and transform streams of data
• Focus on what happens at each step while Reactor decides when