– Jeg mener headless er bra – for de som trenger det

Som teknologibedriften Dekode er så får vi mange forespørsler om hvilken type strategi som er riktig å velge for en gitt kunde. Flere av de som tar kontakt med oss har ofte vært i dialog med flere selskaper. De har også fått forskjellige anbefalinger på hvilken retning de burde ta når det kommer til teknologi. Et av de begrepene som oftest kommer frem i våre dialoger er Headless. Men hva betyr det egentlig å ha en headless nettside?

Hva er headless?

Direkte oversatt så er headless, hodeløst. Det betyr at nettstedets visuelle grensesnitt og administrasjonsgrensesnitt er to forskjellige systemer. Altså, de er koblet fra hverandre og utvikles som to separate systemer. Interaksjonen mellom de to foregår ved hjelp av grensesnitt som tilrettelegger for datamaskin til datamaskin kommunikasjon. Eller et API som det kalles. Ofte driftes systemene på forskjellige servere også. Tidligere har systemer for nettpublisering stått for både administrasjon av innhold og presentasjon av innhold. Det er nettopp denne separasjonen mellom administrasjon og presentasjon i forskjellige systemer som er Headless. 

Så hvorfor er det så mye snakk om Headless egentlig? Og hvem er det som burde ha et headless nettsted? 

Det første spørsmålet jeg mener vi burde stille oss er: Hva er det nettsiden skal gjøre for organisasjonen min?

Behovet nettsiden skal løse er en avgjørende faktor. Skal nettsiden løse et kommunikasjonsbehov? Utløse salg i form av tjenester? Drive direkte salg eller løse kompliserte brukerbehov? I mange organisasjoner vil det kanskje være flere av disse.

Vi kan gjøre dette litt mer konkret med et eksempel som er relevant for mange av våre kunder. Vi i Dekode har mange kunder innenfor samfunnsnytte segmentet. Organisasjoner som har både store behov for kommunikasjon og at nettstedet kan tilrettelegge for salg av produkter og fundraising. Relativt store oppgaver for ett nettsted å løse med mange forskjellige systemer i bakkant som har hvert sitt spesialfelt. Et knippe med systemer som skal løse kommunikasjon, salg og kundehåndtering. Er headless veien å gå for en slik kunde? 

Mikroservice arkitektur

Om vi skulle løst dette konkrete eksempelet med headless kunne vi utviklet dette caset med en mikroservice arkitektur. Nok et begrep som mange etterhvert er kjent med. Istedenfor å lage et stort system, deles systemet opp i mange små deler som sys sammen for brukerne. I en ideell verden merker ikke brukeren at de navigerer mellom disse. Hver enkelt del av nettstedet har helt dedikerte oppgaver. En del av nettstedet løser kommunikasjon, en annen del løser nettbutikk. Den tredje delen løser fundraising og den fjerde tar seg av kundedata som personinformasjon og ordrehistorikk. 

Videre er det opp til det visuelle laget å sy dette sammen. Men med det så trenger vi kanskje et femte system som gjør at redaktørene kan kombinere alle disse datakildene slik at det ser bra ut for brukeren. For at brukeren skal oppleve alle disse delene som ett økosystem er det også fornuftig med et designsystem som omfavner alle de ovennevnte delene av brukerreisen.

Ved å gjøre dette skikkelig så kan man få et velfungerende system som har færre arbeidsoppgaver og dedikerte personer som vedlikeholder de forskjellige delene. Web-teamet implementerer delkomponentene og får dette til snakke sammen. 

– Jeg tror det er mange som etterspør headless uten å vite hva det innebærer, og lar seg påvirke av at begrepet er blitt så populært

I prinsippet er headless en skalerbar metode for å lage nettløsninger. Likevel er det en mulighet for at du nå sitter og tenker på egen organisasjon og vurderer om dere har de nødvendige ressursene for å gjennomføre et slikt prosjekt. Og ikke minst om det er tatt høyde for at de som skal jobbe med nettløsningen har den nødvendige kunnskapen som trengs for å vedlikeholde et slikt system. Er det i det hele tatt økonomisk forsvarlig å ha så mange dedikerte roller? 

Personlig har jeg jobbet med headless i en årrekke i en organisasjon hvor headless var helt riktig vei å gå. Jeg jobbet i en organisasjon hvor produktet var strømmetjeneste av musikk. Systemene for å drive en slik organisasjon er ikke akkurat noe en kan kjøpe av hvilken som helst leverandør. Der implementerte vi mikroservice arkitektur og alt av data ble utvekslet via API-er. Vi hadde dedikerte team for hvert eneste system og dedikerte designavdelinger for både nettsiden og appene vi solgte. 

