Senaste åren har marknaden pratat allt mer om begreppet “headless CMS” vilket innebär att man särskiljer på back-end och front-end. Det är en av de största trendbrotten i vår bransch sedan responsive. Vi har senaste året använt WordPress som CMS för headless i flera projekt. Så här tänker en av våra utvecklare, Christoffer Larsson, om lösningen.
Vilka är de generella fördelarna med headless?
Hastighet framförallt, de två vanligaste sätten är antingen statiskt genererade sidor eller det som kallas för hydrated web application – vilket i princip innebär att frontend laddar minsta möjliga data från APIet för varje klick efter första request.
Det blir allt vanligare att kunder jobbar digitalt på flera fronter, t ex en sajt, en app och ett antal kampanjsidor. Då kan det vara önskvärt att ha ett centralt API för allt innehåll, så kallad content-as-a-service, för att dra ner på kostnader.
Att frigöra frontend från CMS betyder att det blir lättare att uppdatera besökarens upplevelser, och hålla frontend fräsch, utan att behöva lägga tid på att ändra både frontend och CMS.
Triggerfish kör WordPress som CMS för headless, vad betyder det för dig som utvecklare?
Jag skulle säga att WordPress är ett bra CMS-framework för utvecklare. Det går snabbt och lätt att nyttja all inbyggd generell funktionalitet, men även att göra specifika, kundanpassade lösningar. Open Source-communityt är väldigt stort och det finns en rad bra plugins att utnyttja för att dra ner på utvecklingstid.
Många kunder efterfrågar headless-lösningar just nu. Vilka fördelar ser du för kundernas del?
Först och främst har WordPress ett redaktörsgränssnitt som de flesta webbredaktörer är mycket bekanta med eller i alla fall stött på. De gör att de känner igen sig även i en headless-lösning vilket i sin tur gör att kundens utbildningskostnad och kom-igång-tid går ner drastiskt. Vi har dessutom lyckats adaptera en hel rad plugins som redaktörer är vana vid att kunna utnyttja, exempelvis Yoast SEO, Redirection och WooCommerce.
Vad är den största utmaningen med headless utvecklingsmässigt?
Jag skulle säga att det är att gifta ihop WordPress med headless. Koncept som förhandsvisning och lösenordsskyddade eller privata sidor är inte lika enkelt när man inte har med sig redaktörens inloggning till besökarens frontend.
Så hur har ni löst det?
Vi har valt att inte sprida logiken så mycket. Det innebär att vi låter frontend endast visa upp vad API:et serverar baserat på nuvarande URL. På så sätt kommer båda systemens styrkor till rätta vilket skapar oändligt mycket mer dynamik.
Triggerfish jobbar med Next.js som frontend-framework för den publika webben i flera headless-projekt. Berätta mer!
Vi valde att jobba med React då vi hade mest och bäst erfarenhet av det sedan tidigare. Valet av ramverk föll på just Next.js då det är väl etablerat och har ett stort community. Vi jämförde också med största konkurrenten Gatsby och upplevde att Next.js tickade flest boxar.
Kort om headless
Traditionellt sitter den publika webbsidan ihop med sitt CMS och de utvecklas därmed tillsammans. Med en headless-lösning frikopplas innehållet från tekniken. Det betyder att ett headless CMS:et sköter innehållshanteringen genom att hämta innehållet via ett API. Hur det sedan presenteras är upp till designer och utvecklare.