The 3 Stages to Making Your Own No-Code Solution

As our world relies more and more on technology, the need for developers is greater than ever. But, capable developers are limited resources, hard to get, and hard to keep; it will be even worse in the future because demand is rising constantly.

One of the very successful concepts for solving this issue is using no-code tools. No-code tools are capable of delivering amazing functionalities without classic coding and that way a much broader audience is able to use new and complex technologies to solve some pain points in their businesses. This concept is so successful and popular that right now you can find and use even no-code services for creating new no-code applications!

Use cases are limitless, the question is only how hard is to design and build one. The screenshot above is from Convoworks (my current startup which enables WordPress websites to have Amazon Alexa skills) while the one below is from Elementor, the most popular page builder on WordPress.

Well, it is not easy, especially if you are first time doing this, but it is doable. With one warning: once you got used to this approach of thinking, you might get hooked and you will see everything as a possible no-code solution.

Can I Do It and in Which Cases Is It Applicable?

Very important thing is that you are familiar with the required technology and business process. Meaning that you already have a working solution coded in a classic manner.

I do not recommend applying this pattern in cases when you are solving some business issue for the first time or when trying to use a new programming language. You’ll have enough issues with a no-code framework, so you don’t need something else to distract you. Besides that, being aware of the business process and pain points is more important than knowing the technology.

Another important thing to keep in mind is that if you have limited concrete implementation use cases (5-10), it will be much cheaper to use a classic copy/paste implementation.

The 3 Stages to Create Your Own No-Code solution

During my career, I used this concept over a dozen times in quite different use cases. It started with building backend administration web pages, mobile websites, but I also used it for content import processes, creating HDR photos, creating stats reports and at last for managing conversational services. What I noticed was that the whole process could be divided into three distinguished phases, which are implemented in a particular order.

Each stage brings its own layer of functionality, but the best thing about this approach is that you have a working solution in any of those phases.

Stage 1: Hard-coded Proof of Concept

This is the most exciting stage in which you are actually solving the problem. As on every project beginning, you are full of energy and enthusiasm. Here you will have your early discoveries and successes.

The task is to describe required workflows with reusable component concepts. In most cases (and I would recommend) these concepts should be described through the interface definitions. When you are looking at the process that should be handled, try to categorize logical blocks which you are encountering, try to define common needs, check are there any top-level types of objects ... all that will give you names for your class types and will describe their relations.

If you are building some kind of web page builder you might end up with something like in the example below. Notice how it feels like boilerplate code. These examples are in PHP, but it should be clear to all and easy to reproduce in any other programming language.

$app    =   new MyNoCodeApp( ['some'=>'app', 'config'=>'data']);
$home   =   new MyNoCodePage( ['title'=>'Home']);
$app->addPage( $home);
$header =   new MyDefaultHeaderComponent( 
    ['title'=>'Home', 'text'=>'Some description here', 
	 'bgColor' => 'orange']);
$home->addToHeader( $header);

$about  =   new MyNoCodePage( ['title'=>'About']);
$home->addPage( $about);

$result =   $app->run();

Your app implements logic to keep the state and be aware which page should be triggered. Page is aware that it has several sections (header, body, sidebar ...) and will make sure that all child components are executed too.

Depending on what you are building (and in which framework), you should invoke your shiny new app somewhere. If the result is a web page, you will output html in some view controller or dispatcher. If the result of your application is a REST response, you'll put it in some REST handler.

Although factory class is the topic of the next stage, I like to introduce it from the beginning, which allows me to mess with the framework's controllers much less, and instead gives me full focus on my package.

// example controller method
public function handleAppCall( $appId) {
    
    $app = $this->myAppFactory->getApp( $appId);
    $app->init();
    return $app->html();
}

View handling can vary a lot from framework to framework, so here is a quite standard example in case your application is REST-based and you are using PSR-15 HTTP Server Request Handlers.

class NoCodeAppRestHandler implements RequestHandlerInterface
{
    private $myAppFactory;
    private $httpFactory;
    
    public function __construct( $httpFactory, $myAppFactory)
    {   
        $this->httpFactory = $httpFactory;
        $this->myAppFactory = $myAppFactory;
    }
    
    public function handle( ServerRequestInterface $request): ResponseInterface
    {
        $appId = $request->getQueryParams()['appId'];
        $app = $this->myAppFactory->getApp( $appId);
        $data = $app->run();
        return $this->_httpFactory->buildResponse( $data);
    }
}

Stage 2: Component Factory and Loading App From the Definition

Now that we have a working proof of concept, let's get rid of that boilerplate code. For that, we will write the app definition as a JSON.

{
    "appId" : "My No Code app",
    "root" : {
        "class" : "MyNoCodePage",
        "properties" : {
            "title" : "Home",
            "header" : [ {
                "class" : "MyDefaultHeaderComponent",
                "properties" : {
                    "title" : "Home",
                    "text" : "Some text here",
                    "bgColor" : "orange"
                }
            }],
            "body" : [],
            "footer" : [],
            "childPages" : [{
                "class" : "MyNoCodePage",
                "properties" : {
                    "title" : "Home"
                }
            }]
        }
    }
}

Note how we added

childPages

property to a page object. We need it to keep relations between objects and it will require us to make small adjustments to components we created in the first stage. We are expecting child pages inside configuration, so we will move actual

addPage()

calls to the

MyNoCodePage

class constructor or some load method (it is better to leave the constructor simple).

Now you have to go to your app factory class, load this JSON and programmatically create class instances and return the app object. All programming languages have some support for creating objects from a string class name so this shouldn't be a problem. The main thing is that all properties will be defined through a configuration object/array.

Stage 3: Visual Editor

The hardest and the largest stage in this process. Especially if you want to create some nice-looking solution that will be used outside of your organization.

First, you have to figure out how to visually represent the whole thing, and then actually implement it. You will also have to create and expose some administration REST API that will be used by the GUI.

All your components will have a set of properties that a user can adjust. These properties can use different types of property editors (text, dropdown, ...) and you will have to have some definition that will help render properties. Because your GUI and your core engine (server) are detached and technically two separate projects, these definitions are the bridge between these two worlds.

{
    "class" : "MyNoCodePage",
    "properties" : {
        "title" : {
            "default" : "",
            "label" : "Title",
            "editorType" : "text",
            "editorProperties" : {
                "maxLength" : 25,
                "required" : true
            }
        },
        "header" : {
            "default" : [],
            "label" : "Header components",
            "editorType" : "container",
            "editorProperties" : {
                "multiple" : true
            }
        },
    }
}

The main goal is that when you are adding a new component to the system, you will just add a new definition and the GUI will not require any changes. All goes through shared definitions (GUI can load them from some REST endpoint).

Conclusion

In the end, it is not that hard. The question is to know what you are planning. If you are building an internal solution, then you can have a nice tool in a week or so. If you are trying to build a publicly available product, now you know that it is all doable.

You can have your 1st or 2nd phase done in a short time, but you should mock up GUI and concentrate more on running the startup than on the technology.