Making Low-Code Work

  • By Anjana Fernando
  • 15 Jul, 2021

As Marc Andreessen explained, to succeed in digital transformation, you need to also become a software development company. To gain an edge in efficiency and flexibility, companies must now look to build their own software, beyond merely buying generic software and tools.

However, this approach does come with its challenges. First, the shortage of skilled developers has driven businesses to seek out more participation from non-technical employees. This actually provides a benefit of allowing more domain experts to get involved in the software development process. So, how can we get this new group of people involved? The answer is low-code.

The low-code approach has generally been met with skepticism. Some state that it is not flexible enough for complex logic, has limited capabilities, and is not manageable in the long run. Let’s take a look at these concerns and see how a modern low-code platform can address them.

Concern #1: Low-Code Can’t Handle Complex Use Cases

Typically, when you say low-code, it means only the graphically modelling of logic, and it takes a longer time to define the actions and complex operations are hard to implement. This is actually true when you are only provided with a limited set of graphical operation toolsets and making a meaningful composition from those operations can become messy for complex use cases.

This is where we need to have low-code tools that will work at the correct abstraction layer for your operations. You need multiple layers of functionality—for example, if you are working on a high-level operation (such as simply integrating two software as a service [SaaS] systems for data sync) or if you have complex data validation logic that needs a specialized algorithm to be implemented, preferably in code. Ideally, we need a low-code environment where we can seamlessly switch between different layers of functionality to optimize the work you put in.

The above set of requirements would entail functionalities similar to the following in a potential low-code platform.

  • Connectors and Toolset: In order to connect to different systems, a low-code platform needs a rich set of connectors to access other systems. Also, there should be a vast range of typical built-in actions available, with different granularities of functionality. These are from conditional branching functionality to data mapping and transformation features in order to integrate effectively with different platforms.
  • Integration Patterns and Templates: A templating mechanism should be available in order for higher-level functionality to be implemented rapidly. This requires the availability of templates for most-often used scenarios in the platform, and also the ability to create custom templates. This way, a less technical user (i.e., no-code user) will be able to create useful scenarios using the existing templates without worrying about the inner-workings of the flows.
  • Graphical + Code View: If a graphical modelling environment could be supplemented with a pure code view, this would allow a developer to seamlessly switch between the graphical and the code view whenever needed. In this manner, a developer can build the higher-level constructs, such as services, APIs, and integrations with external systems. Then, when the developer needs to go into specific logic, which is best done in code, he or she can switch to the code view and fill in function definitions to get the work done. This reaffirms the approach of working at the correct abstraction level at the right time.

Concern #2: Low-Code Is Slow and Inefficient

The notion that low-code is slow has come from historical evidence, which shows that visual programming and modelling tools are slower compared to compiled programming languages. This has been generally true, where many DSLs (Domain Specific Languages) are configuration-based and mostly interpreted. You would rarely see a technology as such that is compiled down to direct machine-executable code. So, a low-code system, which is designed in this older approach, will actually be slow and inefficient when it comes to processing intensive work.

A modern low-code architecture can be implemented with this scenario in mind, where its execution flow language can be designed so that it behaves like a mainstream programming language—where the flows can be compiled and executed as an optimized binary. This is made easier when a graphical view is based on a directly mapped underlying code view. Also, the tooling must make sure that the graphical view will generate a clean code view without any bloat or any other extra code as hints to the graphical view. In order to implement this efficiently, we need a programming language that is built from the ground-up and supports both a visual and code view.

So, in a low-code platform, if we have an efficient programming language that is backing visual programming, it will still have the same performance characteristics of any other mainstream compiled programming language.

Concern #3: Low-Code is Hard to Test, Debug, and Maintain

In general software development, we follow a well-known lifecycle of design, development, test, deployment, and maintenance. And we have built specialized CI/CD tools and practices to help carry out this cycle as well. However, we have not seen low-code tools that follow a methodical approach to this lifecycle. Often, current low-code offerings force us to manually test in production after we build some flows. If we later do some updates in a flow, we cannot be sure if we introduced new regressions to the system or not, since we do not have an effectively automated testing system in place.

So, it’s critical that the low-code environment mirrors the typical software development lifecycle to have a scalable and maintainable system. We can’t use the same set of tools in the low-code environment, but we need some new innovations. Here are some possible techniques.

AI-Assisted Development

There were days when we used to edit source code in a plain text editor, and only when we did a compilation, we would see all the errors we get and then fix them one by one. We rarely do that now with code assist support we have in IDEs. We find errors and other potential warnings then and there, which makes a developer's productivity much higher. AI assistance can provide this IDE moment for low-code visual programming as well. For example, when programming with APIs, it is easy to make a mistake, such as placing an API call inside a loop. A proper approach would be to use a batch operation in an API if you need to make multiple similar operations at once. These are possible suggestions that can be provided by the platform.

AI can learn from others and basically do forward thinking for you, and provide smart suggestions for workflow actions, automatic data mapping, development-time performance analysis, and predictive maintenance for deployment time as well. Also, this functionality will be constantly improved by feeding AI/ML models the data generated from actions of the users as well. So, with AI support, the development speed can be accelerated for all levels of programmers.

Tests and Mocking

Test setups are rarely seen in low-code systems. The challenges arise mainly with the integration tests that are required for interacting with external systems, such as a SaaS provider. It may not be practical to use the real external systems for executing tests. This is where test mocks are useful for simulating external systems and APIs. A low-code platform should provide testing infrastructure with the ability to automatically create test mocks for provided external systems and network services. It is not enough to write the code with low-code, we need to write tests as well.

With this functionality in place, the platform can provide the ability to implement corresponding tests for the flows that are designed. This would make sure the full system is consistent, and for each update, the correctness can be verified.

Visual Debugging

If you are developing using a visual tool, it’s critical to have a visual debugger as well. If there isn’t an effective debugging option in a platform, it becomes a considerable setback for the developer’s productivity. The platform needs to support live tracing of requests, examining intermediate results, and their correlations with external requests. These features are mostly combined with the observability features as well.

Automated Observability

Observability is critical for any system’s well-being. If you cannot observe the internal state of your system, you have no idea about its performance and health. Generally, we add explicit code to our applications to add observability features. These can be information emitting for metrics, correlation data for distributed tracing, and logs for tracking certain events that happen in the system.

To get the basic observability functionality, a developer may end up littering the codebase with lots of code related to observability and may become a hindrance for managing the core business logic. So, a typical situation is, either a system does not implement observability fully, or else, the code of the system eventually becomes too complicated with the extra code that is required. But if we analyze the typical observability operations that are done, we realize that most of the information about activities can be derived automatically and can be engaged implicitly by the platform. Operations such as incoming/outbound networking calls, error counts, request latency can be automatically observed. This covers most of the typical scenarios that a developer will need. And, if there is any additional customizations or enrichment needed for this data, it is just a matter of defining only the additional data points that need to be collected.

So in the end, with the availability of automated observability in a low-code platform, a developer can achieve most of the observability features of their system without any additional code or configuration.

Concern #4: Low-Code Means Vendor Lock-In

A typical low-code platform consists of proprietary technologies for modelling and executing its workflows. So, a developer will only be allowed to run their flows in this system and nowhere else. This is a potential setback for most users since the software system’s future is not under their control. And if the target platform is discontinued, or if the vendor updates the terms of conditions, it can become a blocking issue. There should be a clear contingency plan for users if such things come into play, and at least until they can migrate to a new platform.

This is the situation where open standards and also open-source software become the deciding factor. The usage of open standards makes sure that your applications and services can be made to work with other systems, and if some parts of the system need to be redone later. For example, communication protocols such as HTTP, gRPC, and WebHooks; data formats such as JSON and XML; and security protocols such as OAuth and SAML makes sure that potential migrations can be done seamlessly.

To avoid any vendor-lock in, the underlying runtime engine or code compiler also can be made available separately in order for the users to locally build and run the systems in their own local environments if desired. In this manner, the platform’s users have a much lower risk with the platform since they have full control of the code and the execution environment they are using.

Our offering

Leveraging 15 years of WSO2 experience implementing thousands of global digital transformations, we believe we may have a solution. WSO2’s Choreo provides a fully supported low-code software development platform. It provides a low-code + code hybrid development environment, enhanced by AI. The platform’s graphical modelling generates clean code, and the changes flow bidirectionally without any additional code-level annotations or additional configurations. It has hybrid-cloud support and guarantees no vendor lock-in; its execution flow code can be independently compiled and run in your own local environment if needed.


In this article we looked at the common issues in low-code platforms, and how a well-thought-out design and supporting features can be used to mitigate these issues typical software developers will encounter. WSO2 Choreo is presented as a next generation intelligent iPaaS solution, which is set out to fulfill this demand. It provides an intuitive code/low-code hybrid development environment in order to provide all levels of developers a productive experience.

You can start creating your first Choreo app here or visit our resources section for more helpful content.

Sign in to get started

An intelligent iPaaS that does not make you choose between code and low-code

Create your first Choreo App

This website uses cookies so that we can provide you with the best user experience. Read our Cookie Policy to find out more.

If you wish to disable cookies you can do so from your browser.

I Understand