Keskustelu: Yleinen keskustelu: Json ja Ajax: hyödyt ja haitat

Haluisin saada vähän näkökulmia asiaan eli mitä mahdollisia haittoja on liittää backend frontendiin käyttämällä jsonia ja ajaxia verrattuna esim. siihen, että tulostetaan palvelinpään koodissa html-tagit ja haluttu data mukaan.

Tietenkin yksi selvä haittapuoli on se, että ajaxia käyttämällä tullaan riippuvaisiksi javascriptiin, mutta mitään muuta haittapuolta en keksi. Käyttämällä jsonia tai vaihtoehtoisesti xml:llää päästään mielestäni aika kivasti fasaadikerroksen ja sovelluslogiikan toisistaan erottamiseen.

Näkyvyys hakukoneissa kannattaa huolehtia, mikäli tieto on sellaista, että sen tarvitsee siellä näkyä. Muutoinhan JavaScript on suht erinomainen keino estää hakukonetta pääsemästä sellaisiin toimintoihin käsiksi, joihin sillä ei ole asiaa (esim. kirjautumis- ja rekisteröitymissivut).

Tietoon linkittämisestä pitää myös pitää tarkasti huolta. On tosi veemäistä, jos tahdot linkittää johonkin tiettyyn juttuun ja sitten osoite pysyy kokoajan samana ja linkistä ei sitten ole mitään hyötyä.

Miksi aloitus yleiseen keskusteluun?

Ajattelin tätä asiaa itse backend-näkökulmasta, jolloin ajattelin, että en halua tehdä tästä teknologiariippuvaista keskustelua. Tosin javascript ja ajax toki tässä pysyy vakiona kokoaika, eli sinänsä tämän voi siirtää myös "Nettisivut ja ohjelmointi"-osioon.

En nyt sanoisi, että Javascript-riippuvaisuus olisi huono. Jos jollain on vielä selain, jossa ei Javascript toimi tai on ottanut sen pois päältä, niin sillon on kyllä käyttäjän ongelma. Voisihan sitä miettiä, että miten ne sivut toimivat jos käyttäjällä ei ole nettiyhteyttä.

Erityisesti Ajax helposti rajaa touhun suoraan selaimeen, joten ehkä osuvampaa voisi olla nostaa esiin keskustelua RESTimäisestä APIen teosta? APIt kun voi toteuttaa palvelimelta palvelimelle ja tällöin tieto voi kulkea mm. JSONina, vaikka JavaScript ei missään vaiheessa käpistelisikään sitä. Toisaalta sama tieto voidaan jatkokäsiteltynä toimittaa myös selaimelle asti.

RESTissähän taas käytetään HTTP:n GET/POST/PUT/DELETE jne. järkevällä tavalla resurssipohjaisesti. APIen teossa on jossain määrin ihanteellista noudattaa RESTiä, koska se yksinkertaistaa asioita ja varmistaa osaltaan sitä, että API toteuttaa sen osan kuin sen tulisikin, eikä siten paisu kuin pullataikina vaikeasti hallittavaksi möhkäleeksi.

Minusta mikä tahansa selainta kohdealustana käsittelevä keskustelu kuuluu nettiohjelmoinnin piiriin.

Näin yleisesti puhuttaessa haittapuolina tulee mieleen isompi "alkulataus" clientille sekä clientin kovempi kuormitus.

Nämä varsinkin kun puhutaan SPA-tyylisistä sovelluksista (esim. Knockout+Sammy tjms.) missä statea säilytetään koko ajan clientillä ja päivitetään tarvittaessa serverille.

Plussapuolia sitten löytyykin sen verran iso liuta, joten varsinkin jos "webbisivu" on sellainen mikä tällaisesta lähestymistavasta hyötyy, niin ehdottomasti tällaiselta modernilta pohjalta go.

Sinänsähän on hassua, että nyt kun serverit on tehokkaita ja sivunlataukset saa inhimilliseen nopeuteen isommallakin serverin suorittamalla koodilla ja nykyisillä kuluttajan nettinopeuksilla, ajaxin käyttö on kasvanut todella paljon. Kai siitä on tullut myös leiskallinen juttu sen sijaan, että saataisiin sivun pohja näkymään end userilla mahdollisimman nopeasti.

Moni nykykäyttötarkoituksista myös on mielestäni todella ärsyttävä,kuten mm. sivun sisällön dynaaminen lataus alaspäin scrollatessa.

En oikein ymmärrä pointtia tuosta että serverit on tehokkaita. Toki joo voi olla että nykyään saa toteutettua 500 serverillä sen mihin ennen tarvitsi 5000, mutta eikö se silti ole kätevämpää jos tarvitaankin vain 200 eikä 500 ?

No jos pointti ei tosta rivien välistä auennut niin: servereiden tehot on kyllä kasvaneet, mutta niin on myös käyttäjämäärät.

