Frontend og infrastruktur

gullfunn.no er bygget og driftet av NoA Ignite på NoAs rammeverk Adapt. Beskrivelsen bygger på kunnskapsoverføringen 8. april 2025 (Espen Rosenberg Hansen med Tormod Ulsberg og Torbjørn Holtmon fra NoA), Adapt-rammen og NoAs applikasjonsoversikt.

Stack

TypeScript brukes i hele løsningen, både frontend og backend. Frontend er bygget med Astro, valgt for god integrasjon med Cloudflare Pages, høy ytelse, lite JavaScript til klienten og fleksibel caching. Interaktive komponenter lages i Svelte. Styling gjøres med Tailwind, og vanlig CSS der Tailwind ikke passer.

Request-flyt

flowchart TD
    U[Bruker: request til www.gullfunn.no] --> F{Fastly: finnes i cache?}
    F -- Ja --> R[Svar fra Fastly]
    F -- Nei --> P[Cloudflare Pages<br/>Astro + Svelte]
    P -- Query for data --> W[Adapt API på Cloudflare Workers<br/>GraphQL]
    W --> O[(Omnium)]
    W --> S[(Sanity)]
    W --> AZ[(Azure)]
    W -- Response --> P
    P -- Response --> F

NoAs applikasjonsoversikt viser i tillegg at frontend og API logger til Datadog, bruker Google Analytics, autentiserer kunder med Azure AD B2C og henter søk og anbefalinger fra Voyado Elevate og chat fra Kindly.

Adapt API (GraphQL)

Adapt API er et GraphQL-lag på Cloudflare Workers som ligger mellom frontend og Omnium, Sanity og Azure. I NoAs eldre design heter det Retailor API. Frontend henter akkurat feltene den trenger, for eksempel produkt, varianter og kategorier i én forespørsel, uten at backend lager egne endepunkter for hver kombinasjon. Nye funksjoner, som huskelister, kan bygges uten nye Omnium-integrasjoner.

Nyere Adapt-prosjekter hos NoA har gått bort fra GraphQL på grunn av kompleksitet, bratt læringskurve og tyngre vedlikehold. Det finnes ingen planer om å fjerne det fra Gullfunn, fordi det fungerer. Sannsynlig vei videre: nye funksjoner uten GraphQL, det gamle beholdes, gradvis migrering.

Hosting og deploy

Alle deployer går via Cloudflare Pages. Tidligere versjoner kan aktiveres umiddelbart ved rollback. Branch-miljøer opprettes ved behov, koster ingenting når de ikke brukes, og brukes til test og QA.

Caching

Løsningen har flere cache-lag, og det er en viktig årsak til god ytelse.

• Fastly CDN ligger foran applikasjonen med cache-intervall og stale-while-revalidate: brukeren får cachet innhold med en gang, mens oppdateringen skjer i bakgrunnen. Cachen kan tømmes ved deploy.
• Intern cache i Cloudflare holder header, footer, kampanjer, kategorier og brands, for å redusere antall kall til Sanity og andre tjenester.

Miljøer

Miljø	Adresse
Test nettbutikk	test.gullfunn.no
Test Omnium	test.omnium.no, apitest.omnium.no
Test Bluestone	app.test.bluestonepim.com
Test VisionPoint	demovpoint.gullfunn.no
Test BC	Business Central, company NC CHRISTOPHERSEN AS (testprodukter må finnes her)

Feilsøking

Postman brukes mot Omnium API: egen API-klient per person, bearer-token, miljøvariabler og GET, PATCH og POST. Bruk PATCH fremfor PUT når enkeltfelt skal endres, og vær forsiktig mot produksjon. Typisk bruk er å kontrollere rådata, feilsøke ordre og produkter og validere integrasjoner.

Svakheten i dag er observability. Omnium har få logger, det er vanskelig å se hva som feiler, og feilsøking krever ofte hjelp fra NoA. Elevate har egne logger, men de gir lite, så feilsøking må kombineres med Azure-logger. Forslaget fra kunnskapsoverføringen er en egen loggdatabase med et grensesnitt i Sanity som viser synkstatus, feilede produkter, feilårsaker og manuelle kjøringer.