Utvecklingsprocessen för Houdini Sportwears nya e-handel

I mitt tidigare blogginlägg gick jag kortfattat igenom hur vi byggde Vålamagasinets e-handel som en Single Page Application (SPA) med React. Med tiden har vi förbättrat vår utvecklingsprocess, och jag tänkte gå igenom ett par av de förbättringar vi gjort under arbetet med Houdini Sportwears nya e-handel för att underlätta arbetet för våra utvecklare.

Utmaningar på vägen

Som alltid när man använder ny teknik stötte vi på utmaningar vi var tvungna att lösa under utvecklingen av Vålamagasinets e-handel. Flera av dessa var kopplade till att frontend inte styrde över webbservern som hostade vår webbapp.

Detta innebar att data som till exempel sidtitlar och metataggar var tvungna att sättas av backend i sidmallen, så att Googles spindel och andra bottar kunde få tillgång till den datan direkt, utan att ladda hem och köra vårt JavaScript. Dessutom behövde vi skriva logik i frontendappen som såg till att sidtitlar och metataggar uppdateras när användaren navigerar runt i appen. Det gick naturligtvis att lösa, men krävde ett tätt samarbete mellan frontend och backend, och kändes inte optimalt.

Ett annat område för förbättring är laddningstiden för första sidvisningen. Som React fungerar out-of-the-box, måste webbläsaren ladda hem vårt JavaScript och tolka det innan den kan börja hämta data och rita upp sidan som ska visas. På en modern apparat med en skaplig Internetuppkoppling går detta snabbt, men snabbare är alltid bättre.

Det sista området vi verkligen ville förbättra, är möjligheten att på ett enkelt sätt ha olika miljöer som kör olika kod för att underlätta testning och code review av vår frontendkod. Detta försvårades av att vår webbapp hostas i en Windowsmiljö.

Next.js to the rescue!

För att lösa dessa hinder under vår utvecklingsprocess byggde vi Houdini Sportswear med server side rendering med hjälp av Next.js, och gick över till att särskilja backend och frontend ännu mer.

Då all kommunikation mellan backend och frontend sker med Ajax-anrop, hade vi i Houdini möjlighet att själva styra över hostingen av vårt webbapp. Vi satte upp ett system i Heroku, där en ny instans av vår app snurrar igång varje gång vi gör en pull-request i GitHub.

Detta underlättade enormt vid testning i olika devices och code review, då vi automatiskt alltid har en miljö som kör just den kod vi vill testa. Dessutom ser man snabbt direkt i GitHub, om koden av någon anleding, inte bygger korrekt.

Förbättring 1: Automatiskt ha olika miljöer som kör olika kod, check.

Eftersom vi i frontend nu styr över webbservern kan vi använda Next.js för att rita upp hur sidan ska se ut direkt i servern. Användaren som besöker sidan behöver inte längre vänta på att hämta och köra vårt JavaScript innan webbläsaren kan rita upp sidan.

Dessutom kan vi cacha resultatet från Next.js i webbservern för att ge ännu snabbare sidvisningar.

Förbättring 2: Snabbare första sidvisning med cachning på servern, check.

Det betyder att vår logik för att sätta sidtitlar och metataggar även körs och skickas ut från vår server, och behöver således inte finnas både i backend- och frontend-kod.

Förbättring 3: Underlätta hantering av sidtitlar och metataggar, check.

En levande utvecklingsprocess

Detta var bara ett axplock av några av de förbättringar vi gjort under utvecklingen av Houdini Sportswear. Vår utvecklingsprocess är något som ständigt förbättras och utvecklas allteftersom tekniken och vår erfarenhet växer.

Alexander Järnehall, gränssnittsutvecklare på Cloud Nine.

Är du utvecklare och tycker detta låter intressant, kolla in vår karriärsida.