This mini-series shows how to start a low-code platform from scratch. With example repo. How far are you willing to go down the rabbit hole?
Four articles explain the why and the how, so you can see for yourself what a low-code platform needs and how it delivers its functionality.
- Outline — Overall architecture (this article)
- Data — Dealing with data and data storage
- Frames & Views — Creating and using views
- The Rabbit Hole — Adding to the platform
To make the text more tangible, I’ve included a link to the repository that contains my Proof-of-Concept (PoC) for a low-code platform. See below.
This article does not explain terms like low-code, model driven development or levels of abstraction. Please be sure you know what these terms mean and how they are used in software development.
High-level requirements for the PoC
There are a lot of decisions to make creating software. These can be distilled into requirements. For the PoC, I‘ve made some, mostly technical, requirements of my own:
Defining the data structure once… and in run-time. Traditional application development have data structures embedded in every layer. And in every layer it needs to be written in a different language. If the structure changes, changes need to be made in every layer (3 times minimum) and that requires a new build + deploy.
This speeds up the early stages of development significantly. It’s helpful for fast-prototyping, something I like to do as an IT architect at the start of projects.
Data-driven, with good scalability and speed. A Data-driven platform means information first, functionality/behavior second. Since data is the foundation of any IT system, let’s place it front and center. On top of that, it needs to be fast and stay fast when scaling.
Modular approach to low-code. As a developer, I want to have a platform that comes with the opportunity to expand functionality with new modules. These modules expand the generic functionality of the platform, but can also be very solution-specific.
Used technology in the PoC
The PoC uses:
- Php (7.3.6)
- Symfony (4.3) with Graphaware/Neo4j-php-client (^4.0)*
- Neo4j (3.5.1)
Why? The combination Php/Symfony gives an easy to download and set up configuration with a vast space for expansion. Dev- and Production differences are mostly non-functional, so changes in the dev version can be tested while running the app. The Symfony debug feature also makes it very easy to spot errors while developing. Plus the Twig addon delivers complete flexibility in the (run-time) composition of web pages.
Neo4j has a very easy and accessible data-structure. Moreover, graphs can also be used to store and execute code-patterns (like linked-lists and trees) natively. For most use-cases, it also scales without losing speed and allows embedded functions if needed.
*note that the Graphaware client has been archived on github meaning no more development will or can be done on it.
The architecture
Since low-code uses abstraction, the architecture is chopped up in 3 parts:
Supplied by Platform itself — The left stack. There is a Data-service module that supplies the standard CRUD actions to act on the bare meta-meta model (read meta-data and perform standard crud actions on instances). The platform itself also supplies twig/html templates, like a default landing page. Very basic and abstract stuff.
Created by Developer — The middle stack. It revolves around functional modules, which are php-code and screens** that act on a specific data structure, With one or more functional modules, the low-code developer can define an implementation for a specific context.
The border between platform- and developer-created items here is blurry: The platform can ship stuff from the middle stack as well. In my example, I’ve also supplied a Data Browser, Data Editor and Data Viewer, which are functional modules.
However, in most low-code platforms the behavior provided to low-code developers is provided by the platform and is unchangeable for other parties. The approach with functional modules in my PoC are an attempt to open this up to a community of developers.
Examples of functional modules are:
- Defining, executing and analyzing a Questionnaire
- Decision engine in which the user can define and execute decisions
- Visualization templates for specific data structures
- A Process module (define, execute and dashboard)
- An Integration module (define, send/receive messages)
Created by low-code developer — The right stack. The low-code developer creates functionality for the end-user: A specific kind of Questionnaire (Customer Satisfaction Survey) or uses a process module to define a subscription process for a magazine.
The end-user functionality is configured (+stored as data in the database) with the functionality of the platform and the functional modules and does not need “programming”.
**note that the meaning of screens here are concepts within the functional modules to visualize and interact with data. A developer creates screen-templates and screen-behavior with which a low-code developer configures screens for the users. This is explained in detail in Part 3.
Building this architecture
Looking at this architecture outline again, the platform needs to be built from bottom-left to top-right. Basically following the orange arrow in the figure below. Preferably iteratively, because the platform is modular. So this path has to be taken for each module.
The meta-meta model is first on the list. This only needs to be built once and made accessible via the Data-service module.
After that, meta models can be created for functional modules and all the functionality they need to run properly. Last but not least will be end-user functionality. For every functional module, the process needs to be repeated.
There are many other directions you can take a low-code platform and each direction comes with its own specific design challenges. So while the above choices work for my needs, they might not work for yours.
Next step: Data
In part 2 the data structure for the PoC is explained.
And have a look: I’ve published a PoC for you to discover its inner workings and then make the decisions to build your own. It can be found on GitHub — InfoNotion. (Want to contribute or build the real deal? Please send a note!)