Docs‎ > ‎Logic Designer‎ > ‎Live Logic‎ > ‎

Reactive Logic

A somewhat whimsical look at Reactive Logic.

Needed: the Executable Cocktail Napkin

For decades, business executives have been bewildered why a 5 line specification - that could almost be loaded directly into a spreadsheet - takes 10 days to program?  And well they should.  For database apps, these specs represent up to half the effort.  We are talking billions.

The difference is Reactive Programming

The answer lies in the question: how is a spreadsheet so different from a conventional computer program?  The answer is Reactive Programming (a branch of declarative programming).

A spreadsheet is based on this concept.  All the references in your spreadsheet formula are detected - when a referenced cell changes, the referencing cells "react"" and are recomputed.   Automatically.

But a conventional program is imperative: all the "what has changed, who depends on that" logic is the programmer's job.  And this dependency management is gigantic: it's how a 5 line spec becomes 500 lines of code.  To design.  To build.  To Test.  To Maintain.  Until Death do you part.

Reactive Programming on the Front End

In addition to the Spreadsheet use, Reactive Programming is attracting a good bit of attention as an approach for simplifying client programming (<<references>>), many arising from Microsoft Rx.  NETFLIX

Reactive Programming on the Back End

So, Prof Higgins wise (and often-misquoted) advice applies: why can't a database be more like a spreadsheet?   In other words, apply Reactive Technology to database logic:  
  • bind reactive expressions to compute a database column (e.g., customer.balance := sum(purchaseorderList.amount_total)
  • validate row in a database table (e.g., customer.balance <= customer.credit_limit)
The database schema defines the valid expression operands.

What's exciting about the database application of RP is that it is a well-bounded problem, so becomes much simpler than general purpose RP.  Events (database transactions) are simpler (transactions are inherently serialized), you don't need to set up Observables (they can be set  up automatically by parsing the expressions), or worry about how to integrate it into a programming language.  It really does make your database behave like a spreadsheet.

The Executable Cocktail Napkin

And that, it turns out, is the cocktail napkin.  An executable specification - maintainable code for IT, transparent documentation for the business.

The 500 lines of code are distilled away.  Programmers are empowered to operate at unprecedented speed, since the logic engine plays the role of the spreadsheet for transaction processing, eliminating all the checking, the SQLs, the optimizations... the noise.

For Web 2.0

There's lots of ways to deliver a functioning runtime: integrate it into the DBMS, generate triggers, generate App Server code, etc.  But it's simple - we're in the Web 2.0 age, and RESTful servers are the consensus way for computers and mobile devices to talk.  It's fast, it's easy, and it's ubiquitous.

So, the ideal way to expose Reactive Database logic is as a RESTful server, managing SQL data residing in the cloud or on premise, watching the in=coming Put/Post/Delete requests (events).  One step further - make the RESTful server itself  a cloud-based service, so there's no install, no IDE.  Reactive Logic is specified via the Browser.

The economics are compelling: half the app gets built in a tenth the time.  Mobile, Web-app and SOA ready.  Maintenance is performed at the same level, so enjoys the same benefits - dealing with iterations is suddenly easy..  And it's transparent - the code is the documentation.