Real Time Web & Apps jungle

Inleiding

Veel apps communiceren met servers op het internet. Traditioneel doen ze dat via web services. Dit is vrij simpel in te bouwen in apps en de benodigde libraries zijn beschikbaar op alle platforms. Het ontwikkelen van een eigen web service is echter een ander verhaal. Als back end ontwikkelaar leek dit me een goede basis voor samenwerking met app- en front end ontwikkelaars. Maar toen hoorde ik over Meteor.com.

Het framework Meteor.com trekt momenteel veel aandacht met verrassend simpele clients. Het zou revolutionair zijn omdat het het werkingsprincipe van het real time web radicaal doortrekt vanaf de web based GUI tot en met de onderste laag aan de serverkant. Maar het is helemaal gericht op javascript (ook op de server). Vraag je je af wat er mogelijk is in andere omgevingen, waar onder de diverse app platforms, dan kom je terecht in een jungle van frameworks en technieken. Omdat er op appril geen inleidende lezing is over het Real Time Web heb ik geprobeerd om zelf wat orde te scheppen. Om de omvang binnen de perken te houden heb ik mij geconcentreerd op open source. Het scheelt dat ik toevallig de achterliggende werkingsprincipes ken omdat een van mijn toenmalige medewerkers eind jaren 90 een onderzoeksproject gedaan met een vergelijkbare techniek, maar het blijft een eerste verkenning van iemand zonder hands on ervaring.

Real time web

Het is geen toeval dat de real time techniek het eerst op het web tot wasdom komt. Webgebaseerde applicaties vervullen duidelijk in een behoefte, maar de techniek is van oorsprong trager dan de lokaal geïnstalleerde 'native' tegenhangers. Daarom zijn web ontwikkelaars altijd op zoek naar technieken om meer snelheid te krijgen. AJAX is zo'n techniek en is inmiddels al helemaal ingeburgerd. Maar AJAX kent ook zijn beperkingen. Dit komt omdat het nog steeds is gebaseerd op de traditionele webservertechniek van "1 vraag van de client, 1 antwoord van de server". Dit past goed bij het procedurele programmeren waar de meeste programmeertalen (gedeeltelijk) op zijn gebaseerd en werkt goed met relatief statische content en traditionele applicaties. Maar met de komst van sociale netwerken, user generated content en genetwerkte organisaties begint dit model te knellen, bij multi player games is het eigenlijk al achterhaald.

Door het beschikbaar komen van WebSockets in de belangrijkste browsers wordt het mogelijk om sneller ongevraagde updates van de server te verwerken. Je krijgt dan stromen van qua timing niet aan elkaar gerelateerde (asynchrone) berichten in twee richtingen tussen de client en de server. Let op, het gaat hier niet om e-mail berichten of SMS-jes en ook niet om notifications zoals Andoid en iOS die kennen, deze berichten zijn namelijk niet bedoeld voor mensen, maar voor software. Het lijkt nog het meest op events. Op die manier zijn ze dan ook binnen je programma af te handelen.

Protocollen en basale frameworks

In de praktijk werken de meeste GUI's al met events. Het past dus eigenlijk juist goed bij hoe tegenwoordig front ends en apps worden ontwikkeld. Mits het onderliggende nivo van sockets, verbindingen, dataconversie en verzending voor de applicatie-ontwikkelaar wordt afgeschermd. Dat is wat de SockJS, Socket.IO en CometD doen. Daarvoor implementeren ze hun een eigen protocol (communicatietaal). Je moet dus zowel op de client als op de server hetzelfde framework gebruiken. Maar verder zijn ze niet echt gelijksoortig:

  • SockJS lijkt me qua api eigenlijk maar een dun laagje rond de WebSockets maar zorgt er wel voor dat het werkt op diverse browsers en hun versies (en zelfs op browsers zonder WebSockets, maar dan trager - dat doen de andere frameworks overigens ook). Ik vraag me af of dit voldoende is om de ontwikkelaars van client-applicaties af te schermen. Maar je hebt wel een redelijke keuze aan server platforms.
  • Socket.OI doet duidelijk meer: ontvangstbevestiging, verspreiding over meerdere ontvangers (publish & subscribe). Het biedt bovendien veel keus qua clients, waaronder ook de belangrijkste platforms voor native apps. Maar aan de kant van de server werkt het alleen op node.js. Dit biedt standaard al de mogelijkheid om binnen de server en met de database met asynchrone berichten werken. Maar daar komt een stuk meer bij kijken dan bij de client-server communicatie, bijv. threads, message queues en authorization. Het bevat bovendien een http server.
  • CometD was er van oorsprong op gericht om wat we nu WebSockets noemen te simuleren, maar werkt nu ook via WebSockets. Het heeft een geformaliseerd protocol genaamd 'Bayeux' en er zijn ook diverse andere frameworks die daar mee werken en dus onderling en met CometD uitwisselbaar zouden moeten zijn. CometD werkt op de client in javascript en op de server in een Java Servlet container. Het implementeert zelf asynchonous messaging en aanvullende technieken op de server.

