Yhden HTML-sivun varaan rakennetut SPA-arkkitehtuurin (single-page application) web-sovellukset ovat tällä hetkellä web-kehityksen kuumin trendi responsiivisen suunnittelun ohella. SPA-sovelluksissa itsessään ei sinällään ole mitään uutta, ja sellaisia onkin rakennettu jo aina AJAX-pohjaisen tiedonsiirron läpimurrosta asti. Aiemmin tällaisten sovellusten kehittäminen oli kuitenkin suurten ja monimutkaisten sovellusten tapauksessa työlästä ja kallista, ja lopputuloksena oli usein läjä vaikeasti ylläpidettävää spagettikoodia. Nyt aika on kuitenkin kypsä SPA-sovellusten tuottavaan kehitykseen viime vuosien aikana merkittävästi parantuneen työkalutuen myötä.
Hyödyt ja haasteet
Miksi sitten SPA-arkkitehtuurin pohjalle rakennettu web-sovellus on perinteisiä, usean eri HTML-sivun varaan tehtyjä sovelluksia parempi? Ilmeisin syy on parantunut käyttökokemus turhien sivulatausten hävitessä, jolloin sovelluksen käytön aikana ei tule tilanteita missä selain näyttää tyhjää sivua sivulatauksen ollessa kesken. Näin käyttökokemuksesta saadaan paljon interaktiivisempi ja sivustosta kokonaisuutena käytettävämpi. Lisäksi SPA-sovellukset lataavat kerralla pienemmän määrän tietoa kuin usean sivun pohjalle rakennetut sovellukset, jolloin siirtymät eri näkymien välillä ovat kevyitä kun ainoastaan uudelle näkymälle välttämätön tieto tarvitsee siirtää verkon yli, mikä käytännössä näkyy käyttäjälle nopeina sivulatauksina.
SPA-sovellukset myös ohjaavat sovellusarkkitehtuurin kehittämistä enemmän API-lähtöiseen suuntaan selaimen ja palvelimen välisen REST-rajapinnan myötä, mikä mahdollistaa helposti myös muiden samaa REST-rajapintaa käyttävien sovellusten kehittämisen. REST voi toki olla perinteisemmänkin, useasta eri sivusta koostuvan web-sovelluksen pohjalla, mutta SPA-sovellusten kehittämisessä REST-rajapinnan huolellinen suunnittelu korostuu, koska käytännössä kaiken sovelluksen kannalta keskeisen siirrettävän tiedon pitäisi olla saatavilla sen kautta.
Yksi SPA-arkkitehtuurin keskeisiä etuja on myös skaalautuvuus. Koska SPA-sovelluksessa kaikki käyttöliittymän tila on tallessa selaimessa, palvelimelle tallennettavan sessiotiedon määrä on minimaalinen, mikä mahdollistaa suuren määrän rinnakkaisia sessioita vaatimattomallakin palvelininfrastruktuurilla.
SPA-arkkitehtuurin toteuttamiseen liittyy kuitenkin omat haasteensa. Esimerkiksi sivuhistorian hallinta, saavutettavuus, hakukoneoptimointi ja sivun avaaminen uudessa välilehdessä tai ikkunassa vaativat enemmän suunnittelua kuin perinteisissä sovelluksissa. Myös muistinhallinta selainpäässä on asia johon SPA-sovellusten toteutusvaiheessa on syytä kiinnittää erityistä huomiota. Käyttöliittymäsuunnittelun näkökulmasta taas korostuneessa roolissa on interaktioiden suunnittelu, kun sivusiirtymien esittäminen käyttäjälle on täysin sovelluksen hallinnassa. Kaikki näistä haasteista ovat kuitenkin ratkaistavissa, mutta on tärkeää että ne huomioidaan jo sovelluksen ja sen arkkitehtuurin suunnitteluvaiheessa.
Katsaus teknologiakentälle
SPA-sovellusten haasteita ratkaisemaan on viime vuosina kehitetty monia apuvälineitä, joiden avulla SPA-sovellusten rakentaminen on helpottunut huomattavasti verrattuna muutaman vuoden takaiseen tilanteeseen. Keskeinen kulmakivi SPA-sovelluksessa on selainpäässä käytettävä JavaScript MVC-kehys, jonka varaan selainpään sovellusarkkitehtuuri on järkevää rakentaa. MVC-kehyksen avulla sovelluksen rakenne selkeytyy ja tarve kirjoittaa suuria määriä koodia DOMin käsittelyyn pienenee, mikä tosin riippuu paljon kehyksen tarjoamista ominaisuuksista ja abstraktiotasosta. Sopivan MVC-kehyksen käyttäminen voi parhaimmillaan parantaakin tuottavuutta merkittävästi.
Tämän artikkelin kirjoitushetkellä on selkeästi erotettavissa kolme vahvaa kehystä ja niiden ympärille muodostunutta yhteisöä, jotka ovat saaneet suurta suosiota web-kehittäjien keskuudessa: Backbone.js, AngularJS ja Ember.js. Näistä Backbone on ominaisuuksiltaan yksinkertaisin, ja tarjoaa vain välttämättömimmät rakennuspalikat selainpään arkkitehtuurin rakentamiseen. Tämän takia se on hyvä valinta sellaisten sovellusten rakentamiseen joiden arkkitehtuuri halutaan pitää tiukasti omassa hallinnassa ilman suuria kehyksen asettamia rajoitteita. Backbone ei kuitenkaan sellaisenaan ole paras mahdollinen valinta mikäli tällaista kustomoitavuustarvetta ei ole, ja sen päälle kannattaakin valita jokin Backbonea laajentava kehys, joka tarjoaa valmiina usein käytettäviä rakenteita joita Backbone ei suoraan tue. Esim. Marionette.js sopii hyvin tällaiseksi Backbonen päälle valittavaksi laajennokseksi. Vaikka Backbonen 1.0-versio ilmestyi vasta kuluvan vuoden maaliskuussa, on sitä käytetty jo pitkään monilla merkittävillä web-sivustoilla, ja sen ympärille onkin ehtinyt muodostua todella vahva yhteisö.
AngularJS sen sijaan tarjoaa paljon laajemman pohjan sovellusten rakentamiseen kuin Backbone, ja on siten tuottavuuden suhteen erinomainen valinta. Angular on Googlen kehittämänä kehyksenä saanut nopeasti ympärilleen jatkuvasti kasvavan yhteisön, ja on kaikista tarjolla olevista kehyksistä varmasti yhteensopivin tulevaisuuden selainstandardien ja niiden mahdollistamien ominaisuuksien kanssa. Esimerkiksi mallimuutosten kuunteleminen ja HTML-merkinnän laajentaminen omilla komponenteilla ovat tällaisia ominaisuuksia jotka löytyvät tulevaisuuden selaimista, ja joita voi jo nytkin jossain määrin kokeilla Chrome Canarylla. Tämä on ehkä suurin syy valita Angular, koska se tavallaan toimii siltana nykyisten ja tulevaisuuden selainten ominaisuuksien välillä. Lisäksi Angularin suunnittelussa on annettu erityishuomiota testattavuudelle selainpäässä harvoin nähdyn riippuvuuksien injektoinnin kautta.
Ember.js ei vielä kirjoitushetkellä ollut saavuttanut 1.0-versiojulkaisun merkkipaalua, mutta kovin kaukana se ei kuitenkaan enää ole (release candidate 4 ilmestyi kirjoitushetken aikoihin, ja se on Emberin kehitystiimin mukaan jo hyvin lähellä lopullista 1.0-versiota). Emberin ehkä suurimpana vahvuutena, ja samalla heikkoutena, on pitkälle viety automaattinen objektien luominen ja alustaminen nimeämiskäytäntöjen kautta, mikä mahdollistaa parhaimmillaan erittäin korkean tuottavuuden, mutta samalla asettaa kehittäjälle enemmän rajoitteita kuin muut vastaavat kehykset. Tämän takia Emberiä ei voikaan käyttää järkevästi vain osana kehitettävää selainpään toteutusta, vaan se käytännössä määrää koko selainpään arkkitehtuurin itse. Lisäksi Ember ei vielä kirjoitushetkellä ole niin kypsä kuin esimerkiksi Angular tai Backbone, mikä käytännössä näkyy Emberin APIn epävakautena. Esimerkiksi juuri ilmestyneessä RC4:ssä on potentiaalinen taaksepäin yhteensopimaton muutos. Tämä APIn kypsymättömyys on kuitenkin ohimenevä haitta ja korjaantunee 1.0-julkaisun myötä.
Näiden suurten kehysten lisäksi on olemassa monia muitakin vaihtoehtoja, eikä työkalutuen puute enää olekaan este SPA-sovellusten rakentamiselle. Lähitulevaisuudessa eräs varteenotettava vaihtoehto voi olla myös futuristinen, vielä kehityksessä oleva kehys Meteor, joka tarjoaa aivan uudenlaisen tavan rakentaa reaktiivisia SPA-sovelluksia pitämällä näkymässä esitettävän mallitiedon synkronoituna palvelimen ja kaikkien selainistuntojen välillä ja mahdollistamalla kaiken API-koodin suorittamisen sekä selain- että palvelinpäässä. Meteor mahdollistaakin monimutkaisten sovellusten rakentamisen verrattain pienellä ohjelmakoodin määrällä, ja tämä tuottavuuden nousun trendi on varmasti keskeinen tekijä jatkossakin uusien SPA-kehysten tullessa saataville.
Yhden sivun varaan pohjautuvat web-sovellukset ovatkin varmasti tulevaisuuden tavallisin malli web-sovellusten rakentamiselle, ja nykypäivänäkin monen web-sovelluksen pohjalle valitaan SPA-arkkitehtuuri, jollei koko sivuston laajuisesti, niin ainakin osalle kehitettävää sivustoa. Javascript MVC-kehysten tarjoamat tuottavuusedut ovat merkittävä syy SPA-sovellusten yleistymiselle, ja lisäksi SPA-sovellusten yleiset edut painavat vaakakuppia SPA-sovellusten puolelle monen uuden web-sovelluksen arkkitehtuurin valinnassa.
