Automation has value only in so far as there are no compromises in architecture (to integrate with existing systems), extensibility (to address elements that are not automated), and performance.  delivers on the best-practice patterns by revisiting relevant optimizations on each logic change.  performance remains at a high level over maintenance iterations the same as database management system (DBMS) optimizers maintain high performance by revising retrieval plans.
Automation has value only in so far as there are no compromises in architecture (to integrate with existing systems), extensibility (to address elements that are not automated), and performance. 
Layer7 Live API Creator
 delivers on the best-practice patterns by revisiting relevant optimizations on each logic change. 
Layer7 Live API Creator
 performance remains at a high level over maintenance iterations the same as database management system (DBMS) optimizers maintain high performance by revising retrieval plans.
This article details how 
Layer7 Live API Creator
 delivers enterprise-class performance.
In this article:
Minimize Client Latency
Modern applications might often be required to support clients that are connected through high-latency cloud-based connections. The following 
Layer7 Live API Creator
 characteristics minimize client-connection latency.
Rich Resources
When retrieving objects for presentation, you can define resources that include multiple types. For example, a customer with their payments, orders, and items. 
Layer7 Live API Creator
 delivers these resources in a single response message, so that only a single trip is required.
This requirement is not fully satisfied by views. You cannot update views and joins result in cartesian products when joining multiple child tables for the same parent. In our example, a customer with five payments and ten orders returns fifty rows. This requirement is unreasonable for the client to decode and present.
For more information about how to create a resource, see Customize your API.
Leverage Relational Database Query Power
Each resource/subresource can be a full relational query that you can send. You can send this query in a single trip to the REST server (and then database). Contrast this solution to less powerful retrieval engines, where the client must compute common requirements such as sums and counts. This solution drives the number of queries up 
fold, which can affect performance.
Large result sets can affect the client, network, server, and database. You can truncate large results, with provisions to retrieve remaining results, such as when the end-user scrolls, using pagination. Pagination can be a complex problem. Consider a resource of customer, orders, and items. If there are many orders, pagination must occur at this level, with provision for including the line items on subsequent pagination requests.
For more information about pagination, see Pagination.
Batched Updates
Network considerations apply to update and retrieval. Consider many rows that 
Layer7 Live API Creator
 retrieves into a client, followed by an update. Clients can send only the changes, instead of the entire set of objects, using APIs. Clients can also send multiple row types (for example, an Order and Items) in a single message using APIs. This results in single, small update message.
For more information about batched updates, see PUT.
Single Update/Refresh
Business logic consists not only of validation rules, but derivation rules. These derivation rules can often involve rows visible but not directly updated by the client. For example, saving an order might update the customer's balance. The updated balance must be reflected on the screen.
Clients typically solve this problem by re-retrieving the data, which is an extra client/server trip. And sometimes, it is difficult to program, for example, when the system assigns the order's key. 
Layer7 Live API Creator
 might know the computed key and might need to re-retrieve the entire rich result set.
Layer7 Live API Creator
returns the refreshed information in the update response. The client can show the computations on related data by communicating a set of updates with a single REST call and can use the response.
Server-Enforced Integrity Minimizes Client Traffic
An infamous anti-pattern is to place business logic in the client. Placing the business logic in the client does not ensure integrity, and causes multiple client/server trips. For example, inserting a new line item might require business logic that updates the order, the customer, and the product. If the client issues these, the result is four client/server trips when only one should be required.
Minimize Database Connectivity
You can minimize database connectivity by customizing the connection pool that is available for each data source, by having 
Layer7 Live API Creator
 reuse existing connections, and by avoiding the cost of initiating a connection to the database.
For more information about how to define the maximum number of database connections that 
Layer7 Live API Creator
 uses to create a pool of connections, see Database Connectivity.
Minimize Database Load
Layer7 Live API Creator
's logic engine minimizes the cost and number of SQL operations. The following 
Layer7 Live API Creator
 characteristics minimize database load.
Minimize Database Latency
If you must deploy databases in the cloud, and you want to minimize the database latency that you experience from 
Layer7 Live API Creator
, consider installing 
Layer7 Live API Creator
 in the same region as the connecting databases.
For more information about security considerations with cloud database connections, see Securing APIs.
Get Logic with Optimized SQLs using Pagination and Chunking  
Layer7 Live API Creator
's logic engine retrieves rows for multi-level table-based resources with a minimal number of SQL operations. 
For more information about 
Layer7 Live API Creator
 approach to retrieving rows on table-based subresources, see Define Table-Based Resource Types.
