What makes "Reactive Programming" so Powerful?
How does "reactive programming" streamline the work of building business logic?
Reactive programming entails the use of "smart object events." Objects are "smart due to the business logic encoded into event handlers associated with table events like "insert," "update" and "delete." "Smart objects" are used in familiar technologies such as
Lots of it - often half the application. But business needs to move faster. Programming tools are useful, but these provide incremental improvements - we need order of magnitude advances.
Let’s examine the current state of the art - Smart Object Events - in light of a familiar sample. Let’s consider a database of customer, orders, items and parts, and explore how we provide Check Credit defined like this:
The knowledge gained through this analysis is very valuable, since it applies to other transactions beyond Place Order, such as Pay Order, Delete Order, Change Order, Change Item and so on. Re-use at the abstract level.
Objects are “smart” per the business logic coded into event handlers associated with table events like insert, update and delete. This is a familiar and powerful architecture, provided in a number of different technologies such as database triggers, ORM objects, or REST objects.
While the encapsulation value is very high (all changes invoke the event handler logic), the expressive power is remarkably low. Just the code for a single qualified sum such as the balance takes pages of code, mainly for dependency management (change detection and propagation), and sql handling (including caching). While that may the best current alternative, we need a technology designed to address dependency management.
Smart Objects contrast to Fowler's Anemic Data Objects, which do not enforce logic.
In reactive programming, you define the meaning of a variable (e.g., A = B + C). Unlike procedural code, this stipulates that subsequent changes to B or C are watched - if changed, A is recomputed, which may of course chain to variables dependent on A.
Reactive Programming is an automation of the Observer Pattern used to manage dependencies. It most successful application is the spreadsheet, where cell formulas are Reactive Expressions that provide enormous power yet are very simple.
This technology maps naturally onto database transaction processing by assigning Reactive Expressions to database columns. Recall our logic defining the customer balance as the sum of the unpaid order totals. It's not a free-standing SQL statement: it defines the meaning of your data.
When you declare the expressions, the Logic Engine's scans it for dependencies, establishing "watch and react" links from the dependent data to the referencing data. Our customer balance depends on the Order.amount_total, Order.paid, and Order.customer_name (the foreign key). It also depends on the state transition of the order - whether it is being inserted, updated or deleted.
And these dependencies chain, as shown here. So our little 5 line spec essentially wires virtually every field in this database.
When a watched field is updated (or inserted or deleted), the dependent field is re-calculated.
That is a significant statement. In the case of our customer.balance rule, this means that this one statement obligates the system respond to all of the following:
Even more powerfully, logic constraints can chain, since one constraint can reference the value of another constraint. So, there are dependencies between constraints.
In our example above, the Customer.balance refers to the Purchaseorder.amount_total, itself defined by a constraint. So, a change to the Lineitem.amount affects the Customer.balance.
Let's further explore the implications of this declarative approach to logic using Constraint and Reactive Expressions.