Low-code, the ability to generate running software by writing as less code as possible, is one of the buzzwords that currently caught the attention of the IT industry. However, the foundational ideas of low-code engineering were present in the industry and academic community for decades. Entire books have been written a long time ago describing approaches for developing software without requiring intensive coding. In so-called low-code environments, code is not the main artifact to build software; High-level specs, models or Domain-Specific Languages (DSLs) are used instead. In general, underlying code is still present, but is automatically generated by the tooling, then used to obtain the final applications or software artifacts in general directly. The tools that convert the high-level (low- or no-code specifications) in the final software are often referred to as "Code Generators".
In this article we are going to explore different kinds or approaches for low-code and how at Ensolvers we embrace the concept from a strategic point of view.
If we understand "low code" as reducing the need of writing code to obtain working digital products, there are different types of solutions that exist in the field.
"Pure" low-code (also known as Domain Specific Development or Modeling) solutions allow to generate working applications 100% from specifications that are not strictly code. Visual models, formal documents in languages such as YAML or XML and any other type of specifications can be used.
Hybrid solutions also use high-level representations to generate working solutions, but they have "hooks" or "placeholders" in which code can be injected as well if needed, giving the engineering team more "freedom".
Scaffolding approaches allow repetitive code pieces to be generated automatically based on some formal specifications (like other approaches), but the rest needs to be coded by hand. So they do not generate working software pieces per-se, they just help engineers in the task by reducing the verbose parts in the coding task
As in other fields in engineering, there is no silver bullet in terms of low-code. It depends on several factors: how fast the product being built needs to be in the market (go-to-market strategy), the amount of control that we need to have on underlying architecture, how we know about the evolution of the product, etc.
Pure solutions are by far the most effective solutions in time: they generate 100% of the implementation from models or high-level specifications. Writing these specifications in general is order of magnitudes faster than writing the underlying code. However, there are important implications. The first one, there is no control on the underlying code, so if anything "out of the box" is implemented, it needs to be done separately. Plugins, extensions or entire code generators need to be added or tuned for such tasks. Secondly, there is no detailed control over architecture, so product scalability is limited to what has been specified to be generated when the low-code tooling or environment has been implemented.
Having the ability to introduce code if needed that hybrid solutions provide helps to do some fine-tuning if required, which might solve some of the scalability and performance limitations and avoid the necessity of additional generators or plugins. However, this fine-tuning is still done over a pre-defined architecture which is generated by higher specifications. So, if root changes are required - for instance, some operation needs to be executed asynchronously using an underlying customized queue system instead of synchronously - there is a clear limitation. The low-code solution needs to concretely implement these architectural variants or must be low-level enough to allow customizing these aspects.
On the other hand, scaffolding solutions which only generate a part of the code of the solution, do not have such a strict limitation: they rely on well defined and known architecture and they still allow to implement parts of it from scratch if needed. While some architectural decisions are still fixed, generated code can still be adapted to what is needed. The engineering team still has control of the full architecture. Of course, the drawback is time: only a part of the code is generated automatically, so for the rest we need traditional, manual coding work.
Low code is a trending concept and, at the same time, their root fundamentals have been studied for decades. At Ensolvers, we know that not all customers are the same, and have unique business / tech requirements, so we want to be in control of the architecture and solution we are building to tailor and adapt the solution to what is required, making emphasis not only in functional aspects of the product but also in security, scalability, etc.
We've developed our custom scaffolding solution over our extensible full-stack framework (based on a standard and well-known Java and React stacks) that allows our engineering teams to generate most of the code they need, while having 100% control of the architecture and underlying infrastructure.
