10 päätöntä väittämää headlessista

Headless viittaa arkkitehtuuriin, jossa digitaalisen palvelun frontend ja backend on erotettu toisistaan. Toimimalla näin pystytään saavuttamaan esimerkiksi nopeampia latausaikoja, sovellusmaisempaa käyttökokemusta, helpompaa skaalattavuutta, parempaa hakukonelöydettävyyttä, korkeampaa tietoturvaa ja joustavuutta, kun arkkitehtuuri ei ole niin sidoksissa yhteen järjestelmään.  

Frontendit rakennetaan pääsääntöisesti JavaScriptilla, ohjelmointikielellä, jota kaikki selaimet pystyvät suorittamaan ja jolla kaikki käyttäjäinteraktiot nykyisellään rakennetaan. Backendit taas voidaan valita vapaasti tarpeen mukaan käyttäen teknologioita, jotka tehokkaimmin sopivat tarvittavan ominaisuuden tuottamiseen. Headlessin avulla samaa sisältöä voidaan helposti käyttää useassa eri palvelussa ja frontendissä. Yksi frontend voi olla vaikkapa aulanäyttö, kun toinen on yrityksen markkinointisivusto. 

Kuten aina, liittyy uudenlaisen arkkitehtuurin käyttöönottoon oppimiskäyrää ja tästäkin maasta löytyy monia esimerkkejä heikosti toteutetuista headless-projekteista.  
 
Headlessin osakseen saama kritiikki Suomessa on kuitenkin ylimitoitettua ja suurimmaksi osaksi perusteetonta. Kokosin tähän blogiin yleisimmin headlessia vastaan esitettyjä väitteitä ja vastaan kritiikkiin. Meillä on Knowit Experiencessa jo yli puolen tusinaa headless-projekteja vyöllä, joten olemme törmänneet jo lähes kaikkiin mahdollisiin ongelmakohtiin ja kehittäneet niihin toimivat ratkaisut. 

Väite 1. Headless on vastaus ongelmaan, jota ei ole vielä keksitty. 

Headless tuskin täysin ratkaisee yhtäkään ongelmaa, mutta se merkittävästi parantaa esimerkiksi tietoturvan ja skaalautuvuuden hallintaa, sekä helpottaa parhaimman mahdollisen käyttökokemuksen toteuttamista. Hömpötyksen sijaan, tässä on kyse yksinkertaisesti työkalujen kehittymisestä siihen pisteeseen, että vähemmällä saa enemmän. 

Laadukkaan käyttöliittymän toteuttaminen vaatii nykypäivänä paljon erikoisosaamista. On tärkeää, että ammattilaiset voivat myös käyttää parhaita mahdollisia työkaluja ilman kompromisseja. Tämä näkyy työn sujuvuutena, tuottavuutena ja kehittäjien tyytyväisyytenä.  

Headless-toteutusmalli kulkee käsi kädessä kehityksen kanssa, jossa hyödynnetään reunalaskentaa, palvelittomia ratkaisuja ja SaaS-tuotteita. Headless mahdollistaa myös ajatustavan muutoksen siihen, miten organisaatio toteuttaa ja valitsee tietojärjestelmiään sekä niihin liittyviä käyttöliittymiä. Teknologioita tulee ja menee, harvoin kaiken keskittäminen yhdelle alustalle on osoittautunut kestäväksi.  

Väite 2. Headless sivustot kuluttavat yhtä paljon palvelinresursseja ja pullonkaulana on kuitenkin se julkaisujärjestelmä 

Konkreettisimmin iloa headlessista saadaan vasta, kun julkaisujärjestelmä on aidosti irrotettu frontendistä. Usein näkee ratkaisuja, joissa headless-sivusto lataa kaiken tiedon suoraan julkkarista, ollen vain "ikkuna" sen rajapintaan. Tämä luonnollisesti kuormittaa julkaisujärjestelmää, ihan kuten tavalliset sivunäytötkin, lisäksi paljastaen myös sen rajapinnat internetiin. 

Headless-toteutuksissa onkin järkevämpää käyttää Jamstack-mallia, missä sivut generoidaan staattiseksi ja mahdolliset dynaamiset toiminnallisuudet suoritetaan reunalaskentana. Yksittäiseen sivunäyttöön käytetään minimaalisesti resursseja ja käytännössä sisällönjakoverkosto (CDN) vain työntää valmiin sivun ulos muististaan. 

Kun Jamstack-mallissa ylläpitäjä tekee sivustolla muutoksia, välitetään tieto herätteinä frontend-ohjelmistolle, joka käy virkistämässä sivun ja muut mahdolliset näkymät, joissa sivun sisältöä käytetään. Tämä pitää sisällön ajantasaisena ja vähentää tarvetta toistuvasti hakea yhtä ja samaa sisältöä julkaisujärjestelemästä. 

