How Should Scripting Work in a Low-Code Platform?

When building a low-code platform, it's crucial to determine where complex business logic should reside. While low-code platforms aim to simplify application development, there are scenarios where scripting becomes necessary. However, scripting should not be a free-for-all approach to adding arbitrary code. Instead, it should provide a controlled environment for handling complex logic that cannot be easily expressed through configuration alone.

Low-code platforms offer a range of capabilities like field validation, conditional form behavior, approval workflows, and automation orchestration. When used effectively, these features can handle the majority of common requirements. However, some logic remains challenging to express elegantly through configuration. Examples include complex quotation calculations, signing requests to external APIs, data cleaning across multiple tables, generating identifiers based on historical rules, transforming imported data, and validating purchase lines against maximum material prices.

If every scenario were to be converted into visual configuration, the configuration system would become increasingly complex. Each new option would require extensive UI, expressions, validations, compatibility rules, boundaries, and performance considerations. This could ultimately lead to a situation where the platform creates a configuration language that is more challenging to understand than code itself. This outcome would defeat the purpose of low-code development.

The key is to strike a balance. Scripts should provide a mechanism to carry out logic that the configuration system would otherwise struggle to handle effectively. They should not replace the entire business process but serve as a controlled escape hatch when necessary. The division of responsibility should be clear: automation handles orchestration, while scripts handle complex logic.

Automation should query data, invoke scripts to perform calculations or transformations, and then use the results to update records, send notifications, and return responses. Scripts should not consume the entire business process. Instead, they should behave like calculation, validation, or transformation nodes within automation. This approach preserves the flexibility of code while maintaining the visual governance provided by automation.

When it comes to scripting environments, there are server-side and client-side scripts to consider. Server-side scripts run on the platform's backend and are suitable for business logic such as querying and writing data, calling external services, performing complex calculations, processing batches, and generating structured results.

JavaScript is a practical language for server-side scripting due to its familiarity among frontend and full-stack developers. Server-side scripts run in isolated environments, ensuring that one application's script context cannot leak into another. They are particularly useful for business processing behind APIs and complex calculations that become cumbersome in visual automation.

On the other hand, client-side scripts are better suited for interface behavior. They can handle field calculations based on user input, update local page state, create custom controls with lightweight logic, and provide instant feedback. However, client-side scripts should have clear boundaries to prevent them from becoming permission backdoors.

They should not be allowed to access data that the user cannot see or modify protected fields directly. Client scripts should focus on interaction and lightweight calculations, returning persistent data and business state changes to server-side scripts, automation, or governed platform actions.