Update Logic Pruning Eliminates SQLs
API Server prunes (eliminates) SQL operations where possible. For example:
  • Parent Reference Pruning.
     API Server accesses parent rows by averting SQL operations if other (local) expression values are unaltered.
    For example, if 
     is derived as 
    attribute-Y * parent.attribute-1
     , API Server eliminates the retrieval for parent if 
     is unaltered.
  • Cascade Pruning.
     If you alter parent attributes that child logic references, API Server cascades the change to each child row. If the parent attribute is unaltered, cascade overhead is pruned.
    In the previous example, API Server cascades the value of 
     if it is altered.
Update Adjustment Logic Eliminates Multi-level Aggregate SQLs
Layer7 Live API Creator
's logic engine minimizes the cost of SQL operations. For example:
  • Adjustment.
     For persisted sum/count aggregates, 
    Layer7 Live API Creator
     adjusts the parent based on the old/new values in the child by making a single-row update. Aggregate queries can be costly when they cascade. For example, the customer's balance is the sum of the order Amount, which is the sum of each order's line item amounts.
  • Adjustment pruning.
    Layer7 Live API Creator
     adjusts only when the summed attribute changes, the foreign key changes, or the qualification condition changes. If none of these occur, it averts parent access/chaining.
Transaction Caching
Consider inserting an order with multiple line items. The following image shows the rules that are organized in the Check Credit topic for the 
 API sample. Per the logic that is shown in the following image, 
Layer7 Live API Creator
 must update, or adjust, the order total and customer balance for each line item:
 Screen Shot 2017-10-05 at 2.03.58 PM.png 
Layer7 Live API Creator
 retrieves these objects only once and maintains a cache for each transaction. All reads and writes go through the cache. API Server flushes them at the end of the transaction. This eliminates many SQL operations and ensures a consistent view of updated data.
Good performance dictates that data not be locked on retrieval. Optimistic locking typically addresses concurrency. API Server automates optimistic locking for all transactions. The automation can be based on a configured timestamp column, or, if a timestamp is not configured, a hash of all resource attributes.
Layer7 Live API Creator
 automates transaction bracketing. It bundles PUT/POST/DELETE requests (which might be comprised of multiple roles) into a transaction, including all logic-triggered updates.
GET: Optimistic Locking
A well-known pattern is optimistic locking. Acquiring locks while viewing data can reduce concurrency. 
Layer7 Live API Creator
 does not acquire locks while it processes GET requests. API Server ensures that updated data has not been altered since it initially retrieved the data.
For more information about optimistic locking, see optimistic concurrency control on Wikipedia.
PUT, POST, and DELETE: Leverage Database Locking and Transactions
Layer7 Live API Creator
 locks update requests using database locking services. Consider the following cases:
  • Client updates.
     In accordance with optimistic locking, 
    Layer7 Live API Creator
     ensures that client-submitted rows are not altered since retrieval. It write-locks the row using a timestamp, or (if one is not defined) by a hash code of all retrieved data. This strategy means that it does note require a timestamp. 
    Layer7 Live API Creator
     completes this process as the first part of the transaction. It detects optimistic locking issues before it incurs SQL overhead.
  • Rule chaining.
    Layer7 Live API Creator
     read locks the rows that it processes in a transaction as a consequence of logic execution, such as adjusting parent sums or counts. 
    Layer7 Live API Creator
     acquires write locks at the end of the transaction, during the "flush" phase. 
    Layer7 Live API Creator
     could have acquired and released other transactions' read locks between the time of the initial read lock and the flush.
Server Optimizations
The following 
Layer7 Live API Creator
 characteristics illustrate how API Server promotes good performance.
Load Balanced Dynamic Clustering
Cloud-based installations of 
Layer7 Live API Creator
 on AWS Elastic Beanstalk provide services for dynamic auto-scaling to address increased load. Each server is stateless and 
Layer7 Live API Creator
 load balances incoming requests over the set of clustered servers.
For more information about auto-scaling and dynamic clustering, see Install on Amazon Web Services Elastic Beanstalk.
Meta Data Caching (Logic and Security)
API Server processes requests into a transaction request by reading the specified logic and security information. It persists the transaction cache over transactions until you alter your logic. For example, inserting an order with five 
 results in an order and a customer adjustment.
Direct Execution (No Code Generation)
Reactive logic is more expressive that procedural code. Compiling logic into JavaScript would therefore represent a performance issue. 
Layer7 Live API Creator
 executes your rules directly and does not compile them into JavaScript.
For more information about reactive logic, see Reactive Logic.
View SQL Performance 
Transparent information about system performance is an important requirement. You can view the logs of SQL and rule execution. You can also obtain aggregate information.
For more information about how to view the logs and how to obtain aggregate information, see the View Logging Information.