Kun ajattelet julkaisujärjestelmää vain yhtenä palikkana kokonaisuudessa, sinulla onkin kymmeniä eri vaihtoehtoja vaikkapa kaupankäyntiin, käyttäjätilien hallintaan tai isomman sisältömassan julkaisuun eri kanavissa.  

Väite 3. Headlessin kustannukset ovat paljon suuremmat kuin perinteinen monoliittisen CMS:n päälle rakentaminen 

Jos ajatellaan esimerkiksi monoliittista WordPress-sivustoa, komponentteja, selvitettävää ja opittavaa on headlessissa taatusti enemmän. Kustannukset riippuvat pitkälle siitä, kuinka rutinoitunut toimittaja on kyseiseen toteutusmalliin. Hiotulla arkkitehtuurilla, valmiiden kirjastojen käytöllä ja hyvällä pohjatyöllä räätälöitäväksi jäävät vain ne samat asiat, jotka monoliittisessakin projektissa tulisi rakentaa.  

Joka tapauksessa sivustolle rakennetaan ulkoasu, käyttöliittymä ja interaktiivisia ominaisuuksia. Headlessissa työkalut vain ovat paremmin suunniteltu ja toteutettu juuri näiden asioiden toteuttamiseen. Reactin ekosysteemistä löytyy huikea määrä valmiita saavutettavia, moderneja ja käyttökelpoisia komponentteja. Samaa hyötyä on vaikea saavuttaa esimerkiksi WordPressin kirjavassa teemoitusviidakossa. 

Headless-toteutuksissa jatkuvat kustannukset jakautuvat useammalle taholle kuin vain yksittäiselle hosting-kumppanille. Pienellä liikennemäärällä nämä kustannukset ovat hieman suurempia kuin esimerkiksi monoliittisen WordPressin tapauksessa, mutta mitä isommaksi liikennemäärä nousee, sitä halvemmaksi suhteelliset kulut muodostuvat. Osa näistä kustannuksista kasvaa myös liikenteen ja käytön mukaan, mutta käytännössä kuitenkin pysytään vielä suorituskykyyn suhteutettuna erittäin maltillisella tasolla. Lisäksi kannattaa huomioida, että palvelittomassa toimintaympäristössä itse infrastruktuurin ylläpitoon ja hallintaan ei pala rahaa.  

Väite 4. WordPress ei ole headless-CMS. 

WordPress on helposti konfiguroitava ja helppokäyttöinen julkaisujärjestelmä, joka on monelle jo tuttu alusta. Se taipuu headless-käyttöön siinä missä moni muukin sisällönhallintajärjestelmä. Kilpailuetuna moneen SaaS-julkkariin on lisenssivapaus, helppo räätälöitävyys ja tuttuus. WordPressin suosio ja pysyvyys myös vetoaa, vaikka markkinoille tulee jatkuvasti uusia headless-julkkareita. 

Kun WordPressiä käytetään headlessina rajapinnan kautta, jää sen raskas teema latautumatta. Kun muutenkin headless-CMS vastaanottaa liikennettä todella vähän, palvelinresurssien tarve on monoliittista radikaalisti pienempi. Ylläpitäjälle käyttöliittymä toimii aina takkuilematta riippumatta sivustolle tulevasta liikenteen määrästä. 

Luonnollisesti headless-arkkitehtuurissa on hankala hyödyntää täysin WordPressin lisäosaekosysteemiä etenkin niissä tapauksissa, missä lisäosa tuottaa näkymiä frontendiin. Harvemmin tosin käytämme Knowit Experiencella tallaisia lisäosia ylipäätään, vaikka toteuttaisimme sivuston monoliittisena. Emme halua muutenkaan lähteä kilpailemaan saittitehtaiden kanssa, joissa käytännössä vain lätkitään lisäosia päällekkäin ja toivotaan parasta.

Moneen muuhun headless-julkkariin verrattuna, WordPress mahdollistaa sisältötyyppien ja kenttien kehittämisen täysin ohjelmallisesti niin, että muutokset tallentuvat myös versionhallintaan. Tämä helpottaa kehitystyötä, kun samoja muutoksia ei tarvitse käydä klikkailemassa monessa ympäristössä.  
  

Väite 5. Headless on järkevä valinta vasta kun mittakaava on suuri. 