Server side messaging en cross stack

Er zijn diverse andere frameworks die ofwel één of meerdere van de protocollen van bovenstaande frameworks implementeren, of als een laag bovenop de eerder genoemde frameworks zijn gebouwd, en dan net als CometD daar zo nodig zelf de server side asynchronous messaging en aanvullende technieken zoals message queues en authorization en een http server aan toevoegen. Dit leidt uiteindelijk tot een nieuwe manier van programmeren (reactive programming). Wie gewend is aan procedureel programmeren kan zich daar misschien weinig bij voorstellen, maar in principe zou je een compleet programma kunnen schrijven dat uitsluitend werkt met asynchrone berichten. Met een concept dat zo krachtig is lijkt het me heel goed denkbaar dat je revolutionaire applicatiegerichte cross stack frameworks kunt maken die het ontwikkelen van applicaties relatief simpel te maken. Maar hoe ver de onderstaande frameworks daar werkelijk mee zijn kan ik zo snel niet natrekken:

  • Meteor.com heb ik in de inleiding al genoemd. Het implementeert Bayeux en werkt aan de serverkant op node.js. Het is nog een beta versie.
  • Derby.js werkt ook op Node.js maar is gebouwd op diverse populaire libraries: Express, Socket.IO, Browserify, Stylus, LESS, UglifyJS. Er wordt beweerd dat het lijkt op Meteor.com, maar dat kan ik niet natrekken. Het is nog een alpha versie.
  • Faye implementeert Bayeux, werkt op node.js, maar ook op Ruby. Versienummers zijn 0.n dus alpha of beta.
  • Vert.x gebruikt SockJS en werkt met diverse talen op de Java Virtuele Machine: Java, Ruby, Python, Groovy. De term 'Verticles' suggereert dat ook hier sprake is van een applicatiegericht cross stack framework. Versienummers zijn 1.n, beta versies hebben toevoeging 'beta'
  • Atmosphere implementeert het Socket.IO protocol in Java op de server maar ook CometD/Bayeux. Het zou goed samenwerken met bestaande populaire (op http gerichte) applicatieframeworks. Versieummers zijn 1.n, beta versies hebben toevoeging 'beta'.

Hosted Message Services

Een heel andere benadering die veel gemakkelijker is in te passen in bestaande code en platforms is denk ik het gebruik van Hosted Messaging Services. Deze bieden kant en klare publish en subscribe diensten via de cloud. Je zou dat redelijk simpel kunnen aansturen vanaf traditionele webservices en webserver applicaties. De diverse commerciële providers bieden de nodige ondersteuning, ook voor server en native app platforms. Zie verder deze lijst van Hosted Message Services.

Conclusies

Alle frameworks hebben cross browser clients in javascript. Soms wordt ook expliciet de werking in web-apps (HTML5, PhoneGap) genoemd. Ik neem aan dat ze ook clients hebben in de programmeertalen van de server-platforms waar ze op werken. De keus aan server platformen is echter beperkt. Wil je dat het werkt met native apps dan moet je kiezen tussen Socket.IO en zelf direct op de sockets iets bouwen. Dat laatste lijkt me niet reëel voor de gemiddelde app ontwikkelaar, ook al zou je in het geval van Andoid de SockJS code van Vert.x kunnen proberen te porten. Maar ook met Socket.IO blijft het nog behoorlijk low level. Het lijkt me onwaarschijnlijk dat de meer applicatiegericht cross stack uitbreidingen van Derby.js of Vert.x zomaar met de GUI toolkits van native apps gaan werken. Met native apps blijft real time messaging met open source dus nog wel even pionieren. Dit zou anders kunnen zijn met de commerciële producten, zie onderaan, maar die heb ik eigenlijk nauwelijks onderzocht.

Een heel andere benadering die veel gemakkelijker is in te passen in bestaande code en platforms is denk ik het gebruik van Hosted Messaging Services. Dit lijkt me makkelijk inpasbaar binnen bestaande apps, webservices en websites. Maar daarmee blijft het wel iets dat je 'erbij' doet voor specifieke doelen die op andere manieren lastiger te realiseren zijn. Dat maakt het ook zo makkelijk inpasbaar. Dat is geen probleem voor de meeste marktgedreven toepassingen van nu. Maar als de cross stack frameworks echt zo revolutionair zijn als wordt beweerd dan zullen ze waarschijnlijk de voedingsbodem worden voor hele nieuwe soorten toepassingen die nu gewoon nog niet worden bedacht. Dat lijkt me toch op zijn minst iets om in de gaten te houden.

 

Links

Andere overzichten:

Commerciële producten (Dit gedeelte bevat citaten van de websites van de leveranciers):

  • WebORB Integration Server is complete framework and toolset for distrubuted applications, maar het is geen open source. Cient support depends on which server platform you choose. There also is a product for mobile, but it is not clear how it combines with server platforms. (http://www.themidnightcoders.com/products/ )
  • WebSync is a highly scalable HTTP streaming (comet) server built for the Microsoft stack (.NET/IIS) using the Bayeux protocol. Community edition is only for non-commercial use. WebSync includes client libraries for JavaScript, iOS, Java, Mac OS X, Mono, Mono for Android, MonoTouch, .NET, .NET Compact, Silverlight, Windows Phone, and Windows 8, as well as server support for Mono, .NET, and PHP.

Sponsored link:

  1. applicatie back-ends voor startups met supplier funding

Dit artikel is gescheven dd 12-4-2013 door Henk Verhoeven in het kader van appril 2013.

Reacties

Bart van Vliet
op Webdevelopment Nederland op LinkedIn
15-04-2013 17:59:00
 
Ik heb om een beetje gevoel te krijgen met deze technieken simpele webapplicaties gemaakt mbv node.js, backbone,angular en meteor.

De keuze is inderdaad ruim, zij het nog weinig volwassen/ondersteunde oplossingen. Vele javascript frameworks leunen sterk op node, maar ook HTML5 heeft een native websocket. Daar kun je samen met local storage de werking van Meteor nabootsen.

Meteor vond ik echter simpel en snel werken, ook omdat veel modules (login, backbone, bootstrap enz.) direct beschikbaar zijn. Dit gaat sneller dan het handmatig onderhouden van een websocket. Ook de koppeling met MongoDB is sterk (JSON input/output).

Het realtime-element gebruik ik alleen voor het deel waar dat nodig is. Frameworks als angular/knockout/ember voor de frontend en met node.js kun je via REST je eigen backend framework aansturen. Je CMS/User management kun je dus via "gewoon" een PHP (Laravel 4 !!!)/.net/Java framework doen. Voor PHP is ook een websocket beschikbaar: Ratchet.

Een dienst als Pusher ziet er veelbelovend uit, hier heb ik helaas geen ervaring mee. Ik denk dat je je als webdeveloper beter kan richten op de Javascript-oplossingen. Phonegap, Windows 8 apps, vele API's (facebook, twitter, spotify) werken allemaal met Javascript/Json, of ondersteunen dit.
Henk Verhoeven
op Webdevelopment Nederland op LinkedIn
16-04-2013 11:35:39
 
Bedankt voor de aanvulling. Voor PHP heb ik een basale websockets implementatie gevonden, een incomplete sockets.io implemetatie en twee uitgebreidere frameworks (photon-project.com en reactphp.org). Ze combineren echter geen van alle met Apache, zodat het op de meeste hosting accounts vermoedelijk niet bruikbaar zal zijn. Ik ben benieuwd of Ratchet daar een oplossing voor biedt.
Henk Verhoeven
www.metaclass.nl
15-02-2014 10:41:43
 
Op dit moment ben ik met wat andere dingen bezig, maar op GroningenPHP hoorde ik over Iron MQ (Hosted Message Service). De vergelijking op www.iron.io/mq#comparison is op zichzelf al interessant omdat het een zekere ordening aanbrengt.

Verder lijkt de lijst op www.leggetter.co.uk/real-time-web-technologies-guide een stuk langer te zijn geworden. En ik vond queues.io, een lijst van populaire message queues.

(28-2-2014) En op AmsterdamPHP hoorde ik over Reactphp, voor asynchroon programmeren in PHP. 20 maart is daarover een presentatie op de meetup van AmsterdamPHP. slides: https://speakerdeck.com/wyrihaximus/having-async-fun-with-reactphp
Reageer
Loading form, please wait