Instant App Backends with API and Logic Automation

I saw career advice recommending against front end development --?"you're dependent on APIs - they're late, so front end dev is always under pressure." ?Sad, but a story I hear often. ?The problem is that framework-based API development is slow and complex.

I also hear snide remarks that "if you don't like the answer from UI #1, try UI #2". ?It's because the?logic is often not shared in the server, but replicated on UI controllers.

Slow framework-based development and unshared logic are really backend problems, affecting dev teams and business agility. ?Now, there's a solution.

API Automation enables you to create backends instantly - ready for client app dev. ?Logic Automation addresses the logic under the API with rules that are 40x more concise than code. ?API Logic Server, an open source Python project, makes this possible. ?Here's how.


API Automation: 1 Command to Create Database API

API Automation means you create a running API with 1 command:

? ApiLogicServer create --project_name=ApiLogicProject \
? ? ? ? ? ? ? ? ? ? ? ? --db_url=postgresql://postgres:p@localhost/nw
        

API Logic Server ?reads your schema, and creates an executable project that you can customize in your IDE.


JSON:API - client app dev ready

With zero framework-based coding, you now have a running API (and an Admin Web App not shown here):

Instant API, With Swagger - Ready for App Dev


The API follows the JSON:API standard. ?Analogous to GraphQL, JSON:APIs are self-serve: front end developers request the fields and related data they want, as shown above using automatically created Swagger. ?Swagger provides the Request URL you can paste into your client code.

JSON:API frees the client app developers from depending on server custom API development.

Contrast this to traditional API development, where:?

  1. API requirements must be specified in advance?
  2. Frameworks do not provide API Automation. ?It takes weeks to months of framework-based API development to provide all the features noted in the figure above. ?

JSON:API creation is automated with 1 command; self-serve enables app dev, instantly.

This is also a great way to get instant integrations - click here.


Full Access to Underlying Frameworks: Custom Endpoints

The create command creates a full project you can open in your IDE, and customize with all the power of Python and frameworks such as Flask and SQLAlchemy. ?This enables you to build custom APIs that bundle multi-row updates into 1 transaction. ?

Here's the code for an endpoint to post an Order and OrderDetails:

Python for a custom endpoint, with automated mapping


The entire code is shown in the upper pane. It's only around 10 lines, because:

  1. Pre-supplied mapping services?automate mapping between dicts(request data from Flask) and SQLAlchemy ORM row objects. ?The mapping definition is shown in the lower pane.Mapping includes lookup support, so clients can provide product names, not IDs.
  2. Business Logic (e.g. to check credit) is partitioned out of the service (and UI code), and automated?with?rules (shown below).

Implement custom endpoints, using Python and standard frameworks.


Logic Automation: Rules are 40X More Concise

While our API is executable, it's not deployable until it enforces logic and security. ?Such backend logic is a significant aspect of systems, often accounting for nearly half the effort. ?It's the iceberg under the surface.


Frameworks have no provisions for logic. ?They simply run code that you design, write and debug.

Logic Automation means you declare rules using your IDE, adding Python where required. ?With keyword arguments, typed parameters and IDE code completion, Python becomes a Logic DSL (Domain Specific Language). ?Let's explore declaring rules for security and logic.

Declaring Security Logic

Here is a security declaration that limits customers to see only their own row:

Grant(? on_entity = models.Customer,
? ? ? ? to_role = Roles.customer,
? ? ? ? filter = lambda : models.Customer.Id == Security.current_user().id,
? ? ? ? filter_debug = "Id == Security.current_user().id") ? ? # customers can only see their own account        

Grants are typically role-based as shown above, but you can also do global grants that apply across roles, here for multi-tenant support:

GlobalFilter(? ?global_filter_attribute_name = "Client_id",? # try customers & categories for u1 vs u2
? ? ? ? ? ? ? ? roles_not_filtered = ["sa"],
? ? ? ? ? ? ? ? filter = '{entity_class}.Client_id == Security.current_user().client_id')        
Security is factored out of front end code, shared in the server.

