Hyppää sisältöön

30.9.2019

Miten nykyaikainen alustapalvelu rakennetaan?

Kirjoittaja: Juuso Haikonen

Uber, AirBnB ja Resq… Siinä muutama alustapalvelu, joita käytämme jokapäiväisessä elämässämme. Kuluttajan näkökulmasta palvelut ovat yleensä ilmaisia ja helppokäyttöisiä. Menestyvät alustapalvelut jakavat yhden elintärkeän ominaisuuden: ne tuovat arvoa kaikille palvelun osapuolille. Ilman tätä ominaisuutta alustalla ei ole menestymismahdollisuuksia.

Päätimme purkaa erään alustapalvelun teknisen kehittämisen askeleet tähän postaukseen. Jotta ne, joilla vastaavanlainen idea polttelee takataskussa tai alustatalous muutoin aiheena kiinnostaa, saisivat konkreettista tietoa siitä, millaisia asioita ratkotaan käytännössä silloin, kun alustapalvelua rakennetaan.

Asiakkaan tarpeen ymmärtäminen

Mobiiliapplikaatio, Progressive Web Application eli tuttavammin PWA vai jotain muuta? Mikä ohjelmointikieli valitaan ja minkälainen backend rakennetaan? Liian usein arkkitehtuuri -tai teknologiavalintakeskusteluissa törmää siihen, että asioiden paremmuutta mitataan jollain muulla mittarilla kuin sillä, mikä on asiakkaalle ja hänen liiketoiminnalleen paras ratkaisu.

Tässä tapauksessa halusimme ymmärtää ja avata asiakkaan tavoitteet kertaalleen ennen projektin aloitusta. Siksi pidimme kick-off päivän, jossa loimme uimaradoille eri käyttäjäpersoonat ja loimme olemassa olevien vaatimusten pohjalta käyttäjätarinoita. Löysimme eri prioriteetteja vaatimuksille (joitain vaatimuksia tarvitsivat lähes kaikki käyttäjäpersoonat ja toisia taas harvemmat). Päivän jälkeen meillä olikin asiakkaan kanssa yhdessä tehty priorisoitu backlog. Vasta tämän jälkeen aloimme pohtimaan mahdollisia teknisiä ratkaisuja.

Teknologian valitseminen

Yksi selkeistä rajauksista tässä tapauksessa oli, että kyseisen alustapalvelun käyttö tulisi tapahtumaan ainoastaan mobiililaitteella. Meidän alustapalvelun perusidea kun perustuu nimenomaan siihen, että palvelun käyttämisessä hyödynnetään sijaintitietoa ja osa käyttäjistä liikkuu paikasta toiseen tuottaakseen palvelua alustan muille käyttäjille. Päädyimme kehittämään mobiiliapplikaation, koska palveluun oli keskeisenä osana tulossa muun muassa push-notifikaatiot, jotka projektin alkaessa 2018 marraskuussa eivät olleet PWA-maailmassa vielä tuettuina iOS-laitteilla.

Budjetin, aikataulun sekä vapaana käytettävissä olleen tiimin huomioiden, natiivi sovelluskehitys (iOS :lle sekä Androidille täysin oma koodipohja kahdella eri ohjelmointikielellä) ei ollut mahdollista, joten päädyimme tekemään applikaation React Native -frameworkilla. React Nativen avulla pystyimme kirjoittamaan mobiiliapplikaation business-logiikan kertaalleen JavaScript-ohjelmointikielellä ja julkaisemaan sen sekä iOS:in että Androidin kauppapaikkoihin. React Native kommunikoi natiivi-maailman kanssa asynkronisen sillan yli, mikä mahdollistaa tarvittaessa myös natiivikomponenttien toteuttamisen.

React Native, hyvät, pahat ja rumat

