Instant App Backends With API and Logic Automation
See how API Automation unblocks client app dev with instant APIs. Logic automation reduces client code and promotes sharing with unique spreadsheet-like rules.
Join the DZone community and get the full member experience.
Join For FreeI saw career advice recommending against front-end development — "you're dependent on backend APIs — they're always late, putting front-end dev under severe pressure." Sad, but it's 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 is 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: One Command To Create Database API
API Automation means you create a running API with one 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):
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:
- API requirements must be specified in advance
- 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 one transaction.
Here's the code for an endpoint to post an Order and OrderDetails:
The entire code is shown in the upper pane. It's only around ten lines because:
- Pre-supplied mapping services automate the 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.
- Mapping includes
- 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 seeing 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 and 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:
Rules operate by plugging into SQLAlchemy (ORM) events. They operate like a spreadsheet to automate multi-table transactions:
- 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 remarkable40x reduction in code; the five rules above would require 200 lines of Python (click here).
- 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 triggerAmountTotal
rule. Just like a spreadsheet. - 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.
- 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 unchanged
- Sum/count maintenance is by one 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 emails. 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:
- 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's 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 one command — ready for App Dev
- Logic automation: Declare logic and security in your IDE with spreadsheet-like rules
- 40X more concise than code
- Parallel client and server app dev
- Shared 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.
Opinions expressed by DZone contributors are their own.
Comments