Declaring Transaction Logic

Declarative rules are particularly well-suited for update logic. ?For example, imagine the following cocktail napkin spec to check credit:


The rule-based implementation below illustrates that rules look like an executable design:

Declaring Rules, Extending with Python


Rules operate by plugging in to SQLAlchemy (ORM) events. ?They operate like a spreadsheet?to automate multi-table transactions:

  1. Automatic Invocation / Re-use:?rules are automatically invoked depending on what was changed in the transaction. ?This means they are automatically re-used over transaction types:For example, the rules above govern inserting orders, deleting orders, shipping orders, changing Order Detail quantities or Products, etc... about a dozen Use Cases.Automatic re-use and dependency management result in a remarkable 40x reduction in code; the 5 rules above would require 200 lines of Python (click here).
  2. Automatic Multi-Table Logic: rules chain to other referencing rules, even across tables. ?For example, changing the OrderDetail.Quantity triggers the Amount rule, which chains to trigger AmountTotal rule. ?Just like a spreadsheet.
  3. Automatic Ordering:?rule execution order is computed by the system, based on dependencies.This simplifies maintenance - just add new rules, and you can be sure they will be called, in the proper order.
  4. Automatic Optimizations:?rules are not implemented by the Rete algorithm - they are highly optimized for transaction processing:Rules (and their overhead) are pruned if their referenced data is unchangedSum/count maintenance is by 1 row "adjustment updates", not by expensive sql aggregate queries.

Spreadsheet-like rules are 40X more concise. Declare and Debug in your IDE, Extend With Python.


Events - e.g., send email, Kafka messages

Rules automate in excess of 97% of your database transactional logic. ?But not all.

To complement rule-based agility, the system also supports events where you can implement standard Python code. ?You have all the power of Python libraries, e.g., for sending Kafka messages or email. ?The example above illustrates sending a Kafka message when an Order is posted.


Logic Partitioning - reuse, simplify client app dev

Logic execution is on the server. ?That means it can be shared:

  • By multiple front end apps
  • By non-UI services

So, for example, our credit check logic is shared between client apps and the B2B service, automatically.

This addresses a common - and serious - architectural error, where "fat clients" implement business logic. ?This is hard to share between client apps, and impossible to share with services.

Logic partitioning also reduces - significantly - the code required in client apps.?


Parallel Client / Server Development

Logic automation also enables client and server development to proceed in parallel. ?As server developers implement logic, the same APIs simply provide more functionality, within the same interface. ?From the client perspective, the API is available immediately, and remains unchanged. ?

This is in stark contrast to traditional framework based development, where client app dev is serialized, after lengthy API implementation.


Summary: Remarkable Business Agility

So there you have it - remarkable business agility to unblock and accelerate front end app dev. ?This is enabled by:

  • API Automation: create an executable API with 1 command - ready for App Dev
  • Logic Automation:declare logic and security in your IDE with spreadsheet-like rules40X more concise than codeparallel client and server app devshared between client apps and services
  • Standards-based customization: Use Python, Flask and SQLAlchemy - develop in your IDE

Compared to framework-based development, you might say that API and Logic Automation are a horse of an entirely different feather.


That said, frameworks are great for customizing what is not automated. ?So: automation for business agility, standards-based customization for flexibility.

API Logic Server is free and open source. ?You can install it and explore running code for these examples - click here.

Tyler Band

AIMicroservice Consulting

9 个月

API Automation, a new dev category

回复

Very nicely presented Val. I am totally onboard! However, I need a cluster of these APIs across multiple databases and schemas representing various parts of my business. How can I pull them together with Api Logic Server?

回复
Woodley B. Preucil, CFA

Senior Managing Director

9 个月

Val Huber Very interesting. Thank you for sharing

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了