Rules offer the promise of accelerating backend delivery by an order of magnitude. That is a big promise. But rules are a new paradigm, so there are sensible questions:
- Complexity.How do rules address complex problems?
- Performance.Nothing matters if the system is slow. API Server automates best practices for performance.For more information about performance, see Performance.
- Debugging.Are rules a black box or can I address problems easily?
- Learning.Is the paradigm reasonable to learn?
This article addresses these questions.
In this article:
Verify the Prerequisites
Before you learn the rules, ensure that you have reviewed one of the following:
- You understand how rules operate.For more information about a description of how rules operate, see Reactive Logic Operation.
- You have watched the following Rule Operation video.
The Promise of Rules
The Check Credit example is a representative transaction, where a insert/update/delete affects multiple related objects.
- Correctness.Building correct code presents its challenges. Reactive programming addresses several of the inherent challenges of quality by automating control flow:
- Automatic Invocation.After you declare a rule, API Creator executes the rule for any use case. In this way, API Creator eliminates an entire class of corner-case bugs (the Customer Balance was not adjusted when the Order was re-assigned to a different account)
- Ordering.Execution is ordered by system-discovered dependencies.
- Maintainability.The same elements that promote correctness make reactive logic easier to maintain. Add/change rules and they execute in the proper order.
- Clarity.Removing the boilerplate change detection/propagation and SQL reveals the intent of the logic. Moreover, the logic is revealed in terms clear to business users. The result: Business users and IT speaking the same language. Logic can reduce the risk of requirement misunderstandings.
Address Complex Examples
You can address complex examples using API Creator:
- Provide logic not addressed by rules using events.You can provide logic that is not addressed by rules using the integrated event model. For example:if ("INSERT" != logicContext.initialVerb && row.amount_total != oldRow.amount_total) SysLogic.insertChildFrom("purchaseorder_audit", logicContext);For more information about the event model and how to create an event, see Event Rule Types.
- Rules reduce complexity.Ordering, dependency management, and automatic invocation inherently reduce complexity. A few simple rules can solve complex problems, in the same way that a few spreadsheet formulas can solve highly complex numerical problems.
For more information about viewing a series of use cases addressed with a few rules, see Logic Tutorial.
Rule and SQL Activity
API Creator provides a detailed log of all rule and SQL activity, including complete row state for each stage.
For more information about the log, see Debug.
Address problems with rules using the following approach.
Differences between Reactive Programming and Conventional Procedural Programming
The following are some observations about some fundamental characteristics that distinguish reactive programming from conventional procedural (Imperative) programming:
- No control flow
- API Server invokes rules per changes in referenced attributes.In conventional procedural programming, you must explicitly invoke object methods for them to execute. In reactive programming, the rules are similar to pipeline event, but are more granular. They react to a change in the referenced attributes.
- API Server orders rules by their dependencies.In conventional procedural programming, you order logic within a method or pipeline event. In reactive programming, API Server orders rules by their dependencies. When you alter the rules, for example, during maintenance or during iterative development, API Server adjusts the logic flow automatically per the new dependencies.
- Elimination of Boiler Plate codeIn conventional procedural programming, the bulk of your code is change detection, change propagation, and persistence handling (SQL commands). In reactive programming,Layer7 Live API Creatorautomates change detection, change propagation, and persistence handling. The previous logic is executable.
A Simple Validation Example
The following code snippet shows a simple example:
Customer Validation: return row.CreditLimit >= row.Balance
Orders Validation: return row.AmountTotal < row.Customer.MaxAmount
For more information about validation rules, see Validation Rule Type.
A Simple SUM Example
You can handle derived balances by adding another rule, a Sum rule type:
Customer Validation: return row.CreditLimit >= row.BalanceDerive Customer.Balance asSum(OrdersList.AmountTotal where ShippedDate === null)
The rule operands, again, are based on the schema;
OrdersListis a defaulted name, which is derived from to a foreign key relationship. These rules are fully executable. After you have created them, you do not need to worry with the details of calling them, ordering them, reading/writing data. API Creator addresses these rules with system RESTful update processing.
For more information:
Rules Automate Logic Patterns
The Simple Sum example illustrates a key to using rules: they work in combination to achieve a desired behavior.
Validate a Sum
This simple "Balance < CreditLimit" example illustrates one of the most common logic patterns: validating a rollup/constrain derived result. Other examples of the pattern:
- Rollup employee salaries to department, constrain to budget.
- Rollup departments, constrain to budget.
- Rollup Student Course Credit, constrain to max for student, max for course.
- Compute Product Price from the sum of the Component Parts (nested).
- Compute Event GiftsAmount from sum of EventGifts.
Existence Checks: validations on [qualified] counts
For example, order must have items and department must have employees.
Scale to Complexity
- Copy.Invoke copy, including deep copy, for patterns like auditing or cloning. The copy pattern automates a Bill of Materials explosion.
- Allocation.Allocate an amount to a set of recipient, such as a bonus to department employees or a payment to outstanding orders.