Som jeg tror du skjønner, så mener jeg at headless er veldig bra – for de som trenger det. Jeg tror det er mange som etterspør headless uten å vite hva det innebærer og lar seg påvirke av at begrepet er blitt så populært. Jeg mener ikke dette fordi Dekode primært driver med WordPress. Det er veldig gode muligheter for å gjøre headless med WordPress. Jeg har selv valgt headless WordPress for delkomponenter i ovennevnte selskap. Jeg mener at beslutningene drives av det som er populært og ikke nødvendigvis hva som er best for organisasjonen eller kunden.

Om vi skal snu på eksempelet over med en veldedig organisasjon og implementerer dette med WordPress, kan vi løse presentasjonslaget for kommunikasjon, nettbutikken og pengeinnsamling i ett system. Alle disse vil kunne administreres i samme grensesnitt. Alle systemer som organisasjonen benytter vil bli oppdatert når kundene gjør handlinger på nettstedet. Redaktørene kan jobbe med innhold og kombinere alle delene de behøver uten å bytte system. De benytter visuelle innholdsblokker som er i tråd med eget designsystem i et grensesnitt som er visuelt likt som det kundene vil bli møtt med. Når vi ser at det gir mening å lage noe headless så gjør vi det som en integrert del av nettløsningen, men sørger for at publisering og vedlikehold av nettstedet er lettfattet og visuelt tiltalende.

WordPress eller headless WordPress?

Vår tilnærming er å ha en pragmatisk tilnærming til kundens behov som løser organisasjonens behov på en måte som er bærekraftig for kunden. WordPress er et system med åpen kildekode. Likevel betyr ikke det at WordPress ikke kan tilpasses til kundens behov slik at det blir kundens verktøy. Og ja, vi benytter også tredjeparter for å strømlinjeforme datautveksling mellom forskjellige systemer. Men da har vi alltid en felles kilde som sender dataene – nemlig WordPress.

Vi i Dekode jobber mye med å skape gode redaktørverktøy. Vi er opptatt av at redaktøropplevelsen skal gi et så godt inntrykk av de ferdige sidene under redigeringsprosessen. Dette gjør vi ved å skape biblioteker med innholdsblokker eller moduler. For å tilrettelegge for det koder vi blokkene i administrasjonsgrensesnittet med React. Ved å benytte headless må alle disse blokkene også utvikles for frontend rammeverket i det rammeverket som benyttes. Når en utvikler noe headless må en også ta høyde for at alle andre aspekter av det å bygge et nettsted må utvikles fra bunnen herunder menystrukturer, URL-strukturer og alt som angår søkemotoroptimalisering. Man må også belage seg på å utvikle alle verktøy som skal benyttes for kommersielle formål slik som tracking og integrasjon med analyseverktøy.  

En pragmatisk tilnærming

Dekode kan levere både vanlig WordPress og headless WordPress, eller headless hva som helst for den saks skyld – men vi har gode argumenter når vi velger det. Istedenfor å presse headless på en kunde som ikke trenger det.

Man bør være pragmatisk til den teknologien en velger slik at en ikke lar teknologien styre hvordan organisasjonen skal jobbe. Gjort på riktig måte er det veldig mye teknologi som kan bidra til at organisasjoner oppnår sine mål. Ved å være bevisst på hvor en skal begynne helt fra bunnen og hvilke områder som bør legges til rette for at redaktørene kan gjøre jobben sin uavhengig av et utviklingsteam – da mener jeg at en har begynt i riktig ende.

Mollie

Vi har i dialog med flere av våre kunder som har ønsket headless gått igjennom det samme rasjonalet som beskrevet over. Ved å gå i dybden på behovene kundene har så er det få tilfeller hvor vi har landet på at det er nødvendig eller god ressursbruk å utvikle headless plattform. En av de siste casene hvor vi landet på akkurat dette valget var for Mollie. Mollie er en nederlandsk betalingstilbyder. 

Organisasjonen til Mollie krever en kombinasjon av flere typer løsninger både headless og ikke headless – men for sitt globale nettsted valgte de å benytte WordPress på vanlig måte. 

Dette valget var spesielt basert på to sentrale faktorer; redaktørene i Mollie trenger et verktøy som er tilpasset sine behov og de er avhengig av et verktøy som det er bred kunnskap om for de som skal lage innhold. Og de ønsket en plattform hvor de kunne iterere raskere uten å måtte vedlikeholde flere kodebaser for å oppnå det designdrevne grensesnittet de ønsker at kundene skal møtes med.

Mollie er i dag godt rustet for å skalere til nye markeder utover de 7 de er tilstede i. Deres mål er å gjøre betalingsløsninger på nett enklere. Vi i Dekode er stolte av å kunne bidra til at bedrifter som dem oppnår sine mål.

Og ikke minst å lage en god løsning som passet deres behov – headless eller ikke headless.