Headless och API:er

Headless är ett begrepp som är väldigt trendigt för närvarande, och så har det varit i några år nu. I samband med detta pratar man också ofta om API:er och diverse frontend-ramverk som till exempel React eller Angular. Här tänkte jag försöka gå igenom lite vad headless betyder, och vad det innebär för ett webbprojekt.

• Vad innebär headless?
• Hur påverkar det min webbplats?
• Vad är då fördelarna?
• Utvecklare gillar headless

Vad innebär headless?

Uttrycket headless dyker upp allt oftare i webbvärlden. Många CMS, e-handelsplattformar och liknande marknadsför sig själva med att de är just headless, och att de därmed ska vara mer lämpade för hur moderna webbplatser byggs.

Så, hur skiljer sig det från traditionella webbplatser? För bara några år sedan så byggdes webbplatser normalt på ett sätt där gränssnittet och bakomliggande system var två delar i samma lösning. Gränssnitten var hårt knutna till plattformsfunktionaliteten och både gränssnitt och plattform låg på samma servrar. Med ett headless-tänk så frikopplar man dessa, vilket har följder på många olika plan, till exempel inom design, utvecklingsarbete och hosting, men också inom redaktionellt arbete och hur man jobbar med olika kanaler.

Headless innebär alltså att det bakomliggande systemet – i vår webbvärld oftast ett CMS eller en e-handelsplattform – ligger som ett separat system, där all information hanteras utan att man behöver veta något om hur det kommer att presenteras utåt. Hur det presenteras styrs av ett gränssnitt som i sig är ett eget system som inte bryr sig om varifrån informationen kommer och hur den skapats. Gränssnittet fokuserar istället bara på hur informationen ska presenteras för en besökare. Kommunikationen mellan systemen sker sedan via ett så kallat API (“Application Programming Interface”) som gör det möjligt för data att skickas fram och tillbaka mellan systemen.

Hur påverkar det min webbplats?

Lite förenklat kan man tänka sig att med det traditionella sättet att bygga webb, så var allt innehåll som skapades för webben just precis skapat bara för webben. När man satte upp en ny sida i sitt CMS, så gjordes det genom att lägga en toppbild längst upp på sidan, lite godtycklig information i en ruta till höger och ingress samt huvudtext på sidan – gärna med lite stilsättning för att det ska passa så bra som möjligt just där. I en headless-lösning försöker man tänka mindre kring presentationen, och jobba mer med ren information (till exempel: det kanske inte finns en “toppbild” och en “högerruta”, utan en “primär bild” och ett fält för “sekundärt innehåll” istället). Användargränssnittet är sedan det som ansvarar för var och hur detta innehåll presenteras i slutändan, och om högerrutan ska flyttas till nedanför texten, så kommer man inte få problemet att allt som är specifikt anpassat för högerkolumnen inte längre kommer att ligga där. Ytligt sett är detta en liten förändring, men förändringen i hur man tänker på innehåll gör ofta att slutresultatet blir bättre. Det beror dels på att redaktören inte behöver göra om innehåll om gränssnittet förändras, dels på att det är lättare att göra den här typen av förändringar, men också på att informationen helt plötsligt kan användas på många fler sätt och ställen.

Vad är då fördelarna?

Det låter ju bra, men påverkar det faktiskt någonting på riktigt? Ja, det får man ändå säga att det gör. Vinsten med att innehållet inte längre är hårt knutet till presentationen, är att man nu har fritt fram att använda innehållet på andra sätt. Ska en mobilapp tas fram där samma innehåll ska användas, men presenteras på ett helt annat sätt? Behövs ett nyhetsflöde på en skärm i företagets lobby? Vill en partner presentera er information på sin webbplats? Den typen av saker möjliggörs helt plötsligt utan att man (åtminstone i teorin) behöver bygga om någonting. Att presentera information från samma system i flera kanaler är en av de stora fördelarna. Det behöver inte nödvändigtvis vara helt separata typer av kanaler heller, ett vanligt användningsområde är att ha ett bakomliggande system som tillhandahåller information till flera webbplatser, till exempel för en koncern med flera varumärken som har liknande behov men ska presenteras med helt olika grafiska profiler.

En annan aspekt är utbytbarheten. Om man vill göra om sin webbplats, behöver man inte nödvändigtvis byta ut allt; det räcker med att göra om presentationslagret. Detta gäller för hela webbplatsen, men går förstås också att applicera på enskilda delar av den. Man kanske bara vill byta ut startsidan eller hur produkter på en e-handel presenteras, och då kommer detta bli mycket enklare. Även små förändringar är lättare att göra, som att bara flytta runt eller göra om enskilda komponenter på en sida. Vill man byta ut sitt CMS behöver man heller inte nödvändigtvis byta ut sitt presentationslager.

Många ser också fördelar med att när man inte tänker på innehåll och design samtidigt, så är det svårare att göra fel. Ett klassiskt problem när redaktörer jobbar med innehåll som är strukturerat efter hur en sida kommer att se ut, så medför det ofta att man väljer att medvetet göra lite “fel” för att uppnå något väldigt specifikt. På många webbplatser kan det medföra att siten inte känns homogen och att designen spretar, men när man istället jobbar med innehåll utefter vad innehållet är snarare än hur det kommer att presenteras, är detta inte längre ett lika stort problem.

Utvecklare gillar headless

En annan positiv aspekt av headless-lösningar är att det ger större friheter för designers, eftersom det med headless blir lättare att utveckla mer avancerade gränssnitt. Det möjliggör också smidigare arbetsflöden, snabbare förändringar och hos oss på Cloud Nine har vi generellt känslan av att det finns mer utrymme för kreativa och moderna lösningar med det här sättet att bygga webbplatser.

När man bygger presentationslagret använder vi oss ofta av ramverket React (utvecklat av Facebook), men även Angular, Vue och några till är populära bland webbutvecklare. Ramverken tar över hela hanteringen av själva siten, och möjliggör en mängd smidiga saker, såsom att siten aldrig behöver laddas om helt mellan sidvisningar, det är lättare att göra snygga övergångar, det är lättare att ladda in innehåll efter behov och att rendera vyer som är anpassade efter den enhet de visas på. Det blir helt enkelt en snabbare, snyggare och modernare lösning.

Så, det här var en “kort” sammanfattning av vad headless är och vad skillnaderna är mot de mer traditionellt strukturerade lösningarna. Kortfattat, så är det alltså att frikoppla innehåll från presentation, något som uppnås genom kommunikation via API:er.

Ronnie Hillgren, Systemutvecklare på Cloud Nine