Alle snakker om headless om dagen. Men hva er det med denne nye teknologien som får utviklere til å ta salto av glede og bedriftseiere til å bruke masse penger for å få tak i det? La oss bruke et enkelt eksempel for å forklare.
Tenk deg en produsent av olabukser, som driver en fabrikk, et lagerhus og en outlet-butikk på én og samme plass. Lageret henter bukser fra fabrikken og distribuerer dem direkte til kunder gjennom butikken. Fabrikken og lageret er uendelig store, men butikken har begrenset med plass. Kundene er dermed tilsvarende begrenset i hvor mye av beholdningen de får se på en gang, men det er greit fordi bukser er bukser.
Én dag oppdager bedriften at kundenes smak har endret seg. de vil ha et større utvalg av farger og stiler, og kanskje noen slengbukser og chinos i tillegg.
Outleten responderer ved å sette ut et større utvalg bukser i butikken. Det blir litt rotete i begynnelsen, men etter en stund finner de måter å arrangere hyllene på som kundene kan like. De deler også opp butikken i seksjoner, sånn at de forskjellige stilene er enklere å lete gjennom. Fabrikken og lageret bryr seg ikke så mye; de bare lager buksene de blir bedt om å lage.
Når vi snakker om et content management system (CMS) er outleten en tradisjonell frontend (det du ser når du besøker en nettside). Lageret og fabrikken er backend og databasen, som dytter ut olabukser, eller kode, i den mengden frontenden etterspør.
Situasjonen er fin så lenge de bare har en butikk. Og det gikk lenge greit for de fleste bedrifter også, for de trengte bare å forholde seg til en nettside, som kun trengte å vises på en vanlig nettleser på en vanlig datamaskin.
Men da mobil og nettbrett ble mer og mer brukt, og til slutt fikk flere brukere enn vanlige nettlesere, måtte frontenden endres. De måtte omorganisere hva de viste frem og hvordan de viste det, sånn at brukerne fortsatt enkelt kunne finne det de lette etter.
Men i løpet av de siste årene har ting endret seg enda mer dramatisk for produksjonsbedriften. Kundene ønsker ikke lenger å reise hele veien til butikken for å kjøpe det de trenger. Og de trenger ikke lenger bare bukser, men også skjorter, skjørt, badetøy og solbriller. Du husker at fabrikken og lageret er uendelig store, så de er ikke særlig påvirket av dette. Men butikken må endres. De har ikke nok plass til å tilby alle kundene det de trenger. Bedriften må utvide.
For å transportere varene til de nye butikkene de åpner over hele regionen trenger de lastebilsjåfører. Sjåførene kjører mellom lageret og butikkene. Hver sjåfør er ansvarlig for en butikk, og de sørger for at butikkene har akkurat det de trenger for å imøtekomme kundenes behov.
På samme måte vil ikke dagens kunder kun konsummere innhold på bare en måte. Hva med når de vil se innhold på en infoskjerm? En smartklokke? Eller en kaffemaskin?!?
Lastebilsjåføren er et Application Programming Interface, eller API. API-et transporterer informasjon på måten individuelle skjermer ønsker, rett fra lageret. Bedriftens magiske, uendelig store fabrikk og lager blir der de er, fordi å behandle data på ett sted er veldig effektivt. Men outlet-butikken er ikke så sentral for driften deres lenger, det er bare en av mange måter de selger produktene sine på.
Når butikker åpnes i andre deler av regionen er de frakoplet (eng: decoupled) fra lagerbygningen. Den tilhørende outleten pleide å være bedriftens hode, eller det de primært brukte for å kommunisere med kundene sine, om du vil. Men nå som butikken er flyttet er kjerneoperasjonen hodeløs (eng: headless)
En annen ting som er på engelsk er eboken vår om headless, som gir deg en litt dypere innføring i hvordan headless fungerer og kan brukes.
I virkeligheten har det ene hodet blitt erstattet med flere hoder som den mytologiske hydraen, men det navnet var visst opptatt.
Et headless content management system sender ut data omtrent på samme måte som før, men de forskjellige presentasjonsflatene (frontendene) kan ofte avvike ganske mye fra hverandre i utseende.
Moderne CMS-er som Drupal og WordPress er i stand til å gjøre mer og mer, og er i mange tilfeller det digitale navet i en bedrift. Når de brukes som et headless CMS er de fortsatt sentrale, men byrden av å i tillegg bære en frontend er løftet fra dem.
La oss si at en elektronikkbutikk ønsker å la kunder kjøpe telefoner gjennom den stemmestyrte assistenten Alexa. Med headless kan de fortsatt lage innhold og kampanjemateriell, kontrollere brukertillatelser og alle de andre logistiske tingene de trenger, gjennom CMS-et. De trenger bare å sende informasjonen til forskjellige "hoder". Med et tradisjonelt (monolittisk) CMS måtte hele frontenden blitt omskrevet for å tilpasses de nye plattformene.
Dette er fantastisk for utviklere, bedriftseiere og administratorer, fordi de kan ha oversikt over hele kodebasen og operasjonen på ett sted. Det er flott for innholdsprodusenter og markedsførere, fordi de kan fortsatt lage innhold i for eksempel Gutenberg og sende det til forskjellige markedsføringsplattformer.
Headless er selvfølgelig ikke for alle (enda), men for bedrifter med store datasett og varierte publikasjonsplattformer er det gull verdt.
Det er mye mer å si om headless, som hvordan det gjør at man kan bruke flere CMS-er eller datakilder for samme frontend, hvordan det forenkler migrasjoner, og slike ting. Men før du leser deg opp på detaljene er det en god ide å se hvor relevant det er for din bedrift, og hvor mange fordeler headless kan gi deg.
Hver bedrift er unik, men det er noen felles parametre som kan fortelle deg om din bedrift i hvert fall burde vurdere å bytte til headless. Hvis du vil, kan du svare på de 12 ja/nei spørsmålene i quizen over for å hjelpe deg til å ta en beslutning. Og hvis du fortsatt har spørsmål vil vi gjerne høre fra deg. En ekspert på headless vil i tilfelle svare deg snart!