De terugkeer van client-server computing?

Een van de dingen die ik de afgelopen maanden interessant vond in de ontwikkelingswereld, is hoe moderne applicaties teruggaan naar het plaatsen van meer intelligentie in de client in plaats van de server. Het client-server-model is natuurlijk niets nieuws: het is de manier waarop traditionele applicaties al jaren zijn gebouwd, met rijke client-applicaties die met server-side applicaties praten. Maar in het tijdperk van het web, en zelfs Web 2.0, ging de aandacht naar webtoepassingen waarbij het grootste deel van de intelligentie op de webserver lag (meestal in op Java gebaseerde applicatieservers) en de client gewoon een eenvoudige webpagina was in een browser waarin u elke keer dat u klikte een nieuwe pagina laadde.

Maar recentelijk leidt de rijping van HTML5, CSS, en met name JavaScript, ontwikkelaars ertoe om echte intelligentie en echte verwerking in de webpagina zelf te plaatsen. We hebben met name de opkomst gezien van een verscheidenheid aan client-side JavaScript-gebaseerde frameworks die het eenvoudiger maken om intelligente front-ends te maken die volledig binnen een moderne webbrowser worden uitgevoerd. De betrokken browsers zijn meestal die gebaseerd op de Webkit-engine, inclusief Chrome en Safari, maar de meeste apps lijken ook goed te werken in de huidige versies van Firefox en Internet Explorer. U eindigt met een complexere webpagina die dynamisch verandert en gegevens van de server haalt als dat nodig is.

Met name drie MVC-frameworks lijken de meeste aandacht te trekken: Backbone.js, Ember.js en Angular.js. (MVC staat voor model-view-controller - het is in wezen de architectuur achter webclient computing. De "js" staat voor JavaScript.) In wezen is dit allemaal een uitvloeisel van de AJAX (Asynchronous JavaScript en XML) -benadering populair in het afgelopen decennium of dus, maar veel volwassener en bijna gestandaardiseerd. Het idee is om meer van de status en intelligentie in de browser te plaatsen en vervolgens de browser verbinding te laten maken met REST API's aan de serverzijde.

Backbone is misschien wel de meest basale en minimale van deze frameworks; het wordt in verschillende mate gebruikt door veel populaire sites. Ember is gegroeid uit een framework met de naam Sproutcore dat door Apple wordt ondersteund, en is een veel uitgebreider framework dat is ontworpen om je desktop-achtige applicaties te laten doen. Het wordt vaak gebruikt met Bootstrap - een set sjablonen voor HTML en CSS die oorspronkelijk zijn gemaakt door Twitter-medewerkers. Angular is het alternatief van Google dat ergens tussenin lijkt te liggen - sommige mensen denken dat het een beetje flexibeler of op zijn minst "minder eigenzinnig" is dan Ember, maar uitgebreider dan Backbone. (Merk op dat Google ontwikkelaars ertoe aanzet Angular te gebruiken om de kwaliteit van de codering te verbeteren, maar gebruikt intern feitelijk een andere, eigen set van frameworks.) Zelfs Microsoft heeft haken toegevoegd aan Visual Studio voor deze frameworks.

Aangezien dit het web is, zijn er tientallen alternatieven. Een van de interessantste die ik de laatste tijd heb gehoord, is Meteor, ontworpen om te werken met JavaScript aan zowel de client- als de serverzijde. Maar dit is nog heel vroeg en ik ken nog geen echte gebruikers. Ondertussen spelen meer ontwikkelaars met Node.js, vaak gebruikt voor server-side JavaScript-implementaties.

Het voordeel van dergelijke kaders lijkt duidelijk. Rijke webclient-applicaties zijn krachtiger dan thin client-applicaties waarbij alles op de server draait, ze kunnen een betere gebruikersinterface bieden en bieden de mogelijkheid van offline informatie. Met behulp van deze frameworks kunt u veel snellere webclienttoepassingen maken dan u zou kunnen door alles vanaf nul te bouwen en te profiteren van de community's die zich rondom hen ontwikkelen.

Misschien het belangrijkste is dat u mobiele applicaties kunt maken die op verschillende apparaten kunnen worden geschaald zonder dat u specifieke native applicaties hoeft te schrijven. Er is nog steeds een goed argument te maken voor native apps, die meer gericht kunnen zijn op de specifieke functies van elk platform. Veel ontwikkelaars hebben echter ontdekt dat dergelijke frameworks de platformoverschrijdende ontwikkeling dramatisch kunnen versnellen, vooral wanneer ze worden gebruikt in combinatie met dingen zoals PhoneGap, een open source mobiel framework dat is aangekocht door Adobe en open source is voor het Apache Cordova-project.

Mobiel brengt natuurlijk zijn eigen beperkingen met zich mee, waaronder de snelheid van de processors, en misschien nog belangrijker, de snelheid van - en soms gebrek aan - connectiviteit. Een reden waarom mensen apps op webpagina's leuk vinden, is dat je vaak de basisfunctionaliteit via Wi-Fi of een snelle verbinding kunt downloaden en alleen de gegevens kunt downloaden die je nodig hebt, niet het hele ontwerp. Pakketten zoals PhoneGap lossen dit probleem op door JavaScript in een gedownloade app te plaatsen.

Er zijn echter andere problemen met dergelijke kaders. Per definitie verhoogt meer computergebruik aan de client-zijde de complexiteit ten opzichte van een eenvoudige server-only app, en inderdaad, sommige van de nadelen van het oude client-server-model komen terug. Ontwikkelaars moeten de staat aan beide kanten beheren. Code op twee plaatsen betekent dat u zich op beide plaatsen op beveiliging moet richten. Aangezien een ontwikkelingsteam vaak sommige mensen op de client en anderen op de server heeft, krijgt u extra communicatieproblemen. Aan de andere kant komen sommige van de oudere problemen van client-server niet terug en behoudt u in plaats daarvan de voordelen van websoftware. Dit is een veel meer op standaarden gebaseerde, gemeenschapgestuurde wereld, dus je bent niet zo afhankelijk van een enkele eigen omgeving. Door de client- en server-side delen te splitsen, kunt u ook een schonere, eenvoudigere server-side implementatie hebben die alleen de verwerking uitvoert en geen UI, en daardoor mogelijk minder resources nodig heeft. Toch hebt u nog steeds het voordeel dat u alle clients tegelijk kunt bijwerken, omdat de browser meestal de code van de server laadt wanneer de app wordt aangeroepen.

We zien duidelijk een beweging in de richting van intelligentere webclients - niet in alle gevallen, maar in veel nieuwe toepassingen. Het is veel moeilijker om oudere applicaties te nemen en ze naar dit model te verplaatsen, maar we zien daar ook wat van terug. Het is niet helemaal het oude client-server-model, maar het komt veel dichterbij.