Low-code webapplicaties worden steeds populairder. Zeker bij organisaties die processen meer willen digitaliseren. Maar wat zijn low-code applicaties precies? Op een low-code platform kan je zonder honderden regels code een applicatie maken. De ‘bouwstenen’ om iets te maken staan al voor je klaar. Sleep ze eenvoudig naar de plek waar je ze wil hebben en voilà, je ziet een website of app voor je neus ontstaan. Toch iets tweaken? Voeg dan zelf een stukje code toe en personaliseer jouw applicatie. Je hoeft tegenwoordig maar een zoekopdracht in Google of ChatGPT in te voeren om erachter te komen hoe dat werkt. Dat stukje tweaken, is dan ook meteen het verschil met no-code; hier kan je alleen gebruikmaken van voorgevormde bouwstenen zonder zelf te coderen.
Zoals bij alle applicaties is het ook bij low-code belangrijk dat deze zo min mogelijk fouten bevatten, zo goed mogelijk presteren en veilig zijn. Hier ligt dan ook een interessante uitdaging voor de bouwers en testers van low-code platforms.
In mijn jaren als performance tester is het mij opgevallen dat low-code platformen steeds meer ingezet worden voor het bouwen van grote applicaties waar intensief gebruik van wordt gemaakt. Graag deel ik daarom mijn ervaringen, zodat bouwers en beslissers – die de knoop doorhakken over een platform – de juiste keuzes kunnen maken en zich bewust worden van diverse valkuilen.
De belangrijkste voordelen van low-code
Met deze applicaties heb je al snel een enigszins werkend product. En dat zonder de vele sprints die nodig zijn voor het ontwerp en de softwareontwikkeling. Bovendien is het gebruik en beheer ook redelijk uitgekristalliseerd, omdat deze systemen door veel verschillende type klanten gebruikt worden. Best logisch dus dat steeds meer organisaties zelf aan de slag gaan met low-code.
De gevaren van een low-code platform
De kracht van het platform is dat het laagdrempelig is waardoor relatief makkelijk en snel een functionaliteit kan worden gebouwd. Iedereen (nouja, bijna dan) kan bouwen met low-code. Een mooie ontwikkeling. Maar het laagdrempelige karakter vormt ook een gevaar. Gebruikers kunnen onbedoeld slecht presterende functionaliteiten bouwen. En daar kunnen talloze redenen voor zijn:
- Druk om zo snel mogelijk iets op te leveren
- Beperkte technische kennis
- Het gebruik van verkeerde methodes
Functioneel gezien kan iets prima werken, maar onder de oppervlakte kan er een hoop misgaan. Er kan bijvoorbeeld veel meer data worden opgehaald – zonder dat dit wordt weergegeven – dan noodzakelijk. Dit heeft zowel security- als performancerisico’s tot gevolg. We zullen je een voorbeeld geven.
Wat gaat er schuil onder de oppervlakte?
Je bouwt een zoekscherm met een door het platform aangeboden zoek- of filterfunctionaliteit. In dit voorbeeld wordt er gezocht naar een tweedehandsauto van maximaal 10 jaar uit. Er kunnen wel honderden resultaten voldoen aan deze zoekopdracht. Het scherm toont, zoals geconfigureerd, een gepagineerde weergave met 50 resultaten van de gevonden auto’s. Hierdoor blijft het voor de bezoeker overzichtelijk. Precies wat je wilde hebben, toch?
Laten we wat dieper inzoomen op hoe de zoekresultaten zijn opgevraagd en geleverd. Het kan zomaar zo zijn dat je dan ziet dat stiekem alle resultaten zijn gestuurd in plaats van alleen de eerste 50. Dit zorgt voor extra belasting op databases, extra geheugengebruik in zowel de backend-applicatie als de browser van de gebruiker en voor meer netwerkbelasting.
Als je pech hebt kan het platform daarna per gevonden item nog een extra verzoek sturen naar de server om alvast extra data op te halen, voor het geval dat de gebruiker dit zou willen zien (hint: niet!). Dit kan weer zorgen voor lange wachttijden en druk op de systemen, waardoor ook andere gebruikers vertraging kunnen ervaren. Dat wil je natuurlijk voorkomen.
Heb je niet zo veel verstand van het bouwen van applicaties? Dan kan het handig zijn om contact op te nemen met een platformbouwer. Zij kunnen je helpen met best practices voor de te bouwen functionaliteit.
Testen blijkt een grote opgave
Low-code platforms kunnen alles (nouja, in ieder geval heel veel). Met deze filosofie is de servercommunicatie ontworpen. Hierbij gaat dataverkeer heen en weer tussen de browser van de gebruiker en de server van de aanbieder. De browser interpreteert deze servercommunicatie en verwerkt de regels tot een pagina die de gebruiker ziet.
Als je aan de slag gaat met een low code platform houdt er dan rekening mee dat er extreem grote berichten heen en weer gaan tussen de browser en server. Deze berichten bevatten vaak nietszeggende, generieke referenties, bijvoorbeeld in de vorm van een reeks nummers en/of letters. Voor mensen zijn deze data lastig te begrijpen.
Deze ‘nietszeggende’ data zijn belangrijk wanneer je een testscript wil bouwen op basis van de servercommunicatie. Referenties moeten, simpel gezegd, in serverantwoord op verzoek A worden afgevangen en in verzoek B weer worden opgestuurd naar de server. Maak je ergens een foutje? Dan zal het script niet werken: ‘computer says no’. Doordat een low-code platform vrijwel alles moeten kunnen, is het scriptingproces slecht tot niet te automatiseren. Het bouwen van een testscript vraagt om veel kennis en wordt al snel een enorm tijdrovend, foutgevoelig en intensief karwei.
Hoe valt dit ‘probleem’ op te lossen? Je zou bijvoorbeeld de testscripts kunnen baseren op opgebouwde/geïnterpreteerde pagina’s met tabellen en knoppen. Hierdoor wordt er een browser geladen die alle applicatielogica uitvoert en zo zelf het zware werk doet. Het bouwen van een script wordt zo een stuk makkelijker. De interface is namelijk speciaal voor mensen ontwikkeld. Helaas hangt ook hier een nadeel aan. Het brengt een mate van onbetrouwbaarheid met zich mee, omdat veel meer zaken voorwaardelijk zijn voor een juiste uitvoering. Bovendien kost het uitvoeren van deze performancetest veel systeemresources op de testexecutieservers. Hier geldt dus: bezint eer ge begint.
Nog wat laatste wijze woorden van de smid
Als je op zoek bent naar een nieuw ontwikkelplatform let dan op:
- De ontwikkelsnelheid
- De doeltreffenheid
- De (geautomatiseerde) testbaarheid
Mocht je na dit verhaal nog altijd een low-code oplossingen willen inzetten voor jouw applicatie, zorg er dan in ieder geval voor dat bij de specificatie-fase aandacht wordt geschonken aan performance-aspecten, zoals gelijktijdige gebruikers en responstijden voor verschillende soorten acties. En uiteraard, zorg voor een goede teststrategie. Computest kan je hier uiteraard goed bij ondersteunen!
Wil je weten hoe wij je kunnen helpen?
Mail dan naar info@computest.nl of bel +31 887331337.
