Serverless-API:n yleisin rakennevirhe on siirtaa olemassa oleva palvelinsovellus sellaisenaan yhteen funktioon. Se toimii, ja se maksaa enemman kuin pitaisi.
Ongelma
Monoliittinen funktio, joka reitittaa kymmenta polkua, lataa kaikkien polkujen riippuvuudet jokaisella kutsulla.
Jos yksi harvoin kaytetty reitti tarvitsee raskaan kirjaston — PDF-generointi, kuvankasittely, raportointi — se ladataan myos silloin kun kutsutaan kevyta hakureittia.
Koska laskutus perustuu suoritusaikaan, tama nakyy suoraan kustannuksessa. Ja koska kylmakaynnistys sisaltaa saman latauksen, se nakyy myos viiveessa.
Miksi tama ei ole ongelma palvelimella
Pitkaikainen palvelinprosessi lataa riippuvuudet kerran kaynnistyksessa ja palvelee sen jalkeen tuhansia pyyntoja. Alustuskustannus jakautuu koko elinkaarelle.
Lambdalla malli on toinen: jokainen kylmakaynnistys maksaa alustuskustannuksen uudelleen.
Tama on sama syy, jonka vuoksi kevyt natiivi kasittelija tai Honon kaltainen kehys on uusissa API-toteutuksissa nopeampi ja halvempi kuin Expressin kaltainen raskaampi kehys — Express on suunniteltu pitkaikaiselle prosessille.
Kaytannon periaatteet
Erottele funktiot vastuun mukaan. Yksi funktio per resurssi tai per selkeasti rajattu toiminto. Raskaat toiminnot omiin funktioihinsa.
Alusta yhteydet moduulitasolla, ala kasittelijassa. Lampimana pysyva ajoymparisto sailyttaa moduulitason tilan kutsujen valilla. Tietokantayhteyden avaaminen kasittelijan sisalla avaa sen joka kutsulla.
Lataa raskaat riippuvuudet dynaamisesti. Jos reitti tarvitsee kirjaston vain tietyssa haarassa, lataa se siella eika moduulin ylaosassa.
Pida vastausmuoto vakiona. Ei vaikuta suorituskykyyn, ratkaisee yllapidettavyyden kun funktioita on kymmenia.
Milloin monoliitti on silti oikea
Pienessa API:ssa, jossa reitteja on muutama ja riippuvuudet ovat samat, erottelu tuottaa monimutkaisuutta ilman hyotya.
Siirrettaessa olemassa olevaa sovellusta toimiva monoliitti on usein oikea ensimmainen askel — ja raskaimpien reittien erottaminen omiin funktioihinsa oikea toinen.
Mihin optimointi kannattaa kohdistaa
Kylmakaynnistykset ovat nykyisin alle 200 millisekuntia. Jos API vastaa 800 millisekunnissa kolmen perakkaisen tietokantakyselyn vuoksi, funktiorakenteen muuttaminen ei korjaa mitaan.
Mittaa ennen kuin jaat. Rakenne kannattaa korjata siksi, etta se on oikein — ei siksi, etta oletat sen olevan pullonkaula.
