Headless-arkkitehtuuri on eräänlainen hajautettu toteutustapa, jossa web-sovelluksen tai sivuston käyttämä tieto voidaan noutaa palasina verkon yli ja näyttää käyttäjälle kulloiseenkin tilanteeseen parhaiten sopivalla tavalla. Tyypillisesti sovelluksia ja ohjelmistoja on kehitetty toimimaan monoliittisesti eli noudattamaan arkkitehtuuria, jossa tietokanta ja sovellus toimivat yhdessä toisiinsa tiukasti koodattuina. Headless-arkkitehtuurissa näin ei ole, vaan tietokantoja voi olla useita ja niitä voidaan käyttää eri rajapintojen kautta. Loppukäyttäjän sovellus voi olla toteutettu useille eri alustoille ja sovellusten sisältö voi olla tilanteeseen paremmin räätälöity. Headless-arkkitehtuuri toimii täysin eri tavalla kuin perinteisempi monoliittinen arkkitehtuuri, minkä vuoksi se on noussut suosioon nykyisten mikropalveluiden aikakaudella.
Headless-arkkitehtuuri ja JAMStack
Headless-arkkitehtuurin suosio perustuu sen joustavuuteen ja skaalautuvuuteen. Koska käyttöliittymä (frontend) ja palvelinpuoli (backend) on erotettu toisistaan, kehittäjät voivat työstää kumpaakin osa-aluetta itsenäisesti. Muutamia hyötyjä:
-
Headless-ratkaisu tarjoaa hyvät mahdolliset työkalut sekä frontend- että backend-kehitykseen. Esimerkiksi tällä sivustolla käytetty Next-js voisi olla sopiva valinta käyttöliittymään. Backend voi toimia vaikkapa Pythonin päällä. Tällä sisvustolla on käytetty Node.js -pohjaista directusta.
-
Headless-arkkitehtuuri mahdollistaa saman sisällön käyttämisen monissa eri kanavissa, esim. verkkosivustoilla ja mobiilisovelluksissa tai vaikka isossa TV-ruudussa. Varsinaista sisältöä ei tarvitse koodata uudelleen jokaista alustaa varten, koska kaikki tieto kulkee samojen rajapintojen kautta.
-
Headless-arkkitehtuuri vähentää toimittajalukon (vendor lock-in) riskiä, koska käyttöliittymä ei ole sidottu suoraan taustajärjestelmän rakenteisiin tai rajoituksiin.
JAMStack liittyy läheisesti headless-arkkitehtuuriin, sillä molemmat korostavat eriytettyä toteutusta ja käyttävät rajapintoja tiedon hakemiseen ja näyttämiseen. Se on moderni verkkosovellusarkkitehtuurin lähestymistapa, joka perustuu JavaScriptiin (J), uudelleenkäytettäviin rajapintoihin (API) (A) ja valmiiksi renderöityihin merkintätiedostoihin (Markup) (M). Sen pääajatuksena on siirtää mahdollisimman suuri osa verkkosivun tai sovelluksen sisällöstä ja toiminnoista staattisiin tiedostoihin, jotka pystytään toimittaa käyttäjälle mahdollisimman pienellä viiveellä.
Keskeiset JAMStackin ominaisuudet ovat:
- Esiladattu sisältö: Staattisesti generoitu sisältö, joka pystytään lataamaan käyttäjälle hyvin pienellä viiveellä.
- API-pohjainen toiminnallisuus: Backend-toiminnot ja tietolähteet saavutetaan API-kutsujen avulla.
- Javascript-pohjainen logiikka: Dynaamiset ominaisuudet toteutetaan selaimessa JavaScriptin avulla.
Headless-ratkaisu tällä sivustolla
Kuten aiemmassa postauksessani jo vähän teknologioista vihjasinkin, tämä sivusto on rakennettu valmiin data-alustan päälle ja käyttöliittymäpuoli on kehitetty modernilla web-ohjelmointikehyksellä. Palvelinpuolella toimii siis avoimen lähdekoodin data-alusta, Directus (www.directus.io). Selainpuolella turvaudutaan moderniin Next.js-kehykseen, joka tarjoaa työkalut niin staattisen kuin dynaamisenkin sisällön näyttämiseen. Näiden kahden teknologian lisäksi sivusto perustuu vahvasti Docker-moottoriin. Molemmat edellä mainitut ratkaisut on työstetty Docker-konttien sisään.
Directus tarjoaa headless CMS -työkalut
Sen enempää mainostamatta, minusta Directus on aivan mainio data-alusta sisällön hallintaan. Se on hyvin laajasti kustomoitavissa, ja kustomointi onnistuu pitkälti ilman ohjelmointia. Alustan pystyttämisenkin voi ulkoistaa (rahalla), sillä Directuksen porukka tarjoaa maksullista pilvipalvelua asiakkaittensa käyttöön.
Ehdottomasti kätevintä Directuksen käytössä on ollut automaattisesti rakentuva API. Rajapinta rakentuu samalla, kun Directuksen käyttöliittymässä luodaan tietorakennetta datan tallennusta varten. Rajapinnan käyttöoikeuksia on mahdollista muokata erillisessä käyttöliittymässä, ja tällä varmistetaan tiedon turvallinen säilyttäminen. API siis rakentuu alustalle valmiiksi web-sivuston tai sovelluksen käytettäväksi.
Next.js helpottaa käyttöliittymäkikkailua
Kun rajapinta on valmis, sen tarjoamalle datalle täytyy luonnollisesti tehdä jotain; sellaisenaan sitä ei voi näyttää selaimessa. Tälle sivustolle luotiin Next.js-kehyksen avulla komponentteja, joilla visualisoidaan vaikkapa hero-näkymät sisältöineen tai näytetään esim. julkaistut blogitekstit ruudukkonäkymässä omalla sivullaan. Next.js tarjoaa myös rutkasti jykeviä työkaluja sivuston datan prosessointiin. Se mahdollistaa sivujen generoimisen staattisiksi web-sivuiksi tai niiden renderöimisen palvelinpuolella aina pyydettäessä. Näitä tekniikoita yhdistämällä pystytään luomaan nopea, dynaaminen ja monipuolinen web-sivusto tai -sovellus. Alla on esimerkki sivustolla käytetystä komponentista.
interface IData {
title: string;
headline: string;
className?: string;
font?: any;
}
export default async function Divider({ title, headline, className, font }: IData ) {
return (
<div>
<div className={`max-w-2xl text-orange-900 mx-auto mt-8 mb-2 flex items-center gap-4 before:h-px before:flex-1 before:bg-gray-300 before:content-[''] after:h-px after:flex-1 after:bg-gray-300 after:content-[''] dark:text-orange-300 ${className} ${font.className}`}>{title}</div>
<div className={`max-w-2xl mx-auto text-center text-3xl mb-8 lg:text-5xl lg:max-w-3xl ${className}`} dangerouslySetInnerHTML={{__html: headline}} ></div>
</div>
);
};Docker sulkee sivuston sisuksiinsa!
Directus on oikeastaan helpointa ajaa kontissa; Directuksen tiimi tarjoaa hyvän dokumentaation siitä, miten homma saadaan hoidettua ja kontti käyntiin. Suoraan lähdekoodista ajaminenkin varmaan onnistuisi, mutta vaatisi todennäköisesti huomattavasti enemmän perehtymistä. Next.js-käyttöliittymä puolestaan tarvitsisi Node.js-ympäristön ja erillisen prosessinhallintatyökalun kunnollisen toiminnan varmistamiseen. Nämä voi joko asentaa suoraan palvelimelle tai sulkea samaan konttiin. Itse sulloin ne konttiin mm. sillä verukkeella, että joskus saattaisin siirtää sivustoni jollekin toiselle palvelimelle. Siirto voisi siinä tilanteessa onnistua helpommin konttien avulla.
Muutenkin kontit tuovat toimintavarmuutta. Docker Swarm huolehtii siitä, että kontit pysyvät koko ajan käynnissä. Lisäksi sen avulla sai tehtyä konttiryppään, johon kuuluu Directus-kontti ja Next.js-kontti sekä näille yhteinen verkko.
Tulevaisuudessa enemmän irti Dockerista
Tulevaisuudessa yritän päästä hyödyntämään Dockeria paremmin. Esimerkiksi selkeä parannus voisi olla sivuston kehittämisen työnkulun päivittäminen. Versionhallinnan voisi automatisoida CI/CD-tyyliin siten, että jokaisen koodipäivityksen jälkeen saisi pukattua uuden Docker-levykuvan sivustosta, ja kuvan avulla saisi tehokkaammin päivitetyn kontin palvelimelle pyörimään. Voisi vielä miettiä, kannattaisiko myös Nginx-palvelin lyödä konttiin; nyt se pyörii suoraan VPS-palvelun sisällä sellaisenaan. Toistaiseksi se on ollut ihan hyvä asia, koska esim. pienet säädöt onnistuvat hieman nopeammin. Sitten kun sopiva konfiguraatio löytyy, palvelimen voisi lyödä konttiin ja näin kontissa oleva Nginx parantaisi sivuston siirrettävyyttä entisestään.