Reactive Programming

From NovaOrdis Knowledge Base
Jump to navigation Jump to search

Internal

Overview

The underlying principles of reactive applications inform overall system design.

Message-driven runtime. One of the key elements to reactive programming is being able to execute tasks asynchronously. Reactive runtimes use an event loop or a shared dispatcher infrastructure based on a thread pool. This allows sharing threads, which are expensive resources, among cheaper constructs: actors. It can be seen as a multiplexing technique. This approach allows for a pattern where we can afford to have one actor per a specific entity in the system, where entities can be quite large in number. State synchronization issue. Reactive applications must avoid blocking the event loop, thus making a specific thread (which can sometimes be the only thread in the system) unavailable. When a reactive application performs such an operation, the thread must be given back to the pool so it can be allocated to other "actors". In this context, blocking is not evil, but needs careful management. Reactive frameworks deal with this issue by isolating the blocking behavior on a different thread pool, that is dedicated for such operations. This technique is called "sandboxing" or "bulkheading".

Programming model.

Resource utilization. Responsiveness is achieved by efficiently using the hardware, by using asynchronous APIs and programming techniques. Better resource utilization is a component of scalability.

Decoupling promotes scale-out, as various components can be scaled independently. Asynchronous communication is key to achieve decoupling. It separates the lifecycle of the request initiator from the lifecycle of the request target.

Same reactive principles apply to the local (application) level of the system and to the distributed system, allowing composing a distributed system from reactive building blocks from bottom up.

In the academic world, "reactive" stands for "functional reactive programming" (FPR), or "functional reactive activation". This technique is very useful for reactive systems.

Back-pressure. When the system uses synchronous API, it is "automatically" back-pressured by the blocking operations. With asynchronous APIs, we may be in the situation of performing the logic more intensely and overwhelm some other slower downstream parts of the application or systems. The back-pressure (or flow-control) mechanism helps with this. TODO: https://doc.akka.io/docs/akka/2.4/scala/stream/stream-quickstart.html#back-pressure-in-action


Actors - a task is usually achieved in messaging-based systems by sending a fire-and-forget message that we want to run a job. We can include in that message a flag that we want to be informed about the progress, and we're done on the sending side. Once the job completes, we'll get a message back with its results. Use of actors allow a "own your own data" pattern, which allow them to avoid concurrent access to mutable state.

SynchronousVsAsynchronous.png

Scaling out - adding more machines. Scaling up - adding more powerful machines.

Reactive systems typically deal with failure by scaling out and replacing failed nodes with new healthy ones.

Reactive-oriented changes can be introduce in the code base using the Ivy Pattern.

Reactive Streams

An initiative around building concurrent and distributed systems that want to standardize an interop protocol around bounded-memory stream processing. It specifies a low-level interop protocol between various streaming libraries. Reactive streams have been incorporated in JDK JEP-266. TODO: https://medium.com/@viktorklang/reactive-streams-1-0-0-interview-faaca2c00bec

Streaming APIs

Bounded-in-memory processing. We never use more of the data in memory than we actually need. Bounded-memory pipelines. Bounded buffers.

TODO:

Reactive System Tenets according to the Reactive Manifesto

  • Responsiveness refers to the capability of the system to be consistently responsive to the user and never fail; it refers to the value brought by such systems.
  • Resilience is the capability of the system to self-heal, and refers to form in which reactive systems are delivered.
  • Elasticity is the capability of the system to scale out and up/ in and down across physical and cloud infrastructure refers to form in which reactive systems are delivered.
  • Message-driven refers to the means used to implement reactive systems. A message-driven system is powered by means of asynchronous, non-blocking communication. This enables first and foremost isolation.

Frameworks

Companies

TODO

Organizatorium

  • The benefits of reactive programming is that you can write code that reads closer to the business problem statement.
Retrieved from "https://kb.novaordis.com/index.php?title=Reactive_Programming&oldid=53016"