React Nativen kehitysnopeus tuli jälleen kerran todistettua, kun pääsimme demoamaan asiakkaalle toimivaa osaa applikaatiosta oikealla mobiililaitteella heti ensimmäisellä viikolla. Jos React-kirjasto on tuttu, koodin kirjoittaminen on kotoisan oloista alusta alkaen. HTML-elementtien sijaan käytetään vain valmiita React Native UI-komponentteja: <div> on <View> ja <p> on <Text>.  Nämä mappautuvat automaattisesti alustakohtaisiksi natiiveiksi komponenteiksi. Hot Reload ominaisuutta ei voi myöskään turhaan hehkuttaa liikaa. Käyttöliittymän rakentaminen on nopeaa muutosten näkyessä testilaitteissa ja/tai emulaattoreissa välittömästi koodimuutosten jälkeen.

React Native tosin iskee myös päin kasvoja nopeasti yhdellä fundamentaalisella puutteellaan. Se ei sisällä sisäänrakennettua navigointia. Projektin aloitushetkellä React Native -yhteisössä ei myöskään ollut vain yhtä oikeaa mallia, vaan kuten React maailmassa yleensäkin on tapana, vastuu jätetään kehittäjille. Me päädyimme Wixin toteuttamaan natiiviin navigointi-ratkaisuun, joka vaati konfigurointia niin Androidin kuin iOS :n puolelta.

React Nativen versiosta 0.60 eteenpäin moduulit ja kirjastot linkkautuvat pääosin automaattisesti, mutta kyseinen versio ei valitettavasti ollut meillä vielä sovelluksen elinkaaren alussa näköpiirissä. Vanhemmilla versioilla halutut kirjastot piti itse linkata, jotta JavaScript osasi keskustella natiivi-realmin kanssa. Helpoin keino tähän on käyttää React Nativen komentorivityökalua. Seuraava vaihtoehto iOS:llä on ottaa käyttöön riippuvuuksien hallintatyökalu nimeltään CocoaPods. Viimeisenä vaihtoehtona on manuaalinen linkkaus, jolla edellä mainittu Wixin navigaatio esimerkiksi saatiin meillä käyttöön.

Prosessi ei ollut täysin triviaali: ensin piti avata Xcode, etsiä node module -kansion syövereistä haluttu tiedosto ja lisätä se projektin kirjastoihin. Tämän jälkeen piti löytää rakennusvaiheista (build phase) paikka, jossa binäärejä linkattiin kirjastoihin. Jos tähdet olivat oikeassa asennossa ja kaikki bitit osuivat kohdilleen, Xcode linkkasi kirjaston oikein. Aina näin ei kuitenkaan ollut, jolloin tuttu “poista kaikki, tyhjennä välimuistit ja asenna kaikki uudestaan” yleensä riitti korjaamaan ongelman.

Toinen nopeasti esiin astuva huomio oli, että siinä missä iOS-puolella kehittäjäkokemus oli pääosin rivakkaa ja sulavaa, joutui Android-ympäristössä toisinaan ihmettelemään virheviestejä, jotka korjaantuivat automaattisesti vain uudelleen käynnistämällä sovelluksen. Android Studion kautta käynnistettävät virtuaaliset emulaattorit eli AVD:t tuntuivat myös hieman hitailta käyttää. Onneksi Genymotion tarjoaa sulavampia Android-emulaattoreita ja ainakin meidän tapauksessa vaihtaminen kannatti.

Lopuksi on vielä todettava, että React Native päivittyy koko ajan, ja sen ajan tasalla pitäminen ei aina ole helppoa. Breaking Changes on jotain mihin pitää vain tottua. Matkan varrella konflikteja eri pakettien ja niiden riippuvuuksien välille tulee vääjäämättä ja ne pitääkin vain hyväksyä osaksi kehitysprosessia.

Firebase: I got your back

React Nativella toteutettu käyttöliittymä tarvitsi vielä luotettavan, skaalautuvan ja nopean backend-toteutuksen. Googlen tarjoama Firebase tarjosi aikalailla kaiken, mitä tarvitsimme: tietokannan, pilvifunktiot, push-notifikaatiot ja analytiikan. Firebase-projektin käyttöönotto on suhteellisen suoraviivaista: luo uusi projekti ja valitse sille toiminta-alue. Tämän jälkeen voi ladata konfigurointitiedoston, jolla saat firebasen linkattua projektiin, meidän tapauksessamme React Native -mobiiliapplikaatioon.

Yksi huomioitava seikka mobiiliapplikaation toteutuksessa on, että sen päivittäminen eroaa täysin selainpohjaisesta ratkaisusta. Applikaation päivittäminen vaatii, että siitä rakennetaan uusi versio sekä iOS:ille että Androidille erikseen. Versiot lähetetään molempiin kauppapaikkoihin, odotetaan auditointi ja lopuksi vielä käyttäjien on itse päivitettävä applikaatio. Tästä syystä päädyimme tekemään kriittisiä toiminnallisuuksia firebasen pilvifunktioihin, joita pääsemme muokkaamaan käytännössä reaaliajassa. Tällä tavoin voimme välttää edellä mainitun päivitysrumban aina, kun siihen ei ole pakollista tarvetta. Lopuksi kannattaa varmistaa, että tietokannan security rules asetukset ovat oikein, sillä oletusarvoisesti firebase-tietokantasi on avoinna kaikille ja kaikelle.

Kaksin aina kaunihimpi: Testi ja julkaisuympäristöt

Viimeistään julkaisun kynnyksellä olisi syytä pohtia, miten tästä eteenpäin? Loppukäyttäjien saapuessa palveluun, ei heidän ympäristössään voi enää riehua vapaasti. Me teimme kaksi erillistä Firebase-projektia: testi- ja julkaisuympäristöt. Android- ja iOS-puolella voi konfiguroida applikaatiosta useampia versioita (flavor), jotka käyttävät eri Firebase-projektia. Meidän tapauksessa testiversio siis käyttää eri ympäristöä kuin missä loppukäyttäjät lymyävät. Näin voimme testata applikaation uusia ominaisuuksia häiritsemättä oikeita käyttäjiä.

Julkaisu

Uuden alustapalvelun julkaisu on hieno ja koskettava hetki. Jotta se menisi mutkattomasti, tässä muutamia tärkeitä asioita, jotka on syytä pitää mielessä. Ensiksi, on hyvä muistaa, että EU:n tietosuojasäännöt vaativat, että palvelusta löytyy ajan tasalla oleva tietosuojaseloste. Toiseksi palvelulle on syytä kirjoittaa käyttöehdot. Teknillisellä puolella Google vaatii että applikaatiosta löytyy sekä 32- että 64-bittiset versiot. Helpoin tapa tähän on buildata bundle-tiedosto, joka sisältää eri versiovaihtoehdot. Tämä vaatii kuitenkin sen, että sovelluksen keystore luovutetaan Googlelle ja kehittäjät käyttävät vain upload key:tä applikaation allekirjoitukseen. Lisäksi sekä Apple että Google tekevät sovellukselle sisäisen tarkistuksen, joka on läpäistävä, ennen kuin sovelluksen saa yleiseen jakoon.

Loppusanat

Vanha sanonta “Roomaa ei rakennettu päivässä” pätee yllättävän hyvin sovelluskehitykseen, etenkin alustapalvelun rakentamiseen. Unelmien, tavoitteiden ja haaveiden mittelöidessä Ubereita ja AirBnB kaltaisia jättejä vastaan, on syytä pitää mielessä, että kyseisten yritysten liikevaihdot pyörivät miljardeissa ja pelkästään sovelluskehittäjien määrä lasketaan tuhansissa. Jos käsissäsi ei ole vastaavia resursseja, on syytä pysähtyä miettimään liikeideasi aivan keskeisimmät vaatimukset ja toteuttaa ne ensin. Julkaisun ei pidä tarkoittaa, että sovellus on valmis vaan pikemminkin sitä, että nyt oikea työ voi vasta alkaa.

Kuvat: Tapio Haaja, Pavel Kasak ja Saulo Mohana

Tutustu ohjelmistokehityspalveluihimme!
Tule meille ohjelmistokehittäjäksi!


Lue seuraavaksi: