Zeer schaalbare en krachtige e-commerce met Jamstack
Tech15 december 2020

Zeer schaalbare en krachtige e-commerce met Jamstack

Het kan heel moeilijk zijn om kosteneffectieve schaalbaarheid te krijgen van op Digital eXperience Platform (DXP) gebaseerde e-commercesites. Het toepassen van meerdere caching-lagen kan er zelfs toe leiden dat we de functionaliteit van het platform moeten opgeven. Voor dit soort e-commercesites kunnen de prestaties niet langer een bijzaak zijn, hiervoor hebben we een architectuur nodig. Hallo Jamstack!

Uitdagingen met digitale eXperience-platformen

Contentbeheer, Analyses, Marketingautomatisering, Machine learning. Dit zijn enkele van de functies die worden aangeboden door Digital eXperience-platforms en de daadwerkelijke lijst is meestal veel langer. Al deze functies vereisen CPU en geheugen om uit te voeren, zelfs degene die je misschien niet eens gebruikt. Beschouw de volgende typische DXP-architectuur:

traditionele request responsetraditionele request response

Van links naar rechts zien we een load balancer die de belasting verdeelt over de drie content delivery servers. De content delivery servers zijn speciale rollen van de DXP voor het leveren van de inhoud. Er is een aparte content management server die gebruikt wordt door de content-editor en marketeers en een aparte applicatieserver voor achtergrondverwerking. Wanneer de bezoeker een pagina opvraagt, ziet de verzoek-antwoordcyclus er als volgt uit:

  1. De klant vraagt een pagina van de website op
  2. De load-balancer kiest een server voor een content delivery server
  3. De content delivery server vraagt de benodigde gegevens uit de database
  4. De content delivery server geeft de pagina weer en verstrekt het antwoord aan de klant

Stel dat er een project is met deze architectuur en het team is klaar met het bouwen van de lanceringsfuncties, zijn ze klaar voor GO-live! Omdat ze professionals zijn, wordt eerst een belastingstest uitgevoerd. De resultaten komen binnen en ze zien er niet goed uit. De producteigenaar eist dat de prestaties worden verbeterd!

Het team downloadt een exemplaar van de prestatiegids van DXP. Eerst wordt het afstemmen op de database uitgevoerd en worden tabelindexen toegevoegd. Vervolgens moeten de caches op de Content Delivery (CD) servers worden geconfigureerd. De prestaties zijn al een stuk beter, om het nog verder te verbeteren, worden afbeeldingen en andere statische bronnen naar een Content Delivery Network gepusht. De prestaties zijn nu acceptabel en de GO-live van de site is een succes.

Een week later viert het team het succes en gaat uit voor een teamdiner. Gedurende het hoofdgerecht rinkelt de telefoon: de site is down. Ze openen hun laptop en merken dat het aantal bezoekers een stuk hoger is dan verwacht. Verdere analyses tonen aan dat de CPU limiet van de content delivery servers is bereikt. Het team past "Infrastructure als code" toe en ze zijn in staat om binnen een uur nog twee CD's toe te voegen, wat het probleem verhelpt. De volgende ochtend op kantoor horen ze dat marketing een grote nieuwsbrief heeft verstuurd die heeft geresulteerd in een piek in het verkeer.

Ze merken meteen dat het aantal bezoekers een stuk hoger is dan verwacht en dat de CPU limiet van de content delivery servers is bereikt

Twee maanden later is het Cyber Monday ... Opnieuw ziet het team een enorme piek in het verkeer en dit keer is het probleem niet zo eenvoudig op te lossen. Ze schakelen uiteindelijk DXP-functies uit om een acceptabele prestatie te krijgen.

Als het gaat om op DXP gebaseerde e-commercesites met deze bezoekersaantallen, kan het erg moeilijk zijn om het systeem te schalen. Zeker bij extreme kijkmomenten. De kosten en complexiteit van de betrokken infrastructuur maken het moeilijk om de investering op het DXP terug te verdienen.