Headlessina voidaan rakentaa sivusto, jossa ei ole CMS:sää taustalla täysin samoilla työkaluilla kuin sivusto, joka käyttää sisältöä vaikkapa neljästä eri lähteestä. Pienikin sivusto hyötyy headlessin tarjoamista hyödyistä etenkin hakukoneoptimoinnin, käyttökokemuksen ja nopeuden osalta. Kun Google järjestää hakutuloksia osin sivuston nopeuden mukaan, voi nopeasti toimiva sivusto olla merkittävä kilpailuetu hakukonenäkyvyydessä. 

Headless ei tietenkään voi kilpailla hinnalla WordPressin valmisteemoilla toteutettujen sivustojen kanssa. Meillä Knowit Experiencella projektit ovat aina joka tapauksessa täysin asiakkaan tarpeeseen räätälöityjä sivustoja. 

Headlessina voidaan myös isomman sivuston kylkeen helposti rakentaa täysin omia sivustojaan, jotka noutavat tiedot olemassa olevan julkkarin rajapinnoista. Näin melko ketterästi voidaan toteuttaa yksittäisiä kevyitä sivustoja tarvitsematta vaivata päätään sillä, missä ja miten sisältö tuotetaan. 

Lähtökohtaisesti headless on aina varsin järkevä valinta. Ennemmin voi kysyä sitä, pitääkö se julkkari olla aina jokaisen sivuston taustalla?  

Väite 6. Headless-ratkaisut ovat sisällöntuottajien ja markkinointitiimien näkökulmasta hankalia käyttää, ja niissä ei ole hyvää preview-toimintoa sisällöntuottajille. 

Ratkaisevana tässä on, kuinka hyvin julkaisujärjestelmän integrointi on tehty headless-frontendin kanssa. Itse olemme yrittäneet panostaa siihen, että ylläpitokokemus on sisällön ylläpitäjälle yhtä hyvä kuin tavallisessa monoliittisessa sivustossa. WordPressin tapauksessa ylläpitäjät käyttävät edelleen Gutenberg-lohkoeditoria, esikatselevat sivuja ja muokkaavat valikkoja ja palvelun rakennetta kuten monoliittisessa sivustossa.  

Toteuttamissamme sivustoissa on otettu huomioon markkinoinnin tarpeet, esimerkiksi mahdollistamalla vapaasti taitettavat ja väritettävät laskeutumissivut. 

Joissakin tapauksissa muutosten näkyminen ja valuminen läpi julkaisuputken voi ottaa joitakin ylimääräisiä minuutteja. Monoliittisessakin toteutuksessa eritasoiset välimuistikerrokset aiheuttavat vastaavia haasteita. Kun projektissa tiedetään, että jokin sisältö pitää saada julkaistua välittömästi, voidaan tämä ottaa jo toteutustavassa huomioon. 

Headless myös mahdollistaa mallin, jossa julkkari voidaan unohtaa välistä ja sisällöntuotanto voidaan keskittää erilliseen sisällönhallintajärjestelmään. Teoriassa sivusto voi siis olla automaattisesti rakentuva algoritimi organisaation sisältöihin.  

Jos sisällöntuottajalla tai markkinointitiimillä on aikaa ja osaamista kokeilla itse ja koristella sivustoa erilaisilla lisäosilla, niin luonnollisesti headlessin vakioitu frontend voi tällaisessa tapauksessa olla liian rajoittava valinta. 

Väite 7. Headless on paljon riskialttiimpi valinta kuin monoliittinen CMS. 

Mihin tahansa monimutkaiseen projektiin liittyy riskejä siihen, että kompleksisuus tekee ohjelmistosta hallitsematonta spagettia. Tämä on mahdollista etenkin monoliittisessa projektissa, jossa vaikkapa sivupohjissa yritetään ratkoa sellaista asiaa, mikä olisi parempi käsitellä vaikkapa tarpeeseen luodussa, erillisessä lisäosassa. Ohjelmistoarkkitehtuurin suunnittelu ja siinä pysyminen vaatii kokemusta, dokumentointia ja kehitystiimin sisäisiä käytäntöjä. 

Headlessilla nämä riskit pienenevät, kun eri järjestelmille syntyy automaattisesti selkeät roolit. Frontendin rooli on näyttää loppukäyttäjälle sivuja, kun backend voi taas keskittyä vaikkapa sisällönhallintaan ja sen ominaisuuksiin. Monimutkaiset integraatiot voidaan rakentaa omiksi järjestelmikseen tai niiden sijasta voidaan käyttää yksinkertaisia pilvifunktioita. Eri järjestelmien kehittäjät juttelevat keskenään vakioitujen rajapintojen välityksellä. 

Headless-sivustonkin saa toki rakennettua väärin ja siitä voi tehdä varsinaisen matolaatikon. Nykyisellään tätä ongelmaa helpottaa hyvät ja dokumentoidut ohjelmointikehykset, kuten Next.js ja Gatsby. Näitä käyttämällä projekti rakentuu vakioiduilla tavalla ja hyödytään toisten ratkaisemista ongelmista. 

