Magento PWA met GraphQL

[Update] 10-07-2022: Lees meer informatie over onze dienstverlening Adobe (Magento) Commerce PWA ontwikkeling en de voordelen van PWA.

Een App die in de browser draait

"De website die je nu bezoekt is geen website maar een App". Altijd leuk om te vertellen als we met klanten in gesprek zijn. Het is waar: reachdigital.nl is een PWA. Gebouwd met GraphQL als API - één van de eersten van Nederland. Geen website, maar een app die in je browser draait.

Wat is een PWA?

Het verschil tussen een normale website en een Progressive Web Application is dat een normale website op een server wordt gerenderd. Er wordt data verzameld, bewerkt, gedefinieerd en opgemaakt - en het geheel komt als html naar de client. In het geval van een Progressive Web App wordt (de naam zegt het al) alleen een dunne schil - de app shell - door de browser gedownload. Alle data wordt progressief (naarmate de gebruiker de app gebruikt) ingeladen.

Voorbeelden van een Adobe Commerce / Magento PWA

Voorbeelden van casestudies met PWA technologie kun je vinden op de pagina Adobe (Magento) Commerce PWA

App-achtige gebruikerservaring

Heb je ooit de Wehkamp, Zalando of Zara app geïnstalleerd? Waarschijnlijk niet. De drempel om een native app te installeren is erg hoog. Zeker voor die van een webshop waar je slechts een paar keer iets koopt. Terwijl de snelheid en stabiliteit van een app superieur is ten opzichte van een voor mobiel geoptimaliseerde responsive website.

Met P.W.A. overbruggen we het gat tussen supersnelle native (geïnstalleerde) app en de gebruikerservaring die we nu kunnen bieden met een mobiel geoptimaliseerde webshop. Het allerbelangrijkste argument daarbij is performance. De snelheid van het laden van pagina's en het doen van acties. Beter performance is betere gebruikerservaring en is betere scalability. PWA's (Progressive web apps) bieden:

• Altijd en overal een stabiele, hoge kwaliteit gebruikerservaring door minimaal dataverbruik.
• Een mobiele (3G,4G) verbinding heeft hoge throughput (hoge downloadsnelheid), maar zijn instabiel en hebben veel latency (vertraging). Je haalt alleen de data binnen die per pagina of actie nieuw of nodig is.
• Daardoor hebben bezoekers met een 2G of 3G verbinding ook een goede gebruikerservaring
• Wanneer de verbinding wegvalt (bijvoorbeeld op het moment van afrekenen) dan zet de app de actie in de wacht tot er weer verbinding is
• Offline compatibility. Dus; bij wegvallende of niet-aanwezige internetverbinding nog steeds door de webshop kunnen browsen en de winkelwagen kunnen vullen.

Een PWA is een doelstelling

De term PWA -Progressive web app- is geïntroduceerd door Google. De term PWA staat voor het voldoen aan een set performance regels en doelstellingen voor het web.

Hoé je dat doet, moet je zelf weten. In de praktijk is het echter 'zeer onmogelijk' om met traditionele technieken (serverside gerenderde pagina's) aan deze regels te voldoen. Zeker niet op schaal. En zeker niet voor e-commerce, waarbij veel informatie gebruikerspecifiek is (cachingoplossingen geen uitkomst bieden).

Google's RAIL model voor PWA's

Om te kunnen definiëren wat een PWA is (waaraan een PWA moet voldoen), heeft google het RAIL model geïntroduceerd:

• Response
• Animation
• Idle
• Load

Zoals je ziet: het hele model draait uiteindelijk om de snelheid voor de gebruiker. Google publiceert de volgende resultaten in het gedrag van gebruikers:

Regel 1: Response (actie / reactie)

Er gebeurt 'iets' binnen 50ms (1/200 van een seconde) wanneer de gebruiker een actie doet. De doelstelling is om de gebruiker de focus van snelheid optimalisatie inspanningen te laten zijn.

Regel 2: Animation

Vloeiende animatie is het einddoel

• Produceer iedere 10ms een frame (60fps).
• Consistente frame rate
• Vloeiend scrollen

Regel 3: Maximaliseer idle time

Maximaliseer idle-time (de tijd waarin de bezoeker de applicatie kan gebruiken zonder dat er zaken hoeven te gebeuren) om de kans te vergroten dat de pagina binnen 50ms reageert op invoer van de gebruiker.

Met andere woorden: laad overige data van een pagina in terwijl de bezoeker de applicatie gebruikt. Of laad data voor overige pagina's of acties alvast in terwijl de bezoeker de applicatie gebruikt

Gebruik idle-tijd om 'overige' data in te laden. Laad bijvoorbeeld zo min mogelijk gegevens in bij de eerste request (de app shell), zodat de gebruiker een resultaat heeft. Laad vervolgens de overige data in als de eerste request klaar is (de applicatie is idle).

Zorg dat 'dingen worden gedaan' (bijvoorbeeld overige data inladen) in 50ms. Anders onstaat het risico dat de app niet binnen 50ms reageert op gebruikersinvoer.

Als een gebruiker tijdens het idle zijn van de applicatie een actie uitvoert, moet de interactie van de gebruiker altijd de hoogste prioriteit hebben. Idle-tijd-activiteit moet worden onderbroken.

De animatie loopt nog, maar de applicatie is idle. Achter de schermen wordt alvast de vanmoof portfolio afbeelding gedownload die op een andere pagina nodig is.

Regel 4: Load

Toon content en word interactief in minder dan 5 seconden

Wanneer pagina's langzaam worden geladen, dwaalt de aandacht van gebruikers af en ervaren gebruikers de taak als onderbroken. Sites die snel worden geladen, hebben langere gemiddelde sessies, lagere bouncepercentages en een hogere zichtbaarheid van advertenties.

• Optimaliseer voor snelle laadtijden in verhouding tot het apparaat en netwerkmogelijkheden die gebruikers gebruikt. Op dit moment is een goed doel voor 'middelgrote mobiele apparaten met trage 3G-verbindingen' 5 seconden of minder (Dit doel na verloop van tijd waarschijnlijk veranderen).
• Voor volgende ladingen is het een goed doel om de pagina in minder dan 2 seconden te laden. Maar dit doel kan ook in de loop van de tijd veranderen.

Lighthouse performance meting op 3G. Iedere meting vertegenwoordigt een andere fase van de gebruiker's waarneming van het laden van de website.

Richtlijnen

• Test prestaties op de mobiele apparaten en netwerkverbindingen die gebruikelijk zijn bij uw gebruikers.
• Houd er rekening mee dat wanneer het apparaat van de standaard mobiele gebruiker 2G-, 3G- of 4G-verbinding is, in werkelijkheid de effectieve verbindingssnelheid vaak aanzienlijk trager is, vanwege packet loss en variatie.
• Focus op het optimaliseren van het 'kritieke weergavepad' om rendering te deblokkeren. Je hoeft niet alles in minder dan 5 seconden te laden om de perceptie van een volledige geladen pagina te behalen.

Het bouwen van een Magento PWA

Om uiteindelijk een e-commerce PWA te kunnen realiseren (Magento webshop PWA), moeten we nog een aantal flinke stappen maken.

1) Een nieuwe Magento frontend

Er moet een nieuwe frontend komen, op basis van een frontend framework dat 'voldoet' aan de PWA eisen. Het meest populair op dit moment zijn:

• React
• Vue
• Angular
• Polymer (Google's frontend framework)

Een nieuwe frontend betekent; Frontend development op basis van componenten

2) Nieuwe datalayer voor Magento

Er moet een datalayer beschikbaar zijn, waarmee het mogelijk wordt om frontend volledig van backend te scheiden. Zo krijgen we een headless Magento installatie. Op dit moment beschikt Magento 2 over een REST (web)API die alle functionaliteit biedt die intern in het systeem beschikbaar is. Echter, mist REST een aantal fundamentele zaken die PWA development op schaal mogelijk maken. In de laatste dev versie van Magento (2.3-develop branche) zien we sporen van de nieuwe GraphQL API waaraan gewerkt wordt.

Magento GraphQL API coming soon, zo te zien

Frontend development op basis van componenten

Met PWA webapplications als doelstelling en door de opkomst van frontend frameworks als React en Vue, heeft er een flinke shift plaatsgevonden in de manier waarop frontend development werkt.

We bouwen niet langer pagina's, maar componenten; stukjes functionaliteit specifiek voor 1 doel, waarin technisch opmaak, gedrag en datacommunicatie zijn verwerkt.

Een goed voorbeeld van een standaard component in de browser is een option select.

<select> <option value="volvo">Volvo</option> <option value="saab">Saab</option> <option value="vw">VW</option> <option value="audi" selected>Audi</option> </select>

Hoe de dropdown te gebruiken is en hoe hij eruit ziet is altijd hetzelfde. Onafhankelijk van hoe de rest van de website of applicatie in elkaar zit.

Eerder konden we al componenten bouwen met bijvoorbeeld React. React biedt virtualDOM, waarmee we elementen in de html konden zetten waar de rest van de stylesheet niet bij kan. Echter, een React component is alleen te gebruiken binnen een React applicatie.

Daarom bouwen wij Webcomponents. Een voor alle browsers (vrij nieuwe) specificatie, waarmee het mogelijk wordt om zelf native componenten te bouwen.

Het contactformulier op deze website bijvoorbeeld. Die kunnen we op een willekeurige plaats op deze website zetten met de volgende code.

<contact-form> <span slot="title">Een Magento PWA bouwen met GraphQL?</span> </contact-form>

Het bouwen in componenten is technisch iets nieuws voor frontend development. Echter, het hele concept vereist een bepaalde shift in werkwijze en denkwijze bij het bouwen van nieuwe websites of PWA's.

Een datalayer op basis van GraphQL

GraphQL is ontwikkeld door Facebook en voorziet in alle zaken die we van een API willen voor het bouwen van een razendsnelle PWA:

• GraphQL heeft één endpoint. Andere API’s vereisen het ontwikkelen van nieuwe endpoints voor nieuwe of veranderende databehoefte gedurende development. Één endpoint aakt een einde aan overfetching van data (data binnenhalen die je helemaal niet nodig hebt).
• Verantwoordelijkheid over op te vragen gegevens bij de client (de PWA)
• GraphQL is een strict type API. Een groot deel van de Magento 2 bugs wordt veroorzaakt door typecasting in de huidige Rest API.
• Heeft een Introspection query; documentatie voor de API is ingebakken in de API. En werkt op dezelfde manier als de wijze waarop je normaal de API gebruikt. Zo begrijp je hoe je data er uit ziet.
• Het 'Graph' in GraphQL. Zie het als een 'boomstructuur' data request. Je kunt in één query parentnodes en childnodes ophalen. En voorkomt daarmee latency door roundtrips (vertraging doordat de ene query wacht op het resultaat van de andere query).
• Query batching, het samenvoegen van meedere queries tot één query. Al is dit inmiddels minder relevant vanwege http2, waarmee de browser meerdere requests tegelijk kan uitvoeren.

Hoe ziet GraphQL voor Magento er uit?

Dit is niet de GraphQL Magento implementatie van Magento. Dit is onze eigen GraphQL implementatie voor Magento 2. [Update] 10-07-2022: Screenshots zijn geupdate naar screenshots van de huidig beschikbare GraphQL API in Magento.

We bouwden halverwege 2017 een volledig automatisch gegenereerd GraphQL Scheme voor Magento. Anders dan Magento zelf doet (handmatig per class het schema bouwen), gebruiken we de php service layer om een schema te bouwen met alle bestaande en beschikbare php classes.

Stack van reachdigital.nl

De Reach Digital PWA is gebouwd met:

Webcomponents ⁠Webcomponents zijn een browserstandaard. Een webcomponent werkt altijd in iedere browser. En kan in ieder frontend framework gebruikt worden (Reactie, Vue, Angular en in ons geval Polymer).

Polymer ⁠Framework voor het bouwen van Webcomponents.

Apollo client ⁠Library voor Webcomponents die een GraphQL query doen om data binnen te halen. Biedt ook mogelijkheden voor caching van queries en het queuen / bundelen van queries.

Google App Engine ⁠Platform As A Service. Een hosting platform, zonder dat je toegang hebt tot de server. Google App Engine draait Node.js en is oneindigend schaalbaar:

runtime: nodejs env: flex automatic_scaling: min_num_instances: 1 max_num_instances: 20

GraphQL ⁠De API

GraphCool ⁠Is een Database As A Service: het biedt de mogelijkheid om een GraphQL schema te definieren dat wordt omgezet naar een database. Die je vervolgens via GraphQL kunt benaderen. GraphCool slaat dus data op.

GraphCMS ⁠Een interface om de GraphQL database te beheren

TravisCI ⁠Continuous Integration tool gekoppeld aan zowel Github als Google App Engine. Een commit op de master branche rolt een nieuwe versie van de Reach Digital App uit op Google App Engine. Build de App.

Magento werkt aan Magento PWA studio

Magento (het bedrijf) zet in op PWA's met de aankonding van de Magento PWA studio. Geen kant-en-klare 'nieuwe frontend' voor Magento, maar een toolset om een PWA te bouwen.

Ze hebben gekozen voor React als frontend framework en GraphQL als datalayer.

Ps: PWA en Google AMP

Mogelijk staat na het lezen van dit artikel een vraag over de rol van Google AMP in dit verhaal.

Kort samengevat: AMP is bedoeld om het bestaande internet sneller te maken. Om websites sneller aan Google gebruikers te serveren. Google stelt een 'template' beschikbaar, waarmee je een pagina op een specifieke manier aanbiedt. Google crawled deze data en serveert ze vanuit eigen cache. Zo heeft de bezoeker veel sneller toegang tot content.

AMP is de oplossing voor situaties waarin een PWA een te grote stap is.