Prestaties mogen niet langer een bijzaak zijn. We hebben een e-commerce-architectuur nodig die is geoptimaliseerd voor schaalbaarheid.

Het tij keren

Deze term werd gebruikt door Netlify CEO Matt Biilmann in zijn State of Jamstack keynote (oktober 2020) om het doel van Netlify uit te leggen toen ze begonnen. In het eerdere voorbeeld vraagt de klant om een pagina en wordt die pagina in een handomdraai opgebouwd. Wanneer de cache verloopt, wordt deze opnieuw opgebouwd, zelfs als de onderliggende gegevens niet zijn gewijzigd. Wat als we in plaats daarvan het tij keren en de pagina vooraf opbouwen en alleen opnieuw opbouwen als de onderliggende gegevens veranderen? Als we nog verder gaan, kunnen we deze statische pagina zelfs naar een Content Delivery Network (CDN) pushen. Op deze manier bevind de pagina zich altijd dicht bij de bezoekers, wat resulteert in optimale prestaties.

reverse the flowreverse the flow

Bedrijven als Netlify en Vercel hebben Content Delivery Networks ontwikkeld tot wat zij Application Delivery Networks (ADN) noemen. Traditioneel bedienen CDN's alleen statische activa. Application Delivery Networks hebben extra functies om jouw applicatie te bouwen, hooks die kunnen worden gebruikt om opnieuw te bouwen wanneer gegevens veranderen, meer geavanceerde cache-invalidatie, enz.

In plaats van alles on the fly te bouwen, kunnen we detecteren wanneer er iets verandert en zoveel mogelijk vooraf bouwen in een bouwstap en het naar de edge laag pushen

Matt Biilmann

Beschouw het voorbeeld van de productieproblemen van het team. Met deze architectuur zijn de pagina's vooraf gebouwd en bediend door het CDN. Het CDN zorgt voor alle schaalvergroting en de applicatie heeft geen problemen, zelfs niet in het Cyber Monday-scenario.

Jamstack

Jamstack staat voor JavaScript, API's & Markup en is het resultaat van het 'keer het tij'-idee. Statische pagina's zijn vooraf gebouwd en opnieuw opgebouwd wanneer de gegevens veranderen. De opmaak van deze pagina's wordt naar een ADN gepusht en bevat JavaScript om ze te verbeteren. Dit JavaScript roept API's op om extra functionaliteit te bieden.

Naast de prestatie- en schaalbaarheidsverbeteringen van deze aanpak, is er een grote verbetering als het gaat om de ontwikkelaarservaring. Met DXP's worden de ontwikkelaars beperkt door de technologie die door het platform wordt gebruikt. Door in plaats daarvan een headless CMS te gebruiken, dat alleen data verstrekt in plaats van markup, wordt de front-end losgekoppeld van het CMS. De ontwikkelaars zijn vrij in hun keuze van technologie, waardoor ze de beste tool voor de klus kunnen gebruiken en geweldige visuele ervaringen kunnen creëren.

Door headless-services te gebruiken en een ontkoppelde front-end te hebben, betekent dit ook dat er geen dure platformupgrades meer zijn. De enige koppeling is via het HTTP-eindpunt en de meeste services garanderen achterwaartse compatibiliteit. Nieuwe functies die ingrijpende wijzigingen vereisen, worden meestal toegevoegd via een nieuwe API. Headless-services zijn geweldig om te gebruiken als Software as a Service, wat betekent dat er minder infrastructuur moet worden beheerd en een betere servicekwaliteit wordt bereikt.

API Economy

Tegenwoordig is er voor alles een API. Vroeger, als je een sms wilde sturen, was het echt moeilijk om te doen. Nu is het slechts één API-aanroep met behulp van een service genaamd Twilio. Deze API-economie maakt het heel eenvoudig om Jamstack-websites te bouwen met verbluffende mogelijkheden, zonder de complexiteit die het normaal gesproken met zich meebrengt. Bovendien hebben ontwikkelaars en gebruikers met een DXP-platform vanaf het begin te maken met de complexiteit van het hele platform. Met de Jamstack-aanpak kan de oplossing eenvoudig beginnen en worden services (en hun toegevoegde complexiteit) stapsgewijs toegevoegd wanneer ze nodig zijn.

Omgaan met grote catalogi

Jamstack-sites worden statisch gegenereerd. Elke keer dat de inhoud verandert, wordt de hele site opnieuw gegenereerd om de gewijzigde inhoud weer te geven. Dit werkt goed met persoonlijke blogs of kleine sites, maar hoe zit het met een e-commerce site met 300.000 producten en duizenden productupdates per dag? Het genereren van een site met zoveel pagina's zou te traag zijn en het zou te lang duren voordat de bijgewerkte productgegevens zichtbaar zijn op de site.

Incrementele Statische Regeneratie

Gelukkig bieden de meeste static site generators een vorm van incrementele builds. Gatsby, een op React gebaseerde statische site generator, heeft bijvoorbeeld incrementele builds die op magische wijze builds versnellen door veranderingen te vergelijken en alleen de benodigde pagina's opnieuw op te bouwen. Next.js biedt een andere oplossing. Next.js verschilt van pure static site generators, omdat het meer een hybride is. Naast Static Site Generation (SSG) ondersteunt het ook Server Side Rendering (SSR) en Incremental Static Regeneration (ISR). Server Side Rendering lijkt meer op de traditionele weergave op aanvraag en het wordt als een best practice beschouwd om deze niet te gebruiken. Het is echter goed om deze optie beschikbaar te houden, mocht dit in een later stadium nodig zijn. Met Increment Static Regeneration is het mogelijk om een ​​pre-build versie van een pagina aan te bieden, terwijl op de achtergrond een nieuwe versie opnieuw wordt gegenereerd, die aan de volgende bezoeker wordt aangeboden. Dit wordt bereikt met behulp van een CDN-mechanisme genaamd Stale-while-revalidate. Wij denken dat ISR de perfecte oplossing is voor grote e-commercesites, omdat het snelle builds, hoge prestaties en up-to-date data mogelijk maakt.

Wij denken dat Incremental Static Regeneration (ISR) de perfecte oplossing is voor grote e-commercesites, omdat het snelle builds, hoge prestaties en up-to-date data mogelijk maakt.

Hoe zit het met personalisatie?

Er zijn meerdere personalisatie oplossingen die afhankelijk zijn van JavaScript aan de clientzijde, zoals Optimizely of Google optimize. Het nadeel van deze oplossingen is dat de hoeveelheid JavaScript die nodig is, een negatieve invloed kan hebben op de waargenomen prestaties en jouw gebruikers mogelijk een flits van veranderende inhoud kan opleveren. Een interessant alternatief is personalisatie on the edge. Met steeds meer Content Delivery Networks (Cloudflare, Netlify) kun je codes op hun edge-servers draaien. Uniform en Outsmartly zijn nieuwe spelers op dit gebied die dit gebruiken om personalisatie mogelijk te maken met behulp van CDN-edge-servers. Dit zorgt voor een supersnelle personalisatie!

Alleen Vooral voor grootschalige e-commerce

De complexe infrastructuur, het grote aantal functies en de legacy-code van monolithische Digital Experience Platforms maken het moeilijk om e-commerce oplossingen efficiënt te schalen. Niet alle hoop is verloren, keer het tij en regenereer stapsgewijs de statische pagina's! Serveer ze vanuit een CDN en schaalbaarheidsproblemen behoren tot het verleden. Het toevoegen van innovatieve services is nog nooit zo eenvoudig geweest, want met Jamstack kun je het meeste uit de API-economie halen.

Want to know more?

Heb je een vraag, wilt je meer weten of wil je onze Jamstack storefront demo zien? Gebruik ons contactformulier of stuur ons een mail: info@unplatform.io.

Jonne Kats
Geschreven door Jonne Kats
Op 15 december 2020