Utviklingsprosessen for Houdini Sportwear sin nye e-handel

I mitt <a href="/how-we-build-modern-ehandel-as-a-spa" target="_blank">forrige blogginnlegg</a> gikk jeg kort gjennom hvordan vi bygget <a href="https : //valamagasinet.se" target="_blank">Vålamagasinets e-handel</a> som Single Page Application (SPA) med React. Over tid har vi forbedret utviklingsprosessen vår, og jeg tenkte jeg skulle gå gjennom et par av forbedringene vi gjorde mens vi jobbet med <a href="https://houdinisportswear.com" target="_blank">Houdini Sportwears nye e-handel</a a> for å lette arbeidet til utviklerne våre.

Utfordringer underveis

Som alltid ved bruk av ny teknologi, møtte vi utfordringer vi måtte løse under utviklingen av Vålamagasinets e-handel. Flere av disse var relatert til at grensesnittet ikke kontrollerte webserveren som var vert for nettappen vår.

Dette betydde at data som sidetitler og metakoder måtte angis av backend i sidemalen, slik at Googles edderkopper og andre roboter kunne få tilgang til disse dataene direkte, uten å laste ned og kjøre JavaScript. I tillegg trengte vi å skrive logikk i front-end-appen som sørget for at sidetitler og metakoder ble oppdatert mens brukeren navigerte rundt i appen. Det kunne selvsagt løses, men krevde tett samarbeid mellom frontend og backend, og føltes ikke optimalt.

Et annet område for forbedring er lastetiden for den første sidevisningen. Siden React fungerer rett ut av esken, må nettleseren laste ned JavaScript og tolke det før den kan begynne å hente data og tegne siden som skal vises. På en moderne enhet med en anstendig Internett-tilkobling er dette raskt, men raskere er alltid bedre.

Det siste området vi virkelig ønsket å forbedre er muligheten til enkelt å ha forskjellige miljøer som kjører forskjellig kode for å lette testing og kodegjennomgang av frontendkoden vår. Dette ble vanskeliggjort av det faktum at nettappen vår er vert i et Windows-miljø.

Next.js til unnsetning!

For å løse disse hindringene under utviklingsprosessen vår bygde vi Houdini Sportswear med gjengivelse på serversiden ved å bruke <a href="https://nextjs.org/" target="_blank">Next.js</a>, og gikk over til å skille backend og frontend enda mer.

Siden all kommunikasjon mellom backend og frontend foregår med Ajax-anrop, hadde vi i Houdini muligheten til å kontrollere hostingen av webappen vår selv. Vi setter opp et system i Heroku, der en ny forekomst av appen vår spinner opp hver gang vi gjør en pull-forespørsel i GitHub.

Dette lettet kraftig testing i ulike enheter og kodegjennomgang, da vi automatisk alltid har et miljø som kjører akkurat den koden vi ønsker å teste. I tillegg kan du raskt se direkte i GitHub om koden av en eller annen grunn ikke bygger riktig.

Forbedring 1: Har automatisk forskjellige miljøer som kjører forskjellig kode, sjekk.

![alex-blogpost-utvprocess (1)](//images.ctfassets.net/ckfp71nhsbgs/5gK3LY7WFv27fJcuvWCtcb/70db8ccdf1b074ca9adf982d66dcdblogg_utvprocess1/s____jpg-utvprocesg.

Siden vi nå styrer webserveren i frontend, kan vi bruke Next.js til å tegne opp hvordan siden skal se ut direkte i serveren. Brukeren som besøker siden trenger ikke lenger å vente på at JavaScript skal lastes ned og kjøres før nettleseren kan gjengi siden.

I tillegg kan vi cache resultatet fra Next.js i webserveren for å gi enda raskere sidevisninger.

Forbedring 2: Raskere førstesidevisning med bufring på serveren, sjekk.

Dette betyr at vår logikk for å sette sidetitler og metatagger også kjøres og sendes ut fra vår server, og trenger dermed ikke være i både backend- og frontend-kode.

Forbedring 3: Tilrettelegge håndteringen av sidetitler og metakoder, sjekk.

En levende utviklingsprosess

Dette var bare et utvalg av noen av forbedringene vi gjorde under utviklingen av Houdini Sportswear. Vår utviklingsprosess er noe som hele tiden forbedres og utvikles etter hvert som teknologien og vår erfaring vokser.

Alexander Järnehall, grensesnittutvikler i Cloud Nine.

Hvis du er en utvikler og synes dette høres interessant ut, sjekk ut vår <a href="/career" target="_blank">karriereside</a>.