How to work with custom low-code application components
No- and low-code development platforms meet more enterprise app needs when they're customized. However, custom work can mean just as much programming as before you bought the tool.
The need for software is far greater than the number of programmers available to write it. That's why many organizations have opened up software development to people who don't code.
Companies use low-code and no-code tools to create applications based on basic models, usually via drag-and-drop interfaces. These platforms provide a simple, quick way to create functional applications without development expertise. But low- and no-code users sometimes find that these platforms don't do everything they need. To bridge the gap, organizations must customize such tools, extending them via integrations, new modules and other means. And custom low-code components open up fresh risks.
Application design patterns
An organization might upgrade its low- or no-code platform to provide different application models. Citizen developers drag elements of code into applications using the low-code GUI; these segments of code represent high-level functional building blocks. Low- and no-code platforms offer basic design patterns for many uses, but there's no guarantee that one of those packaged models will do the job. The choice of design pattern depends on several factors, including:
- whether you opt for a low-code or no-code approach;
- what the platform provides; and
- whether you define a new design pattern or tweak the implementation of a current one.
Almost all low- and no-code platforms provide ways for programmers to create high-level model extensions for applications. Extensions can make the difference between a successful or failed citizen development project. Platforms typically support these extensions through APIs that permit custom low-code visual blocks for drag-and-drop, and programmers should expect to work within them. Thus, factor a platform's ability to integrate traditional code into your low- or no-code tool selection.
An IT enterprise should consider a high-level extension to a low-code/no-code development platform when the organization has a specialized application model that it believes citizen developers could operate, but the platform doesn't support it. Examples include extensions for specialized analytics, the use of a nonstandard database technology, or to enable a complex multidatabase relationship. Put the effort into a new model if you expect broad use and high value -- otherwise, the benefit of low- or no-code could be wiped out by all the work required to enhance the tool to fit custom demands.
Visual blocks and custom code
Sometimes a programmer builds a new high-level model rather than over-modify the model supported by the low-code/no-code platform. It makes sense to invest time to design a new visual block or other element when needed for highly specialized purposes.
Many reasons exist to write new visual blocks rather than modify a packaged block in a no-code/low-code tool. Major modifications increase the risk of misuse by someone who is unaware of the changes made. From a performance perspective, it's simply inefficient for citizen software developers to jump into and out of custom code many times. Avoid tweaking an existing visual block if a modification can't be made for a specific application.
When customizing tools for citizen developers, the difference between low-code and no-code tools matters. These platforms rely on either logic or goals to get from idea to software product. Low-code platforms typically require users to define what steps their creation should take -- i.e., logic -- not the goals to be achieved. Most no-code languages are goal-based, and don't expose these logic steps to the person creating an application. In those cases, the programmer must add a new visual block to insert custom code.
Some low-code tools employ a high-level language (HLL), also called a fourth-generation language (4GL), that simplifies programming. Other platforms use a model-drag-and-drop interface. Still other platforms use both. A procedural HLL/4GL is easy to customize, as long as the platform provides APIs. The language describes the steps that make the low-code software product work.
Check if your selected low-code platform provides for logic adjustments via traditional development approaches. These platforms enable developers to integrate, via established APIs, custom programming. For many programmers, it's easy to introduce a logic step implemented via a traditional programming language in between those written in the HLL/4GL.
Exercise some discipline when adding custom programming to enhance software the organization creates with a low-code tool. Often, line-of-business employees want a specific format for the software product's output, or a particular interpretation of a set of variables. In fact, these workers will often suggest enhancements to the tool rather than accept a minor formatting issue. The more modifications to a low- or no-code platform that you make, the less likely you are to actually save expert development resources and time after all.
Don't forget special file access
Another common ask in business settings is custom programming to address the file access needs of low-code-created software. Most low-code/no-code development tools in the market support traditional database access, though some specialized databases require a custom I/O element to work. Databases often support this capability through a well-defined API. This is the most common reason to extend low- and no-code applications; it's also the most successful.
The risk of custom low-code components
The best approach is to build the extension of new code as an independent module that links into an API for the low- or no-code platform. This approach reduces the risk that software errors in new code will hinder the operation of the low- or no-code product. Test any enhancements extensively before releasing them.
No-code software development tools don't all prevent customization, but they might restrict it. A no-code tool builds software from a representation of the intended result. The platform hides the individual steps that get the application from input to output -- i.e., all that code that users don't have to write. With this kind of tool, customization means programmers have to build drag-and-drop elements, which no-code users can manipulate. Without access to the procedural steps from input to output, it is difficult to customize within those steps. The language that the tool supports will define what artifacts the citizen developer manipulates and, thus, what custom code can augment or replace.
When shopping for a tool to enable citizen developers, evaluate how much the business will rely on the ability to enhance applications via custom coding. To do more customization, favor a low-code platform over a no-code one. The low-code approach will always offer more enhancement options.
