De term UI of gebruikersinterface wordt vaak gebruikt bij de ontwikkeling van toepassingen. Het eerste wat een klant ziet wanneer hij een app opent is hoe de applicatie is ontworpen, en het is logisch dat dit een aspect van webontwikkeling is dat zeer belangrijk is. Een eenvoudige en gebruiksvriendelijke UI kan de conversie van een webapp met bijna 200% verhogen. UI is een integraal onderdeel van het softwareontwikkelingsproces.
Omdat het vooral gaat om wat een klant ziet, worden gebruikersinterfaces ontwikkeld door front-end engineers. Verschillende front-end frameworks - zoals React.js, flutter en meer - maken het ontwikkelen van mooie gebruikersinterfaces eenvoudig en efficiënt. Traditionele ontwikkeling kan echter een langdurig proces zijn, vooral als het gaat om updates. App stores zoals de Apple store en Google play store vereisen vaak dat ontwikkelaars een lang proces doorlopen als ze grote UI-wijzigingen willen doorvoeren. Dit is waar SDUI, of server-driven user interface app ontwikkeling, een verschil kan maken.
Server-gestuurde UI of backend-gestuurde ontwikkeling kan een game changer zijn, en de manier waarop het werkt lijkt erg op hoe browsers omgaan met talen als HTML en CSS. Maar voordat we ingaan op hoe SDUI werkt en de voordelen ervan, laten we eerst eens kijken wat backend of server-gedreven UI eigenlijk is.
Wat is server-gedreven UI?
De gebruikersinterface van een app of dienst verwijst naar hoe deze eruitziet en aanvoelt. Een UI-ontwerper moet zich bezighouden met hoe individuele aspecten van de app worden getoond, de esthetiek, en de responsiviteit van de webpagina op meerdere apparaten. Het is immers het gebied van het startscherm waar de consument zich met de site bezighoudt.
De gebruikersinterface van een website wordt bepaald door de HTML-code. Klanten kunnen deze code snel ontvangen wanneer zij een site bezoeken die gebruik maakt van server-side UI-ontwikkeling. Wanneer gebruikers een dergelijke app gebruiken, worden de site, het ontwerp, CSS, JavaScript en het materiaal in de site geladen tijdens de oorspronkelijke aanvraag.
Bij een traditionele ontwikkeling van een mobiele app ontwerpt en verpakt een programmeur het ontwerp en het uiterlijk van de gebruikersinterface in de releasecyclus. Het softwarepakket wordt geüpload naar app stores zoals de Google play store, waar ze worden beoordeeld voordat ze beschikbaar worden gesteld voor download door klanten. De gebruikersinterfaces van dergelijke apps worden interactief gemaakt door de UI los te koppelen van de inhoud die wordt gepresenteerd. De informatie wordt vaak gedownload van een server of backend en opgenomen in de UI, ook al is de gebruikersinterface een onderdeel van de code van de app. Dit is het gebruikelijke geval voor een releasecyclus bij een update.
Beschouw het geval waarin ontwikkelaars enkele belangrijke wijzigingen van de gebruikersinterface aan de app moeten toevoegen. Zoals we hierboven hebben vermeld, moeten ontwikkelaars een hele releasecyclus doorlopen om deze wijzigingen door te voeren. Dit komt omdat de logica die dicteert hoe de informatie wordt weergegeven, is geïntegreerd in het startscherm van het programma. Nadat ze in deze releasecyclus de nodige verbeteringen hebben aangebracht, moeten ze nog een ronde van beoordeling, testen en goedkeuring door de Play Store doorlopen. Als uw app op zowel het iOS- als het Android-platform moet worden uitgebracht, moet de releasecyclus twee keer worden doorlopen. Dit kan een lang proces zijn, en u zult waarschijnlijk aparte ontwikkelaars nodig hebben voor de twee platforms, omdat ze in verschillende talen moeten worden gecodeerd. Tegen de tijd dat zelfs kleine UI wijzigingen uw gebruikers bereiken na de release cyclus, kan het maanden duren.
Verschil met client-side rendering
Traditionele ontwikkeling maakt gebruik van client-side rendering. Hierbij worden het ontwerp van de pagina, CSS en JavaScript opgehaald nadat de client een verzoek heeft gedaan. Soms wordt bepaalde inhoud niet opgenomen, waardoor JavaScript extra verzoeken moet uitvoeren om de benodigde HTML te kunnen produceren.
Deze aanpak heeft zijn voordelen, maar kampt met het bovengenoemde probleem als het gaat om updates. Toch kan het soms nuttig zijn. Als slechts een klein deel van de website is gewijzigd bij gebruik van client-side rendering, hoeft bijvoorbeeld niet de hele pagina opnieuw te worden gerenderd. Client-side UI rendering zorgt ervoor dat alle noodzakelijke gegevens volledig zijn geladen. Hierdoor wordt client-side UI vrij snel en responsief. Client-side rendering maakt het ook mogelijk gebruikers interactief te benaderen.
Voor server-side rendering is het noodzakelijk om hetzelfde script aan zowel de client- als de serverzijde van de app te houden, wat kan leiden tot hogere operationele kosten en vertraging van de ontwikkeling. Gebruikersvriendelijke client-side toepassingen bieden een hoge mate van prestatie. Maar alleen als de noodzakelijke JavaScript-scripts klaar zijn met laden. Daarom kunnen er bij het gebruik van mobiele telefoons en een trage internetverbinding bij dergelijke toepassingen enige prestatieproblemen optreden. De verscheidenheid aan beschikbare mobiele apparaten maakt het ook moeilijk te voorspellen hoe client-side rendering zal functioneren. Ontwikkelaars bouwen client-side UI met behulp van bibliotheken als Ember.js, backbone.js, en meer.
Voordelen van server-gestuurde UI
Het eindproduct van een server-gedreven gebruikersinterface ziet er niet anders uit dan een client-side UI. Dus wat zijn de voordelen die SDUI biedt?
Snelle updates
SDUI heeft tal van voordelen wanneer ontwikkelaars updates van een app moeten maken. De releasecyclus van een nieuwe update kan tot weken duren. Dit kan worden versneld met SDUI. Engineers hoeven alleen de backend of een server-side upgrade te gebruiken. Ze hoeven het niet te testen omdat ze geen nieuwe code maken. De release cyclus hoeft de bijgewerkte versie van de app ook niet in te dienen bij app stores zoals de Google play store. Er is dus geen goedkeuring nodig van Apple of Google. Wijzigingen die vroeger maanden of weken duurden, kunnen nu in enkele uren of dagen worden doorgevoerd. Deze wijzigingen in de releasecyclus gelden zowel voor een iOS-app als voor een Android-app, aangezien de wijzigingen rechtstreeks op de server worden aangebracht.
Gemakkelijker te implementeren
De backend- of servergestuurde strategie is doorgaans eenvoudiger als ontwikkelaars een statische webpagina maken. Ze hoeven zich ook niet druk te maken over mogelijke SEO zorgen omdat de website statische HTML maakt, waardoor zoekmachines hun materiaal kunnen zien. Door de browser minder werk te geven, vermindert u ook de kans op onvoorziene bugs.
Gemakkelijker indexeren van sociale media
Net als crawlers van zoekmachines hebben bots van sociale media moeite met het verwerken van JavaScript-materiaal. Twitter Cards ondersteunen bijvoorbeeld geen rendering aan de clientzijde. De server-side rendering aanpak kan de voorkeur hebben als het delen van sociale netwerken een belangrijk onderdeel is van uw marketingplan. Server-gestuurde rendering van een app is ook minder complex en veiliger. Laten we dit in detail bekijken.
Minder complexiteit
Onder bepaalde voorwaarden kan het gebruik van back-end of server-gestuurde gebruikersinterface-ontwikkeling veel minder complex zijn dan de front-end en back-end afdelingen. Vanuit het perspectief van een ontwikkelaar vermindert servergestuurde UI-ontwikkeling de cognitieve stress. Zonder rekening te hoeven houden met twee programmeeromgevingen kan de ontwikkelaar zich meer concentreren op de toegevoegde waarde van de applicatie die hij maakt. De eliminatie van doublures vermindert ook de complexiteit van deze toepassingen aanzienlijk. De backend API-software en de UI-software hoeven niet te worden geïdentificeerd, omdat de verificatielogica op één plaats wordt afgehandeld.
Beveiliging
Servergestuurde UI-ontwikkeling maakt zijn specificaties nooit zichtbaar voor de browser en levert alleen de precieze gegevens die nodig zijn om de gebruikersinterface te veranderen. In vergelijking met het scenario waarbij programmeurs de juiste gegevens voor een bepaald UI-contact doorgeven, is dit een intrinsiek veiligere ontwikkelingsstrategie. Daardoor zullen API-eindpunten niet te veel informatie vrijgeven aan de JavaScript-browser. Dit maakt het moeilijker voor een hack of inbreuk op gegevens. Dit is zeer belangrijk voor het behoud van de reputatie van een bedrijf en van vitaal belang voor de bedrijfslogica.
Full-stack teams
Ontwikkelingsteams worden vaak opgesplitst in verschillende teams. Dit vereist een zekere mate van integratie van de verschillende softwareonderdelen zodra de afzonderlijke onderdelen klaar zijn. Een strikte scheiding tussen frontend en backend kan leiden tot een zekere mate van ontkoppeling tussen de teams, aangezien de verschillende gebieden gespecialiseerde kennis vereisen. Dit maakt het moeilijker voor ontwikkelaars om de volledige end-to-end bedrijfslogica te overwegen, omdat ze slechts verantwoordelijk zijn voor één deel.
Als je een full-stack engineer bent, is dit veel gemakkelijker om mee om te gaan. De mogelijke nadelen of voordelen van de UI-componenten zijn gemakkelijk te begrijpen. Full-stack teams kunnen server-gedreven UI-ontwikkeling implementeren, en de behoefte aan integratie kan tot op zekere hoogte worden verminderd.
Server-gestuurde UI nadelen
Hoewel het gebruik van backend of server-driven rendering een rechtlijnig concept lijkt, neemt de diepgang van het idee toe naarmate de complexiteit van de applicatie en de bedrijfslogica toeneemt, zijn enkele van de belangrijkste nadelen van server-driven gebruikersinterfaces:
Langere laadtijd
Het fundamentele nadeel van een server-gestuurde rendering is dat de server of de backend voor elke verbinding met een client een nieuwe webpagina aanmaakt. De client moet dan opnieuw toegang krijgen tot deze pagina. Een dergelijke activiteit kan leiden tot een gebrek aan responsiviteit en een grote toename van de laadtijden. Hoewel backend of server-side rendering goed is voor het maken van statische HTML-sites, kan het de weergave van de webpagina of het startscherm in meer ingewikkelde toepassingen vertragen vanwege de regelmatige serveraanroepen.
Duurder
U moet een server of een serverloze backend aanschaffen om een servergestuurde toepassing te starten, wat resulteert in hogere bedrijfskosten. Het proces kan duur zijn en veel middelen vergen, omdat servergestuurde rendering niet de standaard is voor JavaScript-webpagina's. Voor kleinere bedrijven kan het moeilijk zijn om geld te sparen voor dergelijke servers.
Incompatibiliteit en grotere HTML-grootte
Server-side rendering is niet compatibel met sommige tools en programma's van derden. Server-gestuurde toepassingen hebben ook een grotere HTML-grootte als gevolg van de geïntegreerde hydratatievoorwaarde. Hier moet rekening mee worden gehouden, aangezien het een mogelijk risico is als het verkeerd wordt toegepast.
Geschiedenis van server-gestuurde UI
Computers waren massaal, duur, en voornamelijk in gebruik bij grotere bedrijven in de jaren 1960 en 1970. Omdat het ondoenlijk was voor elke gebruiker een computer ter breedte van een kamer te hebben, werd de mainframetechnologie gecreëerd, waardoor meerdere mensen een computersysteem konden gebruiken. De gebruikersinterface, die werd gecreëerd met behulp van de output van berekeningen met terminalopdrachten, werd vervolgens teruggestuurd naar de monitoren voor presentatie. Deze terminals werden de eerste thin clients. Thin clients werden zo genoemd vanwege hun uiterst beperkte rekenkracht en hun afhankelijkheid van een externe machine om de gebruikersinterface te produceren.
De personal computer ontstond als gevolg van de ontwikkeling van de microprocessor eind jaren zeventig, waardoor de prijs en de omvang van computers drastisch daalden. Toepassingen werden gedownload en werkten op de browser van elke gebruiker afzonderlijk. De PC was een zelfstandige computer die was uitgerust met alle noodzakelijke componenten voor de weergave van de gebruikersinterface. Deze volledig autonome werkstations waren de eerste thick clients.
Websites of een toepassing die met een webbrowser werden bekeken, konden veel van de voordelen van de thin client genieten dankzij de ruime beschikbaarheid van het internet in de jaren negentig. Iedereen die een webbrowser en een internetdienst had, kon gebruik maken van de rekencapaciteiten die zich centraal bevonden op speciale computers, de zogenaamde servers. Met behulp van HTML, een standaard opmaaktaal, maakten de servers de gebruikersinterface-app en stuurden die door naar de webbrowser van de gebruiker. Webbrowsers moesten op elke browser op afstand worden ingesteld, maar ze hadden veel minder behoefte aan prestaties en konden vaak de operationele problemen van een organisatie oplossen.
Mobiele telefoons begonnen in de jaren 2000 vooruitgang te boeken en konden zelfstandig toepassingen uitvoeren. Bij gebruik van een mobiele telefoon als thin client om webpagina's te bekijken, moest de server of de backend de hele gebruikersinterface-app via het internet naar de telefoon sturen, net als bij personal computers. In die tijd waren mobiele netwerken echter traag. Het was dus frustrerend om webpagina's te bekijken.
Toen de iPhone in 2007 op de markt kwam, betekende dat een revolutie in wat men met een smartphone kon doen. De iPhone kwam met een complete set geïnstalleerde programma's in plaats van dat gebruikers software moesten aanschaffen via websites of een applicatie. Apple introduceerde de App Store, en Android nam de Google Play Store over, waardoor externe ontwikkelaars applicaties konden maken. Deze apps boden een veel betere gebruikerservaring omdat alles wat nodig was om de UI te tonen in de applicatie was opgenomen en zonder internetservice kon worden gebruikt.
Softwaredistributie heeft de afgelopen veertig jaar afgewisseld tussen thin en thick clients, waarbij native apps, die thick clients zijn, de boventoon voeren op mobiel. Sommige van de voordelen van de thin client worden door SDUI uitgebreid naar native apps. Met een SDUI-ontwikkelingsstrategie kunnen de servers delen van de gebruikersinterface van een native app aansturen en via het web naar de smartphones van de gebruikers sturen. De UI binnen een native applicatie kan snel worden gewijzigd zonder dat een nieuwe versie van de software moet worden geïnstalleerd.
Frameworks en tools voor servergestuurde ontwikkeling
Terwijl de server een servergestuurde rendering van een applicatie uitvoert, wordt de rendering aan de clientzijde uitgevoerd door de browser. Er zijn momenteel verschillende frameworks beschikbaar, en enkele van de meest gebruikte zijn:
Het is een gratis en open-source JavaScript UI framework dat gecombineerd kan worden met bepaalde andere tools om een full-stack ontwikkelomgeving voor online applicaties te creëren.
Het is een JavaScript-toolkit waarmee herbruikbare user interface app-elementen kunnen worden gemaakt en hun eenvoudige samenstelling om enorme, zeer schaalbare programma's te bouwen.
- Angular
Angular Universal is een backend of server-gedreven ontwikkelingstool.
Server-gestuurde UI en AppMaster
Tegenwoordig kunt u zelfs met zeer weinig of bijna geen coderingservaring een app en programma's bouwen. Dit is mogelijk met behulp van no-code platforms en tools. Met dergelijke platforms kunnen zowel ontwikkelaars als niet-programmeurs een software-app maken met behulp van gebruikersinterfaces en configuratie in plaats van traditionele computerprogrammering. No-code heeft het ontwikkelen van software gemakkelijker en toegankelijker gemaakt.
Dit wordt mogelijk gemaakt met behulp van no-code platforms zoals AppMaster. Met AppMaster kun je nu zelfs zonder codeerervaring een app ontwerpen. Je hoeft je ook geen zorgen te maken over de rechten van de broncode die je maakt - die is van jou. Deze code kan ook snel worden gegenereerd.
De servergestuurde strategie van AppMaster maakt realtime app-updates mogelijk. Je hebt direct toegang tot de hardware van apparaten zoals iPhones en iPads met een backend of server-gedreven UI. Uw app komt bijna 10 keer sneller op de markt dan met traditionele ontwikkeling en UI-updates. U kunt het nut van backend-gestuurde UI-ontwikkeling benutten met AppMaster.
Conclusie
De uiteindelijke vraag of server-gedreven ontwikkeling geschikt is voor uw applicatie hangt af van de functionaliteit. Als uw app dynamisch is en veel elementen heeft, dan is SDUI misschien een goed idee voor u. Naast de bovengenoemde voordelen helpt het websites en applicaties ook met SEO rankings. Het is belangrijk om de voor- en nadelen van server-driven user interface ontwikkeling te begrijpen voordat je het implementeert. SDUI heeft soms meer middelen nodig, en je moet in staat zijn die te leveren als je hetzelfde gebruikt.
Als u gewoon een statische website wilt bouwen, die u snel wilt laden, dan is het gebruik van eenvoudigere client-side ontwikkeling misschien beter voor u. Uiteindelijk moet u de behoeften van uw applicatie en de bedrijfslogica die u implementeert beoordelen en beslissen of backend of server-gestuurde ontwikkeling geschikt is voor u.
