Hoe begin je een low-code platform met Neo4j? – Outline (1/4)

Deze serie van vier artikelen toont hoe je een low-code platform vanaf nul kunt opbouwen. Met een voorbeeld repository. Hoe diep ben jij bereid te gaan?

In de vier artikelen wordt het waarom en het hoe beschreven, zodat je kunt zien wat een low-code platform nodig heeft en hoe het zijn functionaliteit levert.

1. Outline — De architectuur (dit artikel)
2. Data – Het lezen en schrijven van data
3. Frames en Views – Het maken van pagina’s
4. Hoe diep ga jij? — Uitbreidingen schrijven

Om de tekst tot leven te laten komen, wordt onder het artikel een link naar de gebruikte repository genoemd. Deze bevat het Proof-of-Concept dat ik gebouwd heb als begin voor het low-code platform.

Noot 1: De artikelen zijn initieel opgesteld in het Engels, dus de afbeeldingen zijn ook in het Engels.

Noot 2: Dit artikel beschrijft geen termen die horen bij low-code of model gedreven development. Ik ga er van uit dat je deze termen kent en weet wat ze betekenen.

High-level requirements voor de PoC

Er zijn een hoop beslissingen te maken als je software schrijft. Dit geldt ook voor een low-code platform. Voor deze PoC zijn een aantal requirements geschreven. De meeste zijn van technische aard:

Het eenmalig en in run-time definiëren van de datastructuur. Traditionele applicaties bevatten data structuren in elke laag. En in elke laag wordt die structuur in een andere taal beschreven. Als de structuur verandert, moet dat dus in elke laag gebeuren… en dat heeft een nieuwe build + deployment van de software nodig.

Om dit te vermijden wordt de data structuur eenmalig vastgelegd zodat we, zeker de vroege stadia van, de ontwikkeling kunnen versnellen. Iets wat ik als IT Architect heel erg kan waarderen.

Data-gedreven, schaalbaar en snel. Een data-gedreven platform betekent informatie eerst en daarna pas functionaliteit/gedrag. Data is het fundament van elk IT systeem, dus dat moet centraal staan. Daarnaast moet het geheel snel zijn en blijven wanneer het gebruik van de applicatie groeit.

Een modulaire aanpak voor low-code. Als developer wil ik graag een platform dat de mogelijkheid biedt om haar functionaliteit uit te breiden met nieuwe modules. Niet met een API, maar in het platform. Dit kan generieke functionaliteit zijn, maar ook heel specifiek.

Gebruikte technologie in de PoC

De PoC gebruikt:

• Php (7.3.6)
• Symfony (4.3) with Graphaware/Neo4j-php-client(^4.0)*
• Neo4j (3.5.1)

Waarom? De combinatie Php/Symfony levert een pakket op dat eenvoudig te downloaden en installeren is met daarnaast voldoende ruimte om uit te breiden. De verschillen tussen Dev en Prod omgevingen zijn vrijwel allemaal non-functional, dus veranderingen in de Dev versie kunnen direct getest worden. De debug functionaliteit van Symfony maakt het erg eenvoudig om fouten op te sporen tijdens het ontwikkelen. Daarnaast is de Twig addon enorm flexibel in het samenstellen van webpagina’s.

Neo4j heeft een eenvoudige en toegankelijke data structuur. Daarnaast kunnen graph databases ook gebruikt worden om zonder transformatie design-patterns (linked lists, trees) op te slaan. Voor de meeste use-cases schaalt deze database ook zonder verlies van snelheid en kan gebruik gemaakt worden van de ingebouwde (en uitbreidbare) features.

*de Graphaware client is wel gearchiveerd op Github, dus daar wordt helaas niet meer aan ontwikkeld.

De architectuur

Low-code maakt gebruikt van abstractielagen, dus de architectuur bestaat uit 3 delen:

Een architectuur voor een low-code platform

Supplied by Platform itself — De linker kolom. Deze bevat een data-service die standard CRUD acties levert van/naar de database. Deze handelt vanuit een meta-meta model dat compatibel is met het Neo4j datamodel. Het platform zelf levert ook twig/html templates, zoals een standaard landingspagina.

Created by Developer — The middelste kolom. Deze kolom draait om functionele modules. De basis hiervan zijn php-code en Screens** die handen naar een specifieke datastructuur. De low-code ontwikkelaar kan met één of meerdere functionele modules een implemenatie maken voor een specifieke context.

De grens tussen wat gemaakt is door platform- en developer is zeer dun: Het platform kan ook functionaliteit ontwerpen en leveren uit de middelste kolom. In mijn PoC zijn dit de Data Browser, Data Editor en Data Viewer, wat allemaal functionele modules zijn.

In de meeste low-code platforms is het gedrag dat geleverd wordt aan de low-code ontwikkelaar niet te veranderen of uit te breiden (zonder API’s) De aanpak met functionele modules is een poging om die aanpasbaarheid en uitbreidbaarheid wel te leveren in een open source jasje.

Voorbeelden van mogelijke functionele modules zijn:

• Het maken, uitvoeren en analyseren van een Vragenlijst
• Een Decision engine
• Visualizatie templates voor specifieke datastructuren
• Een Process module (maken, uitvoeren en dashboard)
• Een Integratie module (definiëren, zenden en ontvangen van berichten)

Created by low-code developer — The rechter kolom.

De low-code ontwikkelaar maakt functionaliteit voor de eindgebruiker: Een specifieke vragenlijst (Medewerker tevredenheidsonderzoek), of het proces voor het abonneren op een tijdschrift.

Deze functionaliteit wordt geconfigureerd (en opgeslagen als data in de database) met de functionaliteit van he platform en de functionele modules en heeft geen ‘programeerwerk’ nodig.

** Screens is een term binnen de functionele modules om met data te werken (visualisatie en interactie). Deze term wordt in artikel 3 in meer detail uit de doeken gedaan.

Het bouwen van deze architectuur

Als we opnieuw naar deze architectuur kijken, dan moeten we concluderen dat deze gebouwd moet worden van linksonder naar rechtsboven. (Volg de oranje pijl in de onderstaande afbeelding.) Bij voorkeur iteratief, want het platform is modulair. Dit pad moet dus voor elke module genomen worden.

Het meta-meta model wordt als eerste gemaakt. Dit hoeft maar eenmaal gebouwd te worden en wordt ontsloten via de Data-service module. Daarna volgen de meta modellen. Deze worden gemaakt voor de functionele modules en alle functionaliteit die zij behelzen. Als laatste volgt de functionaliteit voor de eindgebruiker. Voor elke module dient dit proces herhaald te worden.

Er zijn veel andere richtingen waarin je een low-code platform kan bouwen. Elke richting komt met zijn eigen specifieke uitdagingen. De bovenstaande keuzes werken dus voor mijn requirements en behoeften, maar ze hoeven niet te werken als ze in een andere context geplaatst worden.

Volgende stap: Data

In deel 2 wordt de data structuur voor de PoC uit de doeken gedaan.

Neem een kijkje in de keuken: De PoC staat op Github, zodat je de werking van het platform kan bestuderen. Hij is hier te vinden: GitHub — InfoNotion. (Als je bij wilt dragen of samen iets wilt bouwen, stuur een berichtje!)