Viimasel ajal on populaarsust kogunud kergprogrammeerimise (low code) ja nullprogrammeerimise (no code) lahendused. Nende tööriistadega on võimalik automatiseerida paljud lihtsamad protsessid ilma, et peaks ise lähetkoodi kirjutamata. Hiljuti puutusin kokku aga ReTool nimelisel kergprogrammeerimise vahendiga, mille eesmärk on hoopis kasutajaliideste ehitamine.
Läbi aja on muutunud kasutajaliidest ehitamine oluliselt kiiremaks ja lihtsamaks. Tekinud on paju teeke ja raamistikke, mis võimaldavad kasutada valmis komponente ja seeläbi liikuda kiiremini kui kunagi varem. Samas mõnedes olukordades oleks kasulik ka see lisatöö ära jätta ja suunata enda energia prioriteetsematele tegevustele. Selliseks näiteks on iseteeninduskeskkonnad, mis on mõeldud ettevõtte siseseks kasutamiseks. Just uute projektide ja startupide algusfaasis on mõistlikum kulutada aega toote tuumfunktsionaalsuse arendamisele, mis loob lisandväärtust lõppkasutajale. Administratiivseid tegevusi taustal saaks esialgu teha ka näiteks otse andmebaasis, aga see ei ole väga skaleeruv lahendus. Kuna lihtne on andmeid seal valesti muuta ning mitte tehniliste inimeste jaok on see liiga keeruline. Seega mingil kujul on vaja kasutajaliidest, mis ühest küljest võimaldab administratiivtegevusi, kuid samas piirab tahtmatuid eksimusi.
ReTool on üks lahendus, millega kiiresti ehitada kasutajaliides, mis suudab ise suhelda otse andmebaasiga või veebiteenusega üle REST või GraphQL liideste. Kasutajaliidese ehitamine on võrdlemisi lihtne ja muudatuste tegemine väga kiire. Mingi hetk käis peast läbi mõte, et ReTooli pakub kohati isegi nii palju võimalusi, et see kergprogrammeerimine on peaaegu sama detailirohke kui päris tarkvara kirjutamine. Kuid kokkuvõttes saab selle tööriistaga liikuda ikkagi kiiremini, kui kõik ise nullist ehitada. Vaja ei ole aega kulutada sellistele teemadele nagu teenuse paigaldus, avalikustamise asukoht, autentimene ja graafiliste komponentide ehitamine.
Miinusena jäi silma, et kui ehitada mitmest andmebaasipäringust koosnev jada, siis see võib jääda aeglaseks. See juhtub kui andmete alamväärtused on jagatud paljude tabelite vahel ja päringud sõltuvad üksteise tulemustest. Näiteks kui soovite korraga kuvada kasutaja andmeid, tema tellimusi ja tellimuste küljes ka konkreetsete toodete infot. Sellisel juhul tuleb teha jadamisi mitu päringut, mis sõltuvad eelmiste tulemustest. Alternatiiviks on muidugi mitte kasutada sellisel juhul otse baasipäringuid, vaid tagastada kogu vajalik info korraga ühest serveri päringust.