How Alibaba’s Low‑Code Engine Enables Powerful Debugging for Non‑Frontend Users

Overview

Low‑code has become popular for its development efficiency, but it introduces many hidden logic issues. Existing low‑code platforms lack user‑oriented debugging, forcing non‑frontend users to rely on platform support or browser tools, raising the cost of using low‑code.

Business Background

To lower the cost of using low‑code platforms, a debugging capability tailored for low‑code is needed.

Technical Challenges

The solution must provide basic debugging for most low‑code platforms while accommodating diverse user habits and learning curves, and also allow extensible customization for different platforms.

Technical Details

The architecture uses a layered design (Client, Server, Protocol) to unify protocols with the low‑code engine and support high customization. Features such as log viewing, error‑code location, element inspection, and data‑source viewing/modification were built. In one internal platform, the debugging tools reached 300 active users, 10% of total MAU, and significantly reduced support tickets.

Low‑Code Engine Introduction

The Low‑Code Engine is an extensible framework for building low‑code platforms, jointly released by Alibaba’s terminal committee and DingTalk YiDa. It provides a standard designer and simple extension capabilities.

Open source: https://github.com/alibaba/lowcode-engine

Website: http://lowcode-engine.cn/#/

Low‑Code Debugging Background

In an internal low‑code platform with ~4,000 monthly active users, only 30% are frontend developers; the rest are non‑frontend staff who rely heavily on two full‑time frontend support engineers, handling over 400 tickets per month. High support cost and steep learning curve hinder broader adoption.

High support cost : Non‑frontend users depend on support staff.

High learning barrier : Even with support, non‑frontend users face a steep learning curve.

Low‑Code Debugging Capability Construction

When a page contains an error expression, the preview shows a generic error that is hard to locate. The debugging tool provides three main abilities:

Visually view error details.

Locate the code responsible for the error.

Guide users on how to modify the code to fix the issue.

Users see a noticeable error indicator, click it, and a debugging panel shows logs and context information, helping them understand and resolve the problem without support.

Errors are assigned unique error codes with contextual data (component ID, expression content). An error‑code management backend stores these details, and the log panel displays comprehensive information, enabling users to search by component ID and locate the problematic code.

For complex errors, the tool offers an external link to a documentation page with step‑by‑step solutions, and users can upload page logs (including JSON source and environment info) to reduce ticket handling time.

To address mismatches between design‑time and preview‑time expressions, a component inspection feature lets users click an element or tree node to view:

Computed display values.

Original configuration (e.g., expression source).

Available context (state, utils, etc.).

Additional panels include a data‑source panel (view/modify data) and a schema panel (view the JSON schema used for rendering).

Low‑Code Debugging Extension Capability

With nearly 200 internal low‑code platforms, many require customized debugging. The solution is to make debugging capabilities plugin‑based, allowing platforms to pick and combine plugins such as log debugging, element inspection, form debugging, or custom actions.

Pluginization : Each debugging feature is a plugin.

Base debugging plugins : Provide fundamental capabilities.

Extension plugins : Platforms develop custom plugins when base plugins are insufficient.

Developers first evaluate base plugins, then create custom plugins and combine them to form a tailored debugging suite.

Low‑Code Debugging Protocol

The protocol defines communication between rendering engines and debugging tools, abstracting three schema layers (top‑level, container, node) and auxiliary domains (Runtime, Overlay). It standardizes how debugging tools request schema data, execute expressions, and receive updates, regardless of the underlying rendering engine (React, Rax, future Vue).

A proxy agent mediates communication: the rendering engine notifies the proxy, which forwards protocol messages to the debugging tool, and vice‑versa, avoiding heavy modifications to the engine and keeping the proxy only in development environments.

Debugging Capability Practice

In the internal platform, the debugging tools serve 300 active users and reduce support tickets by about 10%. Simple issues like cross‑origin errors and expression mistakes have largely disappeared. Commercial platforms such as DingTalk YiDa have also adopted form‑specific debugging features.

Future work includes adding JS code inspection, data‑source request tracing, lifecycle monitoring, and providing various containers (Web, browser‑extension, mobile) to suit different user groups.

Support for multiple rendering engines (React, Rax, Vue) will be expanded to ensure broad compatibility.