Nyheder / 09 okt 2018

Hovedløs og API’er

Hovedløs er et udtryk, der er meget trendy i øjeblikket, og som har været det i et par år nu. I forbindelse hermed taler de også ofte om API’er og diverse front-end frameworks såsom React eller Angular. Her tænkte jeg, at jeg ville prøve at gennemgå lidt, hvad hovedløs betyder, og hvad det betyder for et webprojekt.

Hvad betyder hovedløs?

Begrebet hovedløs optræder oftere og oftere i webverdenen. Mange CMS, e-handelsplatforme og lignende markedsfører sig med, at de er hovedløse, og at de derfor burde være mere velegnede til, hvordan moderne hjemmesider er bygget op.

Så hvordan adskiller det sig fra traditionelle websteder? For blot få år siden blev hjemmesider normalt bygget på en måde, hvor grænsefladen og det underliggende system var to dele af den samme løsning. Grænsefladerne var tæt knyttet til platformens funktionalitet, og både interface og platform var på de samme servere. Med et hovedløst mindset afkobler man disse, hvilket har konsekvenser på mange forskellige niveauer, fx inden for design, udviklingsarbejde og hosting, men også i redaktionelt arbejde og hvordan man arbejder med forskellige kanaler.

Headless betyder, at det bagvedliggende system – i vores webverden normalt et CMS eller en e-handelsplatform – er placeret som et separat system, hvor alle informationer håndteres, uden at du behøver at vide noget om, hvordan den vil blive præsenteret eksternt. Hvordan det præsenteres styres af en grænseflade, som i sig selv er sit eget system, der er ligeglad med, hvor informationen kommer fra, og hvordan den er skabt. Interfacet fokuserer i stedet kun på, hvordan informationen skal præsenteres for en besøgende. Kommunikationen mellem systemerne foregår herefter via et såkaldt API (“Application Programming Interface”), der gør det muligt at sende data frem og tilbage mellem systemerne.

Hvordan påvirker det mit websted?

Lidt forenklet kan man forestille sig, at med den traditionelle måde at bygge nettet på, så blev alt det indhold, der blev skabt til nettet, kun skabt til nettet. Når du opretter en ny side i dit CMS, foregik det ved at sætte et topbillede øverst på siden, nogle vilkårlige informationer i en boks til højre og præamble og hovedtekst på siden – gerne med lidt styling til få det til at passe så godt som muligt lige der. I en hovedløs løsning forsøger man at tænke mindre over præsentationen, og arbejde mere med ren information (f.eks.: der må ikke være et “øverste billede” og en “højre rude”, men et “primært billede” og et felt for “sekundært indhold” i stedet). Brugergrænsefladen er så ansvarlig for, hvor og hvordan dette indhold præsenteres i sidste ende, og hvis den højre boks skal flyttes til under teksten, så vil du ikke have det problem, at alt, der er specifikt tilpasset til højre spalte, vil ikke længere være der. På overfladen er der tale om en lille ændring, men ændringen i, hvordan du tænker indhold, gør ofte slutresultatet bedre. Det skyldes dels, at redaktøren ikke skal lave om på indhold, hvis grænsefladen ændrer sig, dels fordi det er nemmere at lave denne type ændringer, men også fordi informationen pludselig kan bruges mange flere måder og steder.

Hvad er så fordelene?

Det lyder godt, men gør det faktisk en reel forskel? Ja, det kan man stadig sige, at det gør. Fordelen ved, at indholdet ikke længere er tæt knyttet til præsentationen, er, at du nu er fri til at bruge indholdet på andre måder. Skal der udvikles en mobil app, hvor det samme indhold skal bruges, men præsenteres på en helt anden måde? Har du brug for et nyhedsfeed på en skærm i virksomhedens lobby? Ønsker en partner at vise dine oplysninger på deres hjemmeside? Den slags bliver pludselig mulig uden (i hvert fald i teorien) at skulle bygge noget om. At præsentere information fra samme system i flere kanaler er en af de store fordele. Det behøver heller ikke nødvendigvis at være helt adskilte typer af kanaler, et fælles anvendelsesområde er at have et underliggende system, der giver information til flere hjemmesider, fx for en gruppe med flere brands, der har lignende behov, men som skal være præsenteret med helt andre grafiske profiler.

Et andet aspekt er udskiftelighed. Hvis du vil lave din hjemmeside om, behøver du ikke nødvendigvis at udskifte alt; det er nok at lave præsentationslaget om. Dette gælder for hele hjemmesiden, men kan naturligvis også anvendes på enkelte dele af den. Du vil måske bare ændre startsiden eller hvordan produkter på en e-handel præsenteres, og så bliver det meget nemmere. Selv små ændringer er nemmere at lave, såsom blot at flytte rundt eller gentage individuelle komponenter på en side. Hvis du vil udskifte dit CMS, behøver du heller ikke nødvendigvis at udskifte dit præsentationslag.

Mange ser også fordele ved, at når man ikke tænker indhold og design på samme tid, er det sværere at lave fejl. Et klassisk problem, når redaktører arbejder med indhold, der er struktureret efter, hvordan en side kommer til at se ud, betyder det ofte, at man vælger bevidst at gøre noget “forkert” for at opnå noget helt specifikt. På mange hjemmesider kan det betyde, at siden ikke føles homogen, og at designet breder sig, men når man i stedet arbejder med indhold efter, hvad indholdet er frem for hvordan det vil blive præsenteret, er det ikke længere et så stort problem.

Udviklere kan lide headless

Et andet positivt aspekt ved hovedløse løsninger er, at det giver større frihed til designere, fordi det med hovedløse bliver nemmere at udvikle mere avancerede grænseflader. Det giver også mulighed for smidigere arbejdsgange, hurtigere ændringer og vi hos Cloud Nine føler generelt, at der er mere plads til kreative og moderne løsninger med denne måde at bygge hjemmesider på.

Når vi bygger præsentationslaget, bruger vi ofte React frameworket (udviklet af Facebook), men Angular, Vue og et par andre er også populære blandt webudviklere. Rammerne overtager al styring af selve siden, og muliggør en masse glatte ting, såsom at siden aldrig behøver at genindlæse helt mellem sidevisninger, det er nemmere at lave flotte overgange, det er nemmere at indlæse indhold efter behov, og at gengive visninger, der er tilpasset den enhed, de vises på. Det bliver simpelthen en hurtigere, smukkere og mere moderne løsning.

Så dette var en “kort” opsummering af, hvad hovedløs er, og hvad forskellene er til de mere traditionelt strukturerede løsninger. Kort sagt er det således at afkoble indhold fra præsentation, noget der opnås gennem kommunikation via API’er.

Ronnie Hillgren, systemudvikler hos Cloud Nine