Ja aika paljon tulee tuota käytettyä niin, että kohtuullisen monimutkainenkin käyttöliittymä pyörii kokonaan selaimen päässä ja serveri sitten lähinnä tarjoaa API:n, jotka se selaimella pyörivä sovellus sitten käyttää.

Ei se serverien määrä pelkästään, vaan myös yksittäinen laskentateho. Load Balancella saadaan kävijät toki hajautettua eri servuille kuten aina ennenkin sivunlatauksen nopeuttamiseksi, mutta kyllä se kama sieltä DB pannulta nopeammin palautuu nykyisillä myllyillä kuin aiemmilla. jos nyt ajatellaan vaikka tavallista pk-sektorille tehtyjä nettisivuja. Ei ne kävijämäärät päätä huimaa jossain pikkufirman yrityksen nettisivuilla. Kuten ei aiemminkaan. Kävijämäärät eivät ole ylipäätänsä suuria missään keskivertofirman julkisilla verkkosivuilla, jos vertaa vaikka keskikokoisen firman intraan. Eriasia on firmat, jotka tarjoavat kuluttajille enemmän palveluja, kuten verkkokaupat jne. Koneistuskeskus mäkisen verkkosivut tuskin saavat vastaavanlaista kävijäryntäystä ale -päivinään. Jopa isojen konsernien julkiset verkkosivut voivat olla kävijämääriltään yllättävän pieniä. Jos yritys/konserni tarjoaa palvelujaan vain toisille yrityksille, ja verkkosivut eivät sisällä palveluja muuta kuin lähinnä staattisten verkkosivujen ja uutisten muodossa, on kävijöitäkään turha helliä isoilla palvelinsaleilla.

Itsekin toteutan vastaavanlaista mallia kuin sinä, kun mahdollista. Siltikin, leiskaajat pitävät tämän päivän trendinä ajaxilla ladattua kamaa osana leiskaa, vaikka kaman voisi hakea sivun latauksessakin (Kai ne tykkää lataus giffeistä ja siitä, että se antaisi jotenkin pro:maisemman vaikutelman, ihankuin nettisivujen tekeminen async -omaisesti olisi jotenkin vaikeampaa).

Esimerkkinä kaikki pienehkö sisältö, jota ei ole tarkoitus päivittää kuin sivun latauksen yhteydessä. (vaikka lohko joka sisältää teaserit uusimmista uutisista).

groovyb kirjoitti:

Itsekin toteutan vastaavanlaista mallia kuin sinä, kun mahdollista. Siltikin, leiskaajat pitävät tämän päivän trendinä ajaxilla ladattua kamaa osana leiskaa, vaikka kaman voisi hakea sivun latauksessakin.

Leiskaajako sen sanelee, miten nettisivut pitää tehdä teknisessä mielessä? Jos sivulle on piiretty throbberi, niin sen on pakko näkyä myös valmiilla sivustolla jossain kohtaa? Mun reaktio leiskaajien tyhmiin päähänpinttymiin olisi "mitä vittua" eikä "ok...".

Suomi24 on mielestäni aika hyvä esimerkki siitä, miten asiat pitää tehdä oikein. Siellä haetaan kaikki mahdollinen ajaxilla, mutta hyvin usein käy niin, että jostain sisäisestä cachesta tarjoiltu sivu linkkaa vanhentuneeseen, niin ikään cachetettuun js-filuun, joten kun skripti ei lataudu niin tuloksena on tyhjä leiska täynnä pieniä throbber-giffejä.

Alchemist, riippuu vähän siitä paljonko asiakas sanelee toimintamalleja, ja tuleeko leiska sieltä. Ei sinne paljon vittuja huudella, jos meinaa palkkansa tältä alalta saada. Ja mitä väliä, enemmän rahaa siitä tulee, mitä enemmän javascriptiä sivuille lyödään. Ei kai siitä valittamaan aleta. Se, onko se järkevää, on eri asia. Toki on myös asioita, joissa asiakasta tulee ohjata oikeaan suuntaan.

Olen muuttanut ns. vanhan toteutuksen, jossa asiakkaalla tulee 10 tuhatta riviä tietoa selaimeen perinteisellä server-jsp post kutsulla ja sitten niin, että sama tehdään ajax:lla ja toimitetaan json-rakenne, joka javascriptissä parsitaan auki jsp-sivulle. Jälkimmäinen on about 10x nopeampi. Nopeus tietenkin riippuu client-pään suoritustehosta jonkin verran. Lisäksi sivua ei tarvitse ladata uudestaan, vaan sisällön muuttaminen dynaamisesti perinteiseen uudelleen lataamiseen nähden on nykypäivää.

Cachetetun js-file ongelman pystyy kiertämään tekemällä ladattuihin .js tiedostoihin uniikin päätteen, joka muuttuu aina version päivittyessä, jolloin cache-systeemi lataa sen aina automaattisesti. Tästä löytyy netistä hyvät kuvaukset, miten se tehdään (includen perään lisätään tietyt asiat).