Makkelijker realtime offline-first apps bouwen met Realm Mobile Platform

We vragen ons steeds af hoe allerlei technologieën gekoppeld worden tot een werkend geheel. Hoe blijft zo’n webplatform onderhoudbaar op lange termijn voor ontwikkelaars? Wat gebeurt er tijdens database-migraties? Hoe zorgt men ervoor dat een mobiele gebruiker vlekkeloos een app kan blijven gebruiken wanneer updates worden uitgerold op de back-end? Hoe worden gegevens zo efficiënt mogelijk overgebracht, gecached en hoe wordt deze cache up-to-date gehouden? Voor al deze vragen bestaat er een oplossing, maar is dit nu eigenlijk de beste? Daarom moeten we onze kennis steeds bijschaven en regelmatig nieuwe technologieën leren kennen. Eén van die nieuwkomers is Realm.

Het internet en de daarop berustende technologieën maakten de laatste jaren een enorme evolutie door. Applicaties verplaatsen zich meer en meer van de browsers op onze computers naar onze smartphones en dit brengt grote gevolgen met zich mee onder de motorkap van een native app. Smartphones zijn mobiele toestellen waarvan de meest fundamentele functie het gebruik van het toestel onderweg is, waar meestal geen Wi-Fi-verbinding voorhanden is. Wanneer een traditionele browserapplicatie data wil ophalen of pushen van en naar de webserver, dan zal de browser een verbinding moeten maken met de server van de applicatie, maar dit berust natuurlijk op een betrouwbare internetverbinding, een afhankelijkheid die bij mobiele toestellen verre van vanzelfsprekend is. App-ontwikkelaars moeten hier rekening mee houden en een manier vinden om de afhankelijkheid van het internet te gaan verkleinen.

Zonder internetverbinding is een traditionele app volkomen onbruikbaar, er is namelijk geen toegang tot de webserver die de gebruikersinterface en alle data aanbiedt. Er kan dus helemaal niets getoond worden aan de gebruiker. Maar om aan de hedendaagse verwachtingen te voldoen moet een app ook zonder internetverbinding relatief functioneel blijven, zoals het kunnen bekijken van de recent getoonde informatie. Native apps zijn als software op een computer: ze zijn lokaal geïnstalleerd op het toestel en bevatten de volledige gebruikersinterface en alle logica om te weten waar alle vereiste data vandaan gehaald kan worden. De interface van een app is dus steeds beschikbaar. Hoe dan ook moet er nog steeds een internetverbinding zijn om toegang te krijgen tot die data. De oplossing hiervoor heet caching; het tijdelijk bijhouden van informatie voor later gebruik.

Caching voegt een tussenstation toe in de data access layer (DAL) van de applicatie. De app zal niet langer alle data rechtstreeks van de server ophalen, maar wel uit een cache die op het toestel wordt opgeslagen. Die lokale cache wordt dan actueel gehouden door de app, zodat de informatie die getoond wordt in de app zo up-to-date mogelijk is. Regelmatig moet de lokale cache dus gesynchroniseerd worden met de server wanneer een verbinding wel voorhanden is.

Een goed opgebouwde app zal dus zorgen dat een versie van alle basisdata steeds beschikbaar is op het toestel zelf, zodat de gebruiker toch nog iets kan doen met de app, bijvoorbeeld een reactie plaatsen op een bericht. Die handeling wordt dan ook in de cache opgeslagen, als een soort wachtrij van acties die moeten uitgevoerd worden van zodra er terug internettoegang is. Dergelijke apps zijn gebouwd volgens het offline-first principe. Een offline-first ervaring bevordert tevens de gebruikservaring: de gebruiker moet minder lang wachten op data, want die is al beschikbaar (bij de meeste apps wordt de cache in de achtergrond bijgewerkt, wanneer de app niet actief is). Zonder offline-first betekent geen verbinding meteen dat men minder productief wordt, bepaalde acties niet kan uitvoeren of iets niet kan tonen aan een klant. Ook kan men belangrijke data verliezen bij een slechte verbinding. Een actie kan bijvoorbeeld mislukken zonder dat de gebruiker ervan op de hoogte gebracht wordt. Dit kan tot heel wat problemen leiden.