Väite 8. Headless on yhtä turvallinen kuin sen heikoin lenkki. 

Tietoturvasta puhuttaessa hyökkäyspinta-ala pienenee huomattavasti, kun koko frontend on käytännössä vain nippu staattisia sivuja. Mahdollinen liikenne taustajärjestelmiin tapahtuu reunalaskentana, käytännössä sisällönjakoverkosto suorittaa yksinkertaisia pilvifunktioita, joilla voidaan loppukäyttäjältä täysin piilottaa alla olevat järjestelmät.  

Näin julkkari ja muut sivuston mahdollisesti käyttämät taustajärjestelmät voidaan haudata tarpeeksi ison oven taakse, johon on pääsy vain auktorisoiduilla tahoilla. Tällä tavalla voidaan helposti vahvistaa tietoturvaa. Monoliittisessa WordPressissä frontendin ja ylläpidon rakenteellinen erottaminen toisistaan on lähes mahdoton tehtävä. 

Palvelittomassa mallissa, kaikki infrastruktuurin palikat ovat lähtökohtaisesti ajan tasalla. Riskit myös hajaantuvat eri palveluntuottajien ympäristöihin. Sen sijaan, että koko sivusto on pimeänä, voi jokin yksittäinen komponentti olla vain pois käytössä. Kun sivuston komponentteja tuottaa isot toimijat, joiden elinkeino on rakennettu niiden varaan, voidaan olla varmoja siitä, että tahtotilaa ongelman pikaiseen selvittämiseen löytyy. 

Onpa käynyt niinkin, että sivuston taustalla pyörivä WordPress on ollut saavuttamattomissa, mutta sivusto on edelleen toiminut täydellisesti.  

Väite 9. Headless aiheuttaa helposti toimittajaloukun asiakkaalle. 

Mikä tahansa täysin räätälöity toteutus on omiaan aiheuttamaan toimittajaloukun. Jos headless-toteutuksen tekee käyttäen vakiintuneita ohjelmointikehyksiä, käytäntöjä ja kieliä, ei loukosta ole sen enempää vaaraa kuin vaikkapa monoliittisen WordPressin kanssa. Jos toteutus on tehty huonosti ja budjettia ei refaktoroimiselle löydy, minkä tahansa palvelun siirto toiselle toimittajalle on kivuliasta. 

Kun headlessin tekemisessä kuitenkin puhutaan pitkälle Reactista, on osaajiakin nyt ja tulevaisuudessa aivan eri määrä kuin esimerkiksi WordPressin sielunelämää ymmärtäviä. Frontendin ja taustajärjestelmien välille syntyy luonnostaan yksiselitteinen rajapinta, mitä on helppo ulkopuolisen tulkita. Samaan julkkarin rajapintaan voi liittyä useampi toimija, ilman että kokonaisuutta tarvitsee siirtää täysin toiselle toimijalle. 

Onnistunut siirto vaatii toki myös kohtuullisen laadukasta dokumentointia ja ympäristöjen kuvausta. Tässäkin on hyvä, että toimittajalla on kykyä ja rutiinia tarvittavien asioiden automaattisesta dokumentoinnista. 

Usean eri järjestelmän kokonaisuutta voi olla järkevä hallita samassa versionhallinnassa, monorepossa. Näin kaikki muutokset ovat yhdessä paikassa, siirto helpottuu ja koko koneen rakenteen näkee helposti yhdellä silmäyksellä.  
 

Väite 10. Headless-ratkaisujen arkkitehtuuri on monimutkainen ja vaatii toteuttajalta paljon erilaisia kyvykkyyksiä. 

Tämä väite pitää täysin paikkaansa. Juuri tämän vuoksi minulla on työkavereita, jotka ovat panostaneet kyvykkyyksissään alueisiin, joista itse en ymmärrä kuin pintaraapaisun. Nykyaikaiset verkkosivustot vaativat paljon erityisosaamista. Itse mieluummin menen hoitamaan hampaitani hammaslääkäriin ja hiuksiani parturiin. En yritä ostaa niitä samalta henkilöltä, vaikka äkkiseltään tämä kuulostaisi näppärälle, kun kerran nyt  tuolissa istutaan. 

Tutustu headless-referensseihimme: eQ Haku, Technopolis, Lujatalo ja Alma Talent.

Lue tarkemmin Jamstack-arkkitehtuurista täältä. 
 
Kiinnostaako kuulla lisää headless-ratkaisuista? Täytä alla oleva lomake ja keskustellaan headless-ratkaisujen tarjoamista mahdollisuuksista organisaatiollesi.