Hodeløs og APIer
Hodeløs er et begrep som er veldig trendy for tiden, og har vært det i noen år nå. I forbindelse med dette snakker de også ofte om APIer og ulike frontend-rammeverk som React eller Angular. Her tenkte jeg å prøve å gå igjennom litt hva hodeløs betyr, og hva det betyr for et nettprosjekt.
Hva betyr hodeløs?
Begrepet hodeløs dukker opp stadig oftere i nettverdenen. Mange CMS, e-handelsplattformer og lignende markedsfører seg med at de er hodeløse, og at de derfor burde være mer egnet for hvordan moderne nettsider er bygget opp.
Så hvordan er det forskjellig fra tradisjonelle nettsteder? For bare noen få år siden ble nettsider normalt bygget på en måte der grensesnittet og det underliggende systemet var to deler av samme løsning. Grensesnittene var nært knyttet til plattformfunksjonaliteten, og både grensesnitt og plattform var på de samme serverne. Med et hodeløst tankesett frakobler man disse, noe som får konsekvenser på mange ulike plan, for eksempel innen design, utviklingsarbeid og hosting, men også i redaksjonelt arbeid og hvordan man jobber med ulike kanaler.
Headless betyr at det underliggende systemet – i vår webverden vanligvis et CMS eller en e-handelsplattform – ligger som et eget system, hvor all informasjon håndteres uten at du trenger å vite noe om hvordan den skal presenteres eksternt. Hvordan den presenteres styres av et grensesnitt som i seg selv er et eget system som ikke bryr seg om hvor informasjonen kommer fra og hvordan den ble til. Grensesnittet fokuserer i stedet kun på hvordan informasjonen skal presenteres for en besøkende. Kommunikasjonen mellom systemene skjer da via et såkalt API (“Application Programming Interface”) som gjør det mulig for data å sendes frem og tilbake mellom systemene.
Hvordan påvirker det nettstedet mitt?
Litt forenklet kan du tenke deg at med den tradisjonelle måten å bygge nettet på, ble alt innholdet som ble laget for nettet bare laget for nettet. Når du satte opp en ny side i ditt CMS, ble det gjort ved å legge et toppbilde øverst på siden, litt vilkårlig informasjon i en boks til høyre og ingress og hovedtekst på siden – gjerne med litt styling for å få den til å passe så godt som mulig akkurat der. I en hodeløs løsning prøver man å tenke mindre på presentasjonen, og jobbe mer med ren informasjon (for eksempel: det er kanskje ikke et “toppbilde” og en “høyre rute”, men et “primærbilde” og et felt for “sekundært innhold” i stedet). Brukergrensesnittet er da ansvarlig for hvor og hvordan dette innholdet presenteres til slutt, og hvis høyre boks skal flyttes til under teksten, så vil du ikke ha det problemet at alt som er spesifikt tilpasset høyre kolonne vil ikke lenger være der. På overflaten er dette en liten endring, men endringen i hvordan du tenker innhold gjør ofte sluttresultatet bedre. Dette er dels fordi redaktøren ikke trenger å gjøre om innhold hvis grensesnittet endres, dels fordi det er lettere å gjøre denne typen endringer, men også fordi informasjonen plutselig kan brukes på mange flere måter og steder.
Så hva er fordelene?
Det høres bra ut, men gjør det faktisk en reell forskjell? Ja, det kan du fortsatt si at det gjør. Fordelen med at innholdet ikke lenger er tett knyttet til presentasjonen er at du nå står fritt til å bruke innholdet på andre måter. Bør det utvikles en mobilapp hvor det samme innholdet skal brukes, men presenteres på en helt annen måte? Trenger du en nyhetsfeed på en skjerm i bedriftens lobby? Ønsker en partner å vise informasjonen din på nettstedet sitt? Sånt blir plutselig mulig uten (i hvert fall i teorien) å måtte bygge om noe. Å presentere informasjon fra samme system i flere kanaler er en av de store fordelene. Det trenger ikke nødvendigvis være helt separate typer kanaler heller, et felles bruksområde er å ha et underliggende system som gir informasjon til flere nettsider, for eksempel for en gruppe med flere merker som har like behov men må være presentert med helt andre grafiske profiler.
Et annet aspekt er utskiftbarhet. Hvis du vil gjøre om nettstedet ditt, trenger du ikke nødvendigvis å bytte ut alt; det er nok å gjøre om presentasjonslaget. Dette gjelder hele nettsiden, men kan selvsagt også brukes på enkeltdeler av den. Du vil kanskje bare endre startsiden eller hvordan produkter på en e-handel presenteres, og da blir dette mye enklere. Selv små endringer er lettere å gjøre, for eksempel å flytte rundt eller gjøre om individuelle komponenter på en side. Hvis du vil erstatte CMS-en din, trenger du ikke nødvendigvis å bytte ut presentasjonslaget heller.
Mange ser også fordeler ved at når man ikke tenker på innhold og design samtidig, er det vanskeligere å gjøre feil. Et klassisk problem når redaktører jobber med innhold som er strukturert etter hvordan en side vil se ut, betyr det ofte at man velger å bevisst gjøre noe «galt» for å oppnå noe helt spesifikt. På mange nettsider kan dette bety at siden ikke føles homogen og at designet sprer seg, men når man i stedet jobber med innhold etter hva innholdet er fremfor hvordan det skal presenteres, er ikke dette lenger et like stort problem.
Utviklere liker headless
Et annet positivt aspekt ved hodeløse løsninger er at det gir større frihet til designere, fordi med hodeløse blir det lettere å utvikle mer avanserte grensesnitt. Det åpner også for jevnere arbeidsflyter, raskere endringer og vi i Cloud Nine føler generelt at det er mer rom for kreative og moderne løsninger med denne måten å bygge nettsider på.
Når vi bygger presentasjonslaget bruker vi ofte React-rammeverket (utviklet av Facebook), men Angular, Vue og noen få andre er også populære blant nettutviklere. Rammeverket tar over all styring av selve siden, og muliggjør mye smidige ting, som at siden aldri trenger å laste helt på nytt mellom sidevisninger, det er lettere å gjøre fine overganger, det er lettere å laste inn innhold etter behov, og å gjengi visninger som er tilpasset enheten de vises på. Det blir rett og slett en raskere, penere og mer moderne løsning.
Så dette var en “kort” oppsummering av hva hodeløs er og hva forskjellene er mot de mer tradisjonelt strukturerte løsningene. Kort fortalt er det altså å frikoble innhold fra presentasjon, noe som oppnås gjennom kommunikasjon via APIer.
Ronnie Hillgren, systemutvikler hos Cloud Nine