“Eiks se oo aina Apache?”

-“Siis mikä?!“

Express. nginx. Caddy. HTTP/2. IIS. Sertit. CRL. Portti 80. DNS?! localhost:3000

“No mut ku Railsissa on omansa, en mä tiedä miks jotain web-serveriä tarvis laittaa pydeen.”

Sormi suussa? Ällös huolehdi. Tutkitaan, ennenkuin hutkitaan.

Sovelluskehittäjä nykyaikana usein voi “unohtaa” armeliaasti alla olevan teknologian. Ne mallit ja kuviot, joilla webissä palveluja voidaan rakentaa, ovat itse asiassa tietyllä tapaa monimutkaistuneet. Tai sanotaan näin: on paljon tunnettuja vakioratkaisuja, mutta tarvittaessa alustan osaset voidaan rakentaa yhdistämällä eri teknologiatarjoajilta ostettuja palveluja.

Komponentit on revitty irti toisistaan, ja niitä voi vuokrata SaaS-mallilla, joten näiden palikoiden yhteiskäyttömahdollisuus luo suuremman määrän mahdollisia kombinaatioita (verrattuna siis aikaan, jolloin yritys itse vastasi täysin 100% kaikkien palvelimen raudan ja softan pyörittämisestä).

Pyyntö – vastaus (request/response)

Web-sovellusten kivijalka on edelleen hyvin sama kuin alkuaikoina:

• web-selain pyytää sivua palvelimelta
• palvelin vastaa dynaamisesti luodulla sivulla

Pyhä kolminaisuus: client – server – database

Edelliseen 2 toimijan malliin lisätään vielä yksi yksityiskohta palvelimen puolelta: tietokanta. Nyt on client – server – database. Serveri (palvelin) voi keskustella sisäisesti rauhassa tietokannan kanssa, kun sen tarvitsee. Tätä puolta ei välttämättä tarvitse lainkaan näyttää clientille. Eli palvelin näyttää vain julkisen rajapintansa: “täällä olen, kysy sivuja, minä vastaan”.

Selaimen päässä ajettavasta teknologiasta eli frontendistä vastaava kehittäjä tekee käyttäjälle näkyvän teknologian:

• sivujen ulkonäön
• teemat, värit, tyylit
• ikonit
• menujen rakenteen ja toiminnot

Moderni webin päällä käytettävä palvelu voi itse asiassa suurimman osan ajasta pyöriä itsenäisesti selaimessa, ilman kontaktia palvelimeen. Toisinaan tarvitaan päivitystä dataan, eli frontti lähettää kutsun palvelimelle (backendille), ja saa vastauksena tarvitsemansa datat.

Frontilla on kolme vaihtoehtoa, kun tarve muutokselle (“event”) tulee käyttäjältä:

• jos muutos voidaan tehdä paikallisesti, ei tarvita verkkokutsua backendiin
• jos käsittelyyn tarvitaan lisädataa, frontti lähettää kutsun backendille
• jos käsittely aiheuttaa muutoksen (“kirjoituksen”) dataan, tämä pitää myös viestiä backendille

Jos palvelu on hyvin yksinkertainen, eikä kovin paljoa selailua tapahdu käyttöliittymässä, jokainen sivu voidaan luoda serverillä tarvittaessa. Paljon komponentteja sisältävien palvelujen (esimerkkinä verkkokaupat ja Facebook) kohdalla tällainen alkaa rasittaa palvelinta kohtuuttomasti.

AJAX alkuaikoina

Ensiratkaisuna sivun päivityksen raskauteen oli AJAX. Asynchronous Javascript on suomenettu “asynkroninen kutsu”. Ideana AJAXissa on ladata vain se määrä dataa, kuin tarvitaan – ei koko sivua. AJAX eli valtakautensa menestyksekkäästi, eikä idea sinänsä ole mihinkään hävinnyt.

Lisänopeutusta: VDOM ja React

React:ssa (teknologiassa) tehtiin radikaali keksintö: DOM virtualisoitiin. React laskee datan muutoksen tekemät visuaaliset havaittavat piirteet valmiiksi nopeasti, ennenkuin varsinaisesti pyytää selainta piirtämään ruudun uudestaan. React kutsuu tätä VDOM -nimellä, virtual DOM.

Perinteinen DOM: kuin hätäilevä ja tehoton joulupukki!

Vertauskuvallisesti voisi ajatella, että DOM on kuin hajamielinen Joulupukki:

• heti kun ensimmäinen lahjapyyntö saapuu joulukuun alkupuolella, Joulupukki lähtee jo liikkeelle!
• lisäpyyntöjen saapuessa tontut lähtevät pikaisesti toimittamaan näitä Joulupukille, joka joutuu palaamaan takaisin Pajalle hakemaan lahjat
• hanki on täynnä ristiin rastiin meneviä latuja, ja Joulupukki on melkein kupsahtaa puuskutuksestaan..

Selaimessa tämä “edestakainen Joulukin reen matkustelu” näkyy siis oikeasti räpsyvänä ruudunpäivityksenä. Tätä itse asiassa tapahtui mm. Facebookissa, ennenkuin Facebook alkoi panostaa teknologiaan, jolla saatiin sopiva-aikaisesti päivityksiä tietokannasta, kun käyttäjälle tuli vaikkapa uusi tilapäivitys kaverilta. Syntyi ReactJS.

React ja virtuaalinen selaimen sisältö, VDOM on kuin fiksu Joulupukki, joka ensin pakkaa reen täyteen kaikkien lahjatoiveiden suhteen, ja vasta sitten lähtee tehokkaalle toimitusreissulle täydellä reellä.

Web-serverien rooli sovelluksissa

Kuinka paljon sovelluskehittäjän kannattaa miettiä koko stackkia?

Ohjelmoijaa helpottaa usein, jos voi joko:

• vetää rajaviivan oman vastuualueen ja “alustan” välille, tai
• käyttää tunnettuja ratkaisuja, joiden tiedetään olevan tehokkaita ja ongelmattomia

Aina näin ei voi tehdä. Cutting edge – tiedämme kaikki sen tunteen: surffataan projektissa teknologian kirkkaimman kärjen ytimessä, matkalla kohti suurta ja tuntematonta, samaan aikaan hieman vauhtisokeina, uudesta viehtyneinä, ja adrenaalinia kofeiinin lisäksi suonistossa. Rantaviiva on hieman kuohuva; käydään puolin ja toisin vierahissa.

Millainen on ollut mieleenpainuvin cutting edge rantaviivasi? Pistä kommenttia tänne! Kiitti!