Helaas is een mobiele dataverbinding verre van hetzelfde als een Wi-Fi-verbinding, en lopen de kosten ervan hoog op naarmate het verbruik stijgt. Mobiele netwerken zijn ook niet even betrouwbaar. Telkens alle data opnieuw downloaden om de cache bij te werken is dus geen goed idee. Beter is het om enkel de wijzigingen (delta’s) in de gegevens over te maken. Zo moet er minder data verstuurd worden. Een item uit een bepaalde dataverzameling op een toestel kan toegevoegd, gewijzigd of verwijderd zijn. Het communiceren hiervan naar de server of andere toestellen moet natuurlijk correct gebeuren zodat de hele verzameling consistent blijft. Wanneer een verzameling of een item uit een verzameling werd aangepast op meerdere instanties, zijn er dus meerdere versies van die verzameling ontstaan die samengevoegd moeten worden tot de definitieve versie. Dit heet men mergen, en dit gebeurt vaak niet zonder merge conflicten, bijvoorbeeld bij een fout ontvangen volgorde van operaties tijdens het synchroniseren. Daarom is er nood aan een goede synchronisatiestrategie.

Een gebruiker kan bijvoorbeeld een reactie plaatsen op een bericht. De server wordt hiervan op de hoogte gebracht en de reactie wordt opgenomen in de verzameling. Een tweede gebruiker wil ook een reactie plaatsen op datzelfde bericht, maar deze zit echter al even zonder verbinding en bezit niet de nieuwste versie met de reactie van de andere gebruiker. Wanneer deze dan terug verbindt met het internet ontstaat er een conflict: welk bericht zal er eerst in de rij terechtkomen? Wat geniet de voorkeur: de reacties in chronologische volgorde plaatsen of de volgorde laten bepalen door welke gebruiker er als eerste gesynchroniseerd heeft? Dit is een voorbeeld van een regel die vastgelegd moet worden in een synchronisatiestrategie.

Vele ontwikkelaars kiezen ervoor om een volledige synchronisatiestrategie zelf te ontwikkelen. De database wordt dus manueel gerepliceerd. Dit is een moeilijke en tijdrovende opgave. Vaak wordt als communicatiemiddel dan voor een REST-API gekozen. Tussen het versturen van de request en het effectief tonen van de producten gebeuren er dan heel wat zaken. Er moeten validaties gebeuren: is het toestel verbonden met het internet? Is er wel degelijk data ontvangen en geen error boodschap? Kan de JSON of XML output van de API correct geparseerd worden tot bruikbare objecten? Al bij de kleinste wijziging in de API bestaat de kans op crashes, bijvoorbeeld wanneer een integer-huisnummer wordt vervangen door een stringwaarde om ook letters toe te laten. Om de onderhoudbaarheid van het project hoog te houden is dit uitdagend.

Bij het bouwen van een state-of-the-art app komt dus heel wat extra kijken dat bij browser-applicaties een onbestaand probleem is. Men moet nadenken over caching, networking code voor het opvullen van deze cache, data access logic voor het uitlezen ervan, updates toelaten aan de cache (versioning), een goede synchronisatiestrategie programmeren tussen server en app, synchronisatieconflicten behandelen en data- en energieverbruik optimaliseren.
Daarom biedt Realm, een nieuwe speler op de markt uit San Francisco, een oplossing die in al deze noden tracht te voorzien en het leven van ontwikkelaars makkelijker probeert te maken.

Realm is een vrij jong bedrijf uit San Francisco dat werd opgericht in 2014. Men kwam op de markt met Realm Mobile Database, met als doel om een betere caching database aan te bieden voor apps. Realm profileert zichzelf door zich te vergelijken met SQLite en Core Data, de meest gebruikte lokale databases voor Android en iOS. Realm is sneller door hun compleet herziene aanpak op vlak van mobiele databases. Daarnaast breidde men deze database uit met synchronisatietechnologie die als het mechanisme dient om deze caches te onderhouden. Het geheel heet men het Realm Mobile Platform. Dit werkt via Realm Object Server, een centrale server die alle realms bijhoudt en waarmee gesynchroniseerd kan worden.

Met het Realm Mobile Platform wil men dat de voorgaand besproken problematiek allemaal verleden tijd wordt. Men ontneemt de ontwikkelaar bijvoorbeeld de verplichting om zelf netwerkcommunicatie te gaan voorzien. Realm handelt die zelf af, waardoor de ontwikkelaar zich minder hoeft te focussen op networking en synchronisatie, wat developers heel wat ontwikkelingstijd bespaart. Door geen REST te gebruiken onder de motorkap zijn de vele schakels die de ketting kunnen doen breken ook onbestaande. Er is op geen enkel punt in de communicatie-ketting sprake van serialisatie en deserialisatie.

Waarschijnlijk het meest bijzondere aan Realm zijn de objecten die terugkeren uit een query op een realm. In tegenstelling tot een gewone SQL-database krijgt men geen rij terug die moet worden omgezet in een bruikbaar object. In plaats daarvan krijgt men onmiddellijk een RealmObject of een lijst van RealmObjects terug. Deze RealmObjects zijn live objecten: wanneer er iets wijzigt aan de data in de realm, zal ook het object bijgewerkt worden. Zo is ten allen tijde de meest actuele versie van het object beschikbaar. Ook komt er nooit manuele deserialisatie vanuit JSON of een ander formaat aan te pas. Van database tot user interface, over de gehele lijn werkt Realm dus met objecten.

Bijna alles wat wenselijk is om offline-first apps te bouwen zit ingebouwd in één pakket: realtime data synchronisatie, een NoSQL database met transacties, live en lazy-loaded objecten, ingebouwde conflict resolution en de mogelijkheid om zelf regels te bepalen, ingebouwde database-migratie mogelijkheden, authenticatie, autorisatie, compressie, multiplexing, encryptie, server-side event handling en een Data Connector voor legacy database-systemen. Tenslotte is het pakket minder complex dan een traditionele database en is het goed gedocumenteerd. Ook is het ontwikkeld met cross-platform in het achterhoofd en is het vooral zeer performant, ondersteunt het vele concurrent connections en is de Realm Object Server schaalbaar.

Offline-first apps zijn in, maar helaas zijn de aandrijvende technologieën onder de motorkap minder voorhanden. Daar tracht Realm een uniforme oplossing voor aan te reiken. Het in gebruik nemen van een eigen caching strategie stelt ons voor heel wat mogelijke keuzes en problemen die we zullen moeten aanpakken. Het zelf ontwikkelen van een evenwaardige technologie blijft een harde noot om te kraken. De vele deelproblemen waar er zal over gestruikeld worden zijn van een zodanige complexiteit waardoor het bijna onmogelijk wordt om tot een resultaat te komen dat nog maar in de buurt komt van de functionaliteit en performantie van Realm Mobile Platform.

Naast het Realm Mobile Platform springt ook het Realm Mobile Database-segment in het oog. Door de compleet herziene aanpak op het mobiele database-vlak en de daaruit volgende performantie- en ontwikkelingsvoordelen is het ongetwijfeld een goed alternatief om ook als standalone database te gebruiken.

Met Realm hebben we een nieuwe tool in ons arsenaal om uw volgende offline-first app mee te ontwikkelen. Daag ons uit met uw project!

Lees meer over Realm in de bachelorproef Voordelen van Realm Mobile Platform voor realtime data synchronisatie in mobile apps