Headless soveltuu erityisesti suuriin, paljon liikennettä kerääviin ja monimutkaisiin palveluihin, joissa julkaisukanavia on useita.
Viime aikoina keskustelua on aiheuttanut verkkopalveluiden rakentaminen käyttämällä headless-toteutustapaa. Tämä tarkoittaa verkkopalvelun esityskerroksen (frontend) erottamista taustajärjestelmästä (backend), joka on esimerkiksi ContentfullinAvautuu uuteen välilehteen kaltainen CMS SaaS-palveluna, perinteinen CMS Drupalin tai Wordpressin tapaan tai yhdistelmä eri palveluita, joista sitten koostetaan ns. aggregation layerin kautta sisältö frontendin saataville.
Headless-konseptin suosioon on vaikuttanut moni asia, esimerkiksi Reactin ja JAMstackAvautuu uuteen välilehteen-mallin suosion kasvu, staattisten sivustojen helppo ja edullinen hosting AWS:n kaltaisissa pilvipalveluissa sekä tarve sisällön tarjoamisesta eri julkaisukanaviin. SaaS-palveluina tarjottavat Headless CMS:t istuvat erinomaisesti myös nopeasti yleistyviin serverless-arkkitehtuureihin.
Voi tämän nähdä osana 2000-luvun ns. batch-size reduction –trendiäkin: suositaan pienempiä ja erikoistuneempia komponentteja (microservices), joita viedään tuotantoon jatkuvasti (continuous delivery) lyhyissä kehityssykleissä (agile).
Kun joskus Scrumin alkuaikoina oli vallankumouksellista, että jokaisen neljän viikon sprintin jälkeen pystyttiin toimittamaan jotain käyttökelpoista, niin nykyään ihanteena on viedä uutta koodia tuotantoon monta kertaa päivässä. Monoliittinen sovellus, johon pienenkin muutoksen tekeminen tarkoittaa aina isoa deploymenttia ja jännittää vähän jokaista, istuu huonosti tällaiseen maailmaan.
Yritetäänkö headlessiä ja Reactia tyrkyttää, vaikka se ei olisikaan paras ratkaisu?
Olen yli kymmenen vuoden urani aikana ehkä kerran kuullut erään fronttidevaajan tunnustavan, että ihan oikeasti tykkää tehdä teemoitustyötä Drupaliin – mutta voi olla, että tämäkin oli vain unta. On siis varmaankin totta, että Reactia yritetään kaupata osittain siksikin, että sitä on kiva devaa – innokkaita tekijöitä on siis paljon saatavilla. Ja saahan Reactilla monia aikaisemmin vaikeita asioita tehtyä todella helposti. Mutta on täysin aiheellinen kysymys, että onko juuri sinun verkkopalvelussasi toimintoja, jotka vaativat Reactia, puhumattakaan pitäisikö sen olla täysin headless.
Toisaalta on tullut myös nähtyä, kuinka esimerkiksi Drupalia on haluttu väkisin käyttää, milloin “yhtenäisyyden”, milloin tuttuuden tai jonkun muun syyn takia. On tehty nopeasti 90 prosenttia toiminnoista ja sitten poltettu kaikki fyrkat (ja vähän yli) viimeisen 10 prosentin parissa kun ollaan taivutettu Drupalia vääriin asioihin. Lopulta halvemmaksi olisi tullut tehdä alusta lähtien täysin räätälöitynä sovelluksena halutut toiminnot.
Reactin kanssa on ollut havaittavissa pientä vauhtisokeutta, kun kokemattomilta tiimeiltä on voinut unohtua perusasioita liittyen esimerkiksi hakukoneoptimointiin, saavutettavuuteen tai lomakkeiden hallintaan. Reactista, analytiikasta ja hakukoneoptimoinnista kollegani Marko Tuliniemi kirjoittikin asiantuntevan kirjoituksen. Aikaisemmin tällaiset asiat tulivat lähes ilmaiseksi esimerkiksi Drupalin myötä. Itse kohdistaisinkin kritiikkini headlessin sijasta enemmänkin tarpeettomaan Reactin suosimiseen palveluissa, joissa ei ole mitään sovellusmaista.
Headless-konseptiin itsessään suhtaudun lähtökohtaisesti hyvinkin positiivisesti. Se soveltuu pieniin, generoituihin html-sivustoihin kuten blogi tai vaikkapa urheiluseuran sivustoihin, joiden ylläpitoon halutaan käyttää minimaalisesti aikaa ja rahaa. Näin vähäisissä tarpeissa toki myös Squarespacen kaltaiset palvelut ovat kilpailukykyisiä ja helpompia ratkaisuja. Erityisesti headless soveltuu suuriin, paljon liikennettä kerääviin ja monimutkaisiin palveluihin, joissa julkaisukanavia on useita.
Headless-toteutustavan edut ja rajoitteet
Ensinnäkin, headless mahdollistaa CMS:n ja esityskerroksen elämisen eri sykleissä. Tämä on suuri etu, sillä kun sisällön suhteen aletaan puhua sadoista tuhansista tai miljoonista sivuista, niin migraatiot toiseen järjestelmään ovat aina työläitä ja kalliita projekteja. Kuitenkin itse sisällön rakenteeseen tai sisällönhallintatyökaluihin liittyy huomattavasti harvemmin muutostarpeita kuin esityskerrokseen, jota voidaan haluta uudistaa vain muutaman vuoden väleinkin.
Toiseksi, suurissa palveluissa suorituskyvystä huolehtiminen on iso kuluerä mahdollisen migraation lisäksi. Kun on elämässään viettänyt pitkiä iltoja yrittäen pitää kuorman alla natisevaa Drupal-sivustoa pystyssä, niin en voi liikaa korostaa kuinka paljon paremmin nukun yöni, kun sivusto koostuu käytännössä kasasta javascript-tiedostoja S3:ssa Cloudfrontin takana. Jos taustajärjestelmät ovat vielä mallia serverless vaikkapa Lambda-funktioina toteutettuina, niin suurin osa suorituskykyongelmista on luonnostaan ratkaistu ja rahaa säästyy.
Rajoitteitakin headlesssissä luonnollisesti on, esimerkiksi esikatselun toteuttaminen tai monimutkaisten sivupohjien muokkaaminen käyttäjäystävällisesti. Lisäksi ainakin tällä hetkellä yhtään monimutkaisemmissa tapauksissa työaikaa kuluu helposti siihen, kun koko headless-julkaisuputkea viritellään kuntoon. Jos käytössä on staattisten sivujen generaattori (esim. Gatsby), niin isojen sisältömäärien käsitteleminen tuottaa äkkiä ongelmia.
Vähäisempiin tarpeisiin odotan syntyvän lisää valmiita palveluita, joissa sisällönhallinta ja sivuston julkaiseminen valittuun pilviympäristöön onnistuu lähes nappia painamalla.
Lopulta tässäkin palataan perinteiseen vastaukseen: tulee valita oikea toteutustapa ottaen huomioon toiminnan mittakaava ja kehitysbudjetti. Harvoin on myöskään syytä mennä täysin all-in johonkin malliin. Suuremmissa kokonaisuuksissa on suositeltavaa yhdistellä eri tapoja – esimerkiksi tekemällä harvoin päivittyvät asiakastukisivut staattisesti generoituna, ylläpitää blogit Wordpressissä ja toteuttaa monimutkaiset ostoputket Reactilla täysin Single Page Appina, joka keskustelee erillisten tilausjärjestelmien kanssa.
Teksti julkaistu ensimmäisen kerran Pauli Huhtiniemen henkilökohtaisessa blogissa 12.9.2019Avautuu uuteen välilehteen.