Welke low-code-oplossing je als developer beter niet kunt vertrouwen

Applicatieontwikkeling verandert voortdurend. Dat blijkt wel uit het feit dat analisten ontwikkeltools en -platforms regelmatig opnieuw definiëren en indelen in verschillende categorieën. Dit terwijl organisaties vooral behoefte hebben aan één platform en toolset waarmee ze snel (omnichannel) klantgerichte apps kunnen ontwikkelen voor desktop, web, mobiel, wearables en chatbots.

Het kiezen van de juiste low-code-oplossing op basis van open standaarden kan van onschatbare waarde zijn in een tijdperk dat wordt gekenmerkt door een behoefte aan meer apps die bovendien sneller moeten worden geleverd en overal moeten kunnen draaien. Toch is het belangrijk om te realiseren dat niet alle low-code-oplossingen hetzelfde zijn. Hieronder delen we daarom drie rode vlaggen om rekening mee te houden bij de keuze van een low-code-oplossing:

1. Black box

Low-code heeft bij sommige ontwikkelaars een slechte reputatie, door de perceptie dat het een ‘black box’ is - waarbij je als developer niet kunt zien wat er onder de motorkap gebeurt. Ontwikkelaars staan er niet om te springen om bedrijfskritieke services uit te rollen op een platform waar ze geen enkele controle over hebben.

De belofte van hogere productiviteit in een snel veranderende omgeving die low-code biedt is natuurlijk mooi, maar een black box die geen inzicht geeft in de code is natuurlijk niet de oplossing. Waar je als developer meer aan hebt, is een low-code oplossing die gebaseerd is op open standaarden en die volledig inzicht geeft in de broncode. Low-code is in essentie een prima hulpmiddel. De waarde van een low-code-oplossing hangt echter nauw samen met wie er gebruik van maakt - en dat vraagt ??om een ??professionele ontwikkelaar, niet om een zakelijke gebruiker die geen verstand heeft van codes.

Low-code voor professionele ontwikkelaars betekent eenmalig coderen en vervolgens uitrollen over meerdere platforms, terwijl je de volledige controle houdt over de gebruikerservaring.

2. Monolithische architectuur

App-ontwikkeling is altijd al complex geweest. Ontwikkelteams moeten tegenwoordig echter aan meer verwachtingen voldoen dan ooit tevoren: onbeperkte schaalbaarheid over meerdere kanalen en een snelle verschuiving naar cloud-gebaseerde ontwikkeling met behulp van containers en microservices. Tegelijkertijd wordt van developers verlangd dat ze een optimale gebruikerservaring kunnen leveren.

Ontwikkelaars staan ??nogal eens sceptisch tegenover low-code-oplossingen, omdat deze worden gezien als verouderd, monolithisch en onvriendelijk voor de implementatie van applicaties. Daar zijn verschillende redenen voor:

• Monolithische low-code-architecturen kunnen in eerste instantie eenvoudig worden ontwikkeld en uitgerold, maar zijn op de lange termijn vaak nauw met elkaar verbonden, waardoor ze moeilijk te schalen en te onderhouden zijn. Als een onderdeel van de applicatie moet worden bijgewerkt, vereist dit vaak dat andere delen ook opnieuw moeten worden geschreven.
• Monolithische low-code-architecturen kunnen moeilijk te doorgronden zijn, omdat ze afhankelijkheden hebben die niet zichtbaar, maar als het ware in de applicatie ingebakken, zijn. Als developer word je dan opgezadeld met de uitdaging om de ontwikkeling, het testen en de uitrol te doen met een monoliet, maar dan zonder de mogelijkheid om componenten afzonderlijk te ontwikkelen, testen, inzetten en schalen.

3. Eigen toolsets

Low-code-oplossingen hebben vaak hun eigen toolsets. In theorie is dat handig, omdat het platform en de tools afkomstig zijn van dezelfde bron, wat voordelen zou moeten opleveren voor ontwikkelaars. De realiteit is weerbarstiger. Toolsets van low-code-oplossingen zijn niet altijd even eenvoudig in gebruik en je hebt al gauw te maken met vendor lock-in en een ecosysteem van codevoorbeelden, zelfstudie en communities die alleen gespecialiseerd zijn in één leverancier.

In sommige gevallen bevordert een platformleverancier het gebruik van standaardtalen, maar dan wordt de code alsnog vergrendeld binnen het eigen ontwikkelingsproces.

Het aanleren van de skills die nodig zijn voor low-code-platformen kost dus behoorlijk wat tijd. Daarnaast staan doorgewinterde ontwikkelaars niet te springen om zich specialiseren in een niche-platform, omdat ze daarmee een afstand creëren tussen zichzelf en de developer-community. En dat is niet bepaald bevorderlijk voor je CV. Daar komt nog bij dat bedrijfseigen code moeilijk te debuggen kan zijn en dat je beperkte middelen hebt om voorbeelden te vinden en problemen op te lossen.

Deze opeenstapeling van inflexibiliteit en risico’s zorgt ervoor dat professionele ontwikkelaars terughoudend zijn als het gaat om het gebruik van eigen toolsets van leveranciers.

Wat is dan wel een oplossing?

Het ideaal zou zijn om de cloud-mogelijkheden van bijvoorbeeld AWS of Azure tot je beschikking te hebben, gecombineerd met het gemak van een low-code-implementatie.

Developers die werken met een serverless, cloud-based platform kunnen dit platform het beheer laten verzorgen van microservices en functionaliteiten en deze automatisch laten schalen. Als je dit combineert met een Node.js-back-end en een front-end voor internet en mobiel die gebaseerd is op JavaScript, hebt je in principe een volledige stack tot je beschikking.

De voordelen:

• Door het combineren van een serverless en low-code platform dat gebouwd is op JavaScript, kun je voldoen aan de vraag naar goed omnichannel-klantervaringen op basis van de skills die je als developer al hebt.
• Verschillende ontwikkelaars of zelfs verschillende teams kunnen onafhankelijk van elkaar werken aan hun deel van de applicatie, zonder dat ze in conflict komen met wijzigingen die door andere teams zijn aangebracht.
• Updates kunnen worden uitgevoerd zonder de app-code opnieuw te schrijven of opnieuw te gebruiken.
• Code is herbruikbaar in apps en eenvoudiger te onderhouden, omdat de functionaliteit geïsoleerd is.

Het resultaat is dat je als ontwikkelaar vrij bent om je te concentreren op de functionaliteiten van de applicatie en de gebruikerservaring, terwijl het platform de rest beheert.

Wat vooral van belang is, is dat een low-code-platform gebaseerd is op een veel gebruikte en gestandaardiseerde taal met een sterk ecosysteem aan hulpmiddelen, bibliotheken en leermateriaal. Ik geloof dat die taal JavaScript is; JavaScript biedt de mogelijkheid om een gemeenschappelijke taal te gebruiken voor zowel de front-end als de back-end van een applicatie.

Door: Mark Troester, VP of Strategy bij Progress