Understanding Low-Code Implementation: Principles, Frontend Rendering, Backend Storage and Workflow
This article explains the core principles of low‑code platforms, showing how visual (declarative) editing distinguishes low‑code from traditional code, and reviews various frontend and backend implementation schemes—including JSON‑to‑React rendering, storage strategies, JavaScript logic, and workflow engines—while highlighting their advantages and limitations.
Low‑code platforms rely on visual editing, which is only possible when the underlying implementation uses declarative code; this makes the ability to edit a UI or data model visually the essential feature of low‑code.
Declarative code describes the final result without specifying how to achieve it, while imperative code focuses on step‑by‑step execution. For example, a red block can be created declaratively with HTML+CSS:
<div style="background:red; height:50px">
or imperatively with the Canvas API:
const ctx = canvas.getContext('2d'); ctx.fillStyle = 'red'; const rectangle = new Path2D(); rectangle.rect(0, 0, 100, 100); ctx.fill(rectangle);
Declarative languages such as HTML+CSS, SQL, Kubernetes YAML and NGINX configuration share benefits like ease of learning, visual editing support, performance optimisation and portability, but they also suffer from domain‑specificity, limited flexibility, debugging difficulty and strong runtime dependencies.
In the frontend, low‑code is often realised by converting a JSON description into a React component tree. The open‑source amis framework does this by mapping JSON like:
{ "type": "page", "title": "页面标题", "subTitle": "副标题", "body": { "type": "form", "title": "用户登录", "body": [{ "type": "input-text", "name": "username", "label": "用户名" }] } }
into a hierarchy of React components that render the final HTML markup:
<page title="页面标题" subTitle="副标题"> <form title="用户登录"> <inputtext name="username" label="用户名" /> </form> </page>
Backend low‑code faces three main challenges: custom data storage, business‑logic execution and workflow orchestration. Five storage schemes are discussed:
Direct relational‑database DDL generation (e.g., ALTER TABLE 'blog' ADD 'title' varchar(255) NULL; ).
Document databases such as MongoDB, where a collection is created per custom table.
Row‑instead‑of‑column meta tables (e.g., WordPress wp_postmeta ).
Meta‑information plus wide tables with pre‑reserved columns (500‑column example).
Single‑file storage used by "no‑code" Excel‑like tools.
For backend logic, many platforms embed JavaScript; a typical traversal helper is:
function JSONTraverse(json, mapper) { Object.keys(json).forEach(key => { const value = json[key]; if (isPlainObject(value) || Array.isArray(value)) { JSONTraverse(value, mapper); } else { mapper(value, key, json); } }); }
Workflows are stored as directed graphs; a minimal example contains three nodes (start, approve‑task, end) and two edges, which the engine uses to determine the next node based on the current state.
The article concludes that low‑code is fundamentally declarative, making it easy for UI construction but limited for complex abstract logic, and that future platforms will diverge into "zero‑code" solutions with high usability but low flexibility, and "professional‑dev" solutions that retain flexibility at the cost of higher complexity.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.