HTML5 web-sovellukset

Viimeisen parin vuoden aikana HTML5-perheeseen kuuluvien teknologioiden – kuten CSS3, JavaScript, Canvas, Local storage ja Web sockets – kehitys on mahdollistanut täysin uudentyyppisten sovellusten tekemisen standardeja web-teknologioita käyttäen. Samaan aikaan selainten suorituskyky on noussut huimaa vauhtia, mikä on osaltaan vauhdittanut web-sovellusten suosiota parantuneen käyttökokemuksen myötä. Tämä kehitys huomioon ottaen onkin täysin ymmärrettävää että Rich Internet Application (RIA) -teknologioiden, kuten Adobe Flash, käyttö on vähentynyt uusien sovellusten osalta.

Web-sovellusten uudet teknologiat mahdollistavat muun muassa seuraavanlaisten ominaisuuksien lisäämisen:

  • Web-sovellus voidaan kehittää itsenäisenä sovelluksena, ilman tiukkaa integrointia palvelinpuolen teknologioihin
  • Videon ja äänen toistamisen
  • Interaktiivisten pelien toteuttamisen
  • Ilman verkkoyhteyttä toimivien sovelluksen toteuttamisen
  • Työpöytäsovelluksen kaltaiset käyttöliittymät
  • Geopaikannuksen
  • Reaaliaikaisen viestinnän

HTML5 on kokoelma jatkuvasti kehittyviä teknologioita, mutta tällä hetkellä yleisesti käytössä olevissa selaimissa on jo hyvä tuki keskeisille teknologioille.

Yhden sivun arkkitehtuuri

Web-sovellusten kehityksessä on tapahtunut myös suuria muutoksia myös muilla osin. Sovellusten arkkitehtuurina käytetään nykyisin yhä useammin niin kutsuttua yhden sivun mallia. Yhden sivun arkkitehtuuri tarkoittaa käytännössä sitä, että web-sovelluksen logiikka siirretään asiakasselaimen vastuulle. Esimerkkinä tällaisesta sovelluksena on esimerkiksi Googlen Gmail -sähköpostisovellus. Tässä mallissa selain voi kommunikoida web-palvelimen kanssa käyttäen pelkästään XMLHttpRequest (XHR) tai WebSockets -teknologioita. Tällöin selaimen tila säilyy pyyntöjen välissä, eikä selain lataa missään vaiheessa koko sivua uudestaan tyhjältä pöydältä, niin kuin perinteisessä asiakas-palvelin -mallissa on tapana.

Etuina yhden sivun sovelluksissa verrattuna perinteiseen malliin

  • Nopeus: selain ei lataa ja käsittele tarvittavia riippuvuuksia joka kerta kun käyttäjä navigoi sivustolla.
  • Tehokkuus: varsinainen sovelluspalvelin vapautuu palvelemaan vain varsinaisia datapyyntöjä, eli yleensä REST-rajapinnan kautta tapahtuvaa JSON-muotoista kommunikointia. Selainsovellus on oma kokonaisuutensa joka on helppo tarjota käyttäen Content Delivery Network (CDN) -palvelua kuten Amazon CloudFront:a.
  • Käyttäjäkokemus: sovellukset voivat helposti sisältää interaktiivista sisältöä, ja sivun sisällä navigointi ei aiheuta normaalia selaimen sisällön tyhjenemistä ja sitten uudelleen ilmestymistä navigoinnin välissä.
  • Don’t repeat yourself (DRY) -periaatteen noudattaminen: perinteisessä mallissa käyttöliittymä sovelluslogiikka hajautuu helposti ja yleensä välttämättömästi sekä selain- että palvelinpäähän. Tämä johtuu siitä että lähes aina sovellukseen halutaan lisätä jonkinasteista interaktiota JavaScriptia käyttäen, ja tällöin välttämättömät selainpohjaiset ratkaisut tulevat palvelinteknologioiden rinnalle.
  • Selkeys ja eat your own dog food -periaatteen noudattaminen: selainsovellus joutuu kommunikoimaan sovelluspalvelimen kanssa käyttäen määriteltyä rajapintaa. Oikein toteutettuna nämä julkiset rajapinnat tuovat sovellukseen selkeyttä, koska kyseinen rajapinta on ainut kommunikointikanava sovellukseen. Yleensä rajapinta toteutetaan RESTful-periaatteita käyttäen, jolloin rajapintaa voidaan helposti hyödyntää myös natiivisovellusten kanssa.
  • Turvallisuus: koska kaikki rajapinnan metodit on toteutettu yhdenmukaisesti, on rajapinnan metodien dokumentointi, testaus ja turvaaminen selkeää. Tämä edesauttaa ohjelmiston turvallisuuden todentamista.

Haittoina voidaan pitää seuraavia seikkoja

  • Selainyhteensopivuus: pieni osa käyttäjistä käyttää hyvinkin vanhoja selaimia, kuten Internet Explorer 6:tta. On olemassa paljon syitä miksi näin vanhoja selaimia ei pitäisi tukea enää, ja onneksi vain erittäin pieni osa käytetyistä selaimista lukeutuu sellaiseen kategoriaan joiden tukeminen on hyvin työlästä tai mahdotonta.  Loppuasiakkaan käyttökokemus jää kuitenkin vanhoilla selaimilla aina vajanaiseksi.  Selaimelta vaadittu nopeus ja ominaisuudet riippuvat paljon käytetystä sovelluskehyksestä.
  • Osaavan työvoiman puute: yhden sivun arkkitehtuuri ja siihen liittyvät sovelluskehykset ovat niin tuoreita asioita että vain osalla yrityksistä on ollut mahdollisuus toteuttaa oikeita asiakasprojekteja käyttäen tätä mallia. Yhden sivun arkkitehtuuri asettaa myös paljon vaatimuksia sovellukselle. Huono tekninen laatu aiheuttaa helposti sen, että sovelluksen käyttökokemus jää vajavaiseksi.
  • Vakiintumattomat ratkaisut: tällä hetkellä useat eri sovelluskehykset ja arkkitehtuurimallit sotivat keskenään, mallit ja parhaat käytännöt alkavat vasta nyt vakiintua. Lähes kaikki sovelluskehykset ovat avoimen lähdekoodin projekteja, joille ei yleensä ole tarjolla kaupallista tukea. Sovelluskehysten tekniset ratkaisut muuttuvat myös usein projektien edetessä. Tällöin myös varsinaiseen kehitettävään sovellukseen joudutaan ehkä tekemään yhteensopivuusmuutoksia.
backend-frontend(SPA)

Yksinkertaistettu malli yhden sivun arkkitehtuurilla toteutusta web-sovelluksesta

Sovelluskehykset

Yhden sivun arkkitehtuurin suosion yhtenä syynä on myös se, että tällaiseen kehitykseen suunnatut sovelluskehykset ovat pikkuhiljaa kypsyneet varteenotettavaksi vaihtoehdoiksi viimeisen parin vuoden aikana. Muun muassa yksi vanhimmista ja tunnetuimmista sovelluskehyksistä, Backbone.js julkaistiin jo lokakuussa 2010. Tämän jälkeen se ollut käytössä useissa isoissa sivustoilla kuten muun muassa SoundCloud, BitBucket ja AirBnB. Backbone.js:lle on aikojen saatossa julkaistu lukuisasti lisäosia, joiden avulla Backbone.js:n suhteellisen suppeaa perustoteutusta saa laajennettua huomattavasti. Ongelmaksi tällöin saattaa kuitenkin helposti tulla muodostuvan sovelluskehyksen hallinta ja yhteentoimivuus.

Backbone.js:n lisäksi markkinoilla on suuri määrä muitakin sovelluskehyksiä, joista varteenotettavimpia vaihtoehtoja ovat esimerkiksi AngularJS ja Ember.js. Tämän lisäksi kehitteillä on useita mielenkiintoisia projekteja kuten Meteor ja Derby, jotka eivät kuitenkaan vielä tässä vaiheessa ole valmiita vaativaan tuotantokäyttöön. Osa näistä sovelluskehyksistä vaatii sovelluksen toteuttamisen täysin kehyksen omien käytäntöjen mukaisesti, esimerkiksi Meteor tarjoaa myös palvelinpuolen sovelluksen teknologiat ja rakenteen joita on noudatettava. Joidenkin sovelluskehysten, kuten Backbone.js:n, käyttäminen osana olemassa olevaa selainsovellusta taas onnistuu ilman suurempia rajoitteita.

Testauksen helppous vaihtelee myös paljon eri sovelluskehysten kesken. Käyttöliittymätestaukseen liittyy sovelluskehyksestä riippumatta kuitenkin aina lukuisia haasteita. Manuaalisesta testauksesta ei kannata koskaan luopua täysin, mutta testauksen automatisointi on kuitenkin erittäin tärkeässä roolissa, koska web-sovelluksia käytetään lukuisilla eri selaimilla ja päätelaitteitteilla. Onneksi loppukäyttäjän toimintaa jäljittelevä end-to-end -testaus käyttäen esimerkiksi Seleniumia toimii yleensä kuitenkin sovelluskehyksestä tai arkkitehtuurista riippumatta.

Web-teknologiat kehittyvät erittäin nopeaa vauhtia ja tämän takia on tärkeää seurata alan tapahtumia ja suuntauksia. Käyttäen tätä tietoa on hyvä analysoida saatavilla olevia vaihtoehtoja ja suhteuttaa olemassa olevaa tarjontaa omiin tarpeisiin. Joka projektissa on aina erityyppisiä tarpeita, joten minkäänlaista silver bullet -tyyppistä ratkaisua ei tietysti koskaan ole tarjolla.

Kommentoi

Please log in using one of these methods to post your comment:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s

Seuraa

Get every new post delivered to your Inbox.

%d bloggers like this: