Service Overview

 
Espresso Logic, illustrated via a small sample application

Video »

Here we use a small but representative sample application to demonstrate how Espresso Logic enables you to eliminate a significant obstacle in building and running modern mobile applications – a product category that is known as Mobile backend as a service.

traditional-REST-JSON-Server

Mobile App demand continues to soar, driven by major trends such as BYOD.
REST/JSON Servers are the accepted approach for mobile app access to SQL data.

But servers are slow and complex to build, consisting of three projects shown here.

Sure, there are tools and frameworks to reduce the coding, but these are complex and time-consuming. And worse, they don’t address Business Logic and Security, which can comprise up to half the effort.
So we pose the question:

What is the absolute fastest and easiest way to build a REST Server?

Ideal

The ideal solution embraces the vision that:

It should be no more difficult to build a system than it is to imagine it.

database-security-logic-API-to-REST/JSON

Here’s how such a system might look:

  1. Instant Server – Deploy a server just by pointing at a SQL database, and optionally defining some custom resources
  2. Logic Automation – Imagine directly entering the “cocktail napkin” specification.. and it runs!
  3. Security Automation – Add expressions that filter rows/columns for a specified role

This would result in amazing savings of time and money, and be so simple to use that it feels like magic.

1. Instant Server

So let’s move from the ideal to the real, here examining Espresso Logic.

Register Database

Since Espresso Logic is a service, there’s no installation / configuration hassles. To build a REST server, we simply sign-up with the Espresso Logic service, where we create a project and register our database connection parameters. And that’s literally all there is to it.

It’s all done through the browser, using the Logic Designer.

Once you have configured a project / database, you have a REST API.
The initial resources are the Base Tables of the configured database.

 

2. API

Single-table resources are great for admin apps, but multi-table apps require services to minimize latency and support more complex screens.

Custom Multi-Table Resources

Espresso-Logic-screens-custom-API

You can define Custom, Multi-Table Resources that deliver such data in a single JSON response. Simply select the tables. The system defaults the SubResource join (Customers / Orders) from the Foreign Key Constraints.
You can control which attributes are returned to the client, and their alias names. You can also define Resources using JavaScript.

Test in REST Lab

No need to write test programs – the Logic Designer provides a REST Lab where you can send retrieval and update requests to the server, and see the JSON response, here for the Multi-Table Resource OneCustomer.

Note that the JSON provides information for Optimistic Locking, Pagination, and Discoverability.

Client Ready

So, by just pointing at your database, and selecting a few tables, you have a complete REST API.

Test it with the REST Lab.

Client app development is fully enabled – in minutes.

Business Logic is the set of multi-table computations, validations, and actions (e.g., auditing, cloning, sending mail) performed during an update.

 

reactive-business-logic-programming-to-reduce-development-time

Why so much effort?

As much as half the app involves the Business Logic. Let’s see why by considering Place Order.
Analysis (the venerable “cocktail napkin spec” in the lower left) reveals we need to check credit – the balance cannot exceed the credit limit, where the balance is the sum of the unpaid order totals, which is the sum of the Line Item amounts, derived as the quantity times the parts’ price.

This is a nice clear requirements spec. But it represents quite a lot of business logic.

First, we must identify all the related Use Cases that must also respect these rules. If we miss one, serious bugs will result.

Each of these requires dependency management design: change detection, and propagation to dependent data. And optimizations to minimize / reduce SQLs. Pretty soon, the simple 5-line spec becomes 500 lines of code. Weeks of work to write, test, optimize, deploy, maintain, and document.

Not fast. Not simple.

11 Use Cases X Dependencies = 500 lines of code.
And yet, the requirements were so simple.

If only they were executable… that would be amazing.

 

Reactive Programming

And that is exactly what is provided by Reactive Business Logic. Your requirements are directly captured and enforced with automated Dependency Management. The executable cocktail napkin.

When REST updates are processed, your logic is automatically invoked, analyzed, optimized, and executed. You can imagine what this does for maintenance.
This screenshot shows all the logic required to supplant 500 lines of code. You can explore logic here.
Note especially the multi-table derivations, such as the customers’ balance. Such derivations can be chained – used in related logic (used by the credit limit check, uses the amount_total result). These are highly optimized to dramatically eliminate and simplify SQL access.

The Power of Reactive Programming

The contrast of “500 lines of code vs. 5 rules” is stark, but only part of the story:

  1. We did not write any code – not for request handling, database access, or business logic. But we can if necessary – logic is fully extensible using server-side JavaScript, so scales to complexity (e.g, a Bill of Materials explosion with 4 rules).
  2. We solved all the Use Cases – even though we targeted only Add Order. Re-use is automatic – and so is quality.
  3. Our logic is unordered – the system takes care of that through logic dependency analysis. This is repeated on every change, so maintenance is simple – just change the logic.
  4. We did not optimize our logic – that is also the system’s responsibility. So our logic is pruned based on actual changes, and SQLs are eliminated / optimized to reduce server traffic. As for ordering, these optimizations are repeated on each change.
  5. Our logic is transparent – even business users can read it and spot errors / omissions. Compliance can be verified. So we finally have a common business / IT language that is both transparent documentation and maintainable implementation. A corporate asset.

For Security, you define role permissions that filter table rows and columns, based on the user profile.

This security example is defined as follows:

espresso-logic-security-database-based-on-roles

To review:

  1. Security is specified by role/table filter expressions, not code
  2. It is automatically applied to all requests to that table
  3. You can drive security from user-context data, such as values in a user-specific database row

business-logic-design-server-automation

In this short overview, you’ve seen how to build a REST/JSON server for your SQL database. Your server can support mobile apps, as well as service calls from other computers – regardless of their language or architecture.

But you have far more than a server. You have a Smart Server that enforces security and complex, multi-table business logic. That means you have a safe and secure Public API.

Server creation was more a matter of specifying spreadsheet-like expressions than writing code. So, you are done in minutes rather than weeks. And you can change these expressions, with automatic activation.

Automation is the key, providing the speed and agility your business requires. And simple as a spreadsheet.

If you haven’t already signed up, this would be a great time to
sign up
. Start by executing the procedures shown here for your own database.

To learn more, check out the Evaluation Guide, and the documentation.