Druid tunnetaan Drupal-kehittäjänä. Sitä me olemmekin. Useimmat projektimme voidaan sijoittaa Drupal-kategoriaan, kun sisällönhallintajärjestelmää tarvitaan. Drupal ei kuitenkaan aina ole oikea työkalu tehtävään. Kuten Dries Buytaert sanoi Wienissä järjestetyssä DrupalCon Vienna -tapahtumassa: "Drupal ei ole enää tarkoitettu yksinkertaisiin sivustoihin", eikä Drupal yleisesti ottaen sovi jokaiseen käyttötarkoitukseen. Se on kuitenkin erittäin hyvä vaihtoehto oikeanlaisissa projekteissa.

Olemme viime aikoina tehneet joitakin ei-Drupal-projekteja, joten nytpä kerron teille yhdestä sellaisesta. Tässä tapauksessa ei-Drupal kuitenkin tarkoittaa, että teknologiapaketti ei ollut meille aivan uusi, sillä tunnemme jo entuudestaan ohjelmointikielet (PHP ja JavaScript) hyvin.

Tarve  – say no more, say no more

Asiakkaallamme oli projektin alussa jokseenkin strukturoimaton tarve, sillä asiakkaan kohdemarkkina on suuren mullistuksen kourissa. Tämän kyseisen markkinan digitaalinen ympäristö on muutostilassa, ja – kuten aina – muutokseen on osattava sopeutua. Projektin alkaessa meillä oli tiedossa, että sovelluksen tulee olla mobiiliystävällinen ja sen päätoimintona tulisi olla käyttäjien välisen kommunikaation mahdollistaminen. Siitäpä sitten kehitysjonoa luomaan!

Mobiili? Ajattelimme, että PWA on oikea valinta. Me Druidilla olemme olleet PWA:n faneja jo hyvän tovin ja olemme kirjoittaneet kyseisestä hienosta konseptista ennenkin. Progressiiviset verkkosovellukset ovat tulevaisuutta, ja niissä on paljon potentiaalia. PWA on myös hyvä vaihtoehto silloin, kun sovelluksia halutaan jakaa ilman App Storea tai Play Kauppa -palvelua. Jotkin sisäiset työkalut voitaisiin toimittaa esimerkiksi intraneteistä. Kerron PWA:sta lisää tuonnempana. Joka tapauksessa ajattelimme, että PWA sopisi tarkoituksiimme erinomaisesti.

Kommunikaatio? Wink wink nudge nudge. Say no more, say no more. Tämä herätti ideoita tietorakenteista ja käyttöliittymästä.

Teknologiapaketti – And Now for Something Completely Different

Päätimme olla rohkeita ja kokeilla aivan uusia komponentteja uudessa projektissa – frontendissä, backendissä, tietokannassa ja infrastruktuurissa. Tokihan taustalla oli tietoa ja oppimista soveltuvuusselvitysten ja vastaavan kautta. Ja kuten sanoin, teknologia oli meille jo tuttua. Tai ainakin osalle tiimimme jäsenistä.

Jos aloitetaan ihan pohjalta, valitsimme Dockerin liimaksi, joka pitää komponentit ja ympäristöt kasassa. Luonnostelimme nopeasti Docker-osuudesta avoimen lähdekoodin version ja julkaisimme sen omana juttunaan nimellä Stonehenge. Stonehenge on usean projektin paikallinen kehitysympäristö ja työkalusetti Dockerissa. Projektissa käytetään Stonehengeä kehittäjän työkaluna homman pyörittämiseen. Koska paikallinen kehitysympäristö on melko yleinen ongelma kehittäjille, ajattelimme, että tästä voisi olla hyötyä muillekin. Sen vuoksi erottelimme tämän toiminnallisuuden projektista ja julkaisimme sen erillisenä työkaluna.

Pohjimmiltaan Stonehenge tarjoaa meille paikallisia URLeja ja välityspalvelimen käsittelemään liikenteen projekteissamme. Välityspalvelin tehtiin Traefikilla, joka on suoranainen tuulahdus raikasta ilmaa verrattuna aiempiin samaa tarkoitusta varten käytettyihin teknologioihin. Voin sanoa, että se toimii ja suoriutuu oikein mainiosti tuotantopuolellakin!

Projekti itsessään määrittelee sovelluksemme tarjoamat palvelut – perusjutut, kuten Nginxin, PHP:n, tietokannan ja komentorivin, sekä kaikkien niiden suhteet. Tähän käytämme Docker Composea.

 

Sovellukseksi itsekseen valitsimme Symfony 4:n backendiin ja Reactin frontendiin. Symfony periaatteessa luo standardin JSON-ohjelmointirajapinnan, jonka React-sovellus sitten käyttää. Yksi syy Symfonyn valintaan oli tietokantamme (mikä se voisi olla?) tukeminen Doctrinen kautta. Kun arvioimme eri kehikkoja backendiin (PHP), tutkimme muiden kehittäjien käyttökokemuksia, ja vaikutti siltä, että kenelläkään ei ollut pahaa sanottavaa Symfony 4:stä. Ja sen käyttö olikin todella mieluisaa. Joillakin meistä oli jo kokemusta Symfonystä, sillä Drupal 8 on rakennettu Symfony 3:n päälle. Siitä huolimatta meillä oli vielä paljon uusia asioita opittavaksi.

Tietokanta. MySQL, MariaDB, PostgreSQL vai jotakin muuta? Päädyimme valitsemaan MongoDB:n, jotta hyppymme tuntemattomaan olisi täydellinen. MongoDB on niin kutsuttu NoSQL-tietokanta, missä data tallennetaan objekteina rivien sijaan. Tämä on hyödyllistä sellaisen datan kanssa, joka voi olla rakenteeltaan hyvin erilaista (lue: dokumentissa voi olla dataa, jota muissa samaa tyyppiä olevissa dokumenteissa ei ole). Lisäksi skeemaa ei tarvitse määritellä etukäteen (ja päivittää), vaan se elää sen mukaan, kuinka käytät dokumentti-objekteja.

Reactista en itse osaa kirjoittaa kovinkaan paljoa, mutta kollegani Kristian on kirjoittanut alle pienen kertauksen sen käytöstä projektissamme. Varoituksen sana kuitenkin: Javascript-maailman riippuvuushelvetti ja valtaisa määrä samanlaisia mutta erilaisia työkaluja saattavat joskus tehdä kehittäjän elämästä ikävää.

Lainaus Kristianilta:

Oli aika mahtavaa päästä käyttämään Reactia isossa projektissa. Yleisesti ottaen React oli varsin mutkaton. Teimme toki joitain virheitä aikaisessa vaiheessa projektia, mikä pakotti tekemään refaktorointeja. Alkuperäinen suunnitelma oli renderöidä suurin osa sovelluksesta Twigillä, jolloin vain kommunikaatiopuoli olisi ollut Reactin alaisuudessa. Lopulta päädyimme siirtämään suurimman osan sovelluksesta Reactiin. Se tarkoittaa, että emme luoneet minkäänlaista reititysjärjestelmää emmekä suunnitelleet storen arkkitehtuuria. Onneksi refaktorointi onnistui melko tuskattomasti ongelmien ilmetessä. Minulle hauskin osa projektia oli MobX:n käyttäminen. Olen halunnut kokeilla sitä jo pitkän aikaa, joten olen tyytyväinen, että sain tilaisuuden käyttää sitä kaupallisessa sovelluksessa. MobX on pohjimmiltaan tilanhallintatyökalu, joka perustuu tarkkailijamalliin. Kaikki tarkkailijat, jotka seuraavat tarkkailtavaa muuttujaa, päivittyvät kuin taikaiskusta aina kun tarkkailtava arvo muuttuu. Jos voisin muuttaa yhden asian seuraavaa kertaa varten, käyttäisin varmaankin mieluummin MobX State Tree -kirjastoa, joka on kantaaottavampi versio MobX:stä. Se käyttäytyy Reduxmaisesti, mutta ilman Reduxin kuormaa.

Siinäs kuulitte.

Kun hyppäsimme PWA-remmiin, Reactin avulla loimme yhden sivun sovelluksen, joka auttaa joissain PWA:n puolissa. No mitä PWA sitten tekee? Sitä voi ajatella sovelluksena, joka on periaatteessa verkkosivu. Se tarkoittaa, että App Storea tai Play Kauppaa ei tarvita jakeluun. Sovellus päivittyy, kun verkkosovellus päivitetään. Siinä on muutamia ominaisuuksia, jotka tekevät kokemuksesta "sovellusmaisen": tiedon tallentaminen välimuistiin prosessin nopeuttamiseksi, standalone-tila (oman, ilman selainkomponentteja toimivan käyttöliittymän tekemiseen), pääsy joihinkin mobiiliohjelmointirajapintoihin sekä offline-toiminnot. Lisäksi on mahdollista käyttää Push-ilmoituksia, mutta ne toimivat vain Androidilla. Lisätietoa voi lukea 2018 State of Progressive Web Apps -artikkelista.

PWA on huvittavaa kyllä jotakin, mitä Apple visioi jo vuonna 2007 julkistaessaan alkuperäisen iPhonen. Google ajaa yhä vahvasti nykyistä hommaa, joten periaatteessa PWA toimii paremmin Android-luureilla.

Onni suosii rohkeaa, ja uskon vahvasti, että PWA on sovellusten tulevaisuus – ja se on erityisen hyödyllinen, kun luodaan työkaluja organisaatioille ja yrityksille.

Siinä oli teille melko pitkä avautuminen teknisistä jutuista. Eiköhän vedetä vähän henkeä tässä välissä.

"And now a film about a man with a tape recorder up his brother's nose."

GDPR-aspekti

Niin, se pahamainen GDPR. Tällä hetkellä meillä ei ole varsinaista käyttäjädataa, joten meillä ei ole hätää. Me suunnittelimme koko kehitystyön mallidatalla, mikä osoittautui hyvin hedelmälliseksi projektin aikana. Lisäsimme datafikstuureja, jotka täyttivät tietokantamme mallidatalla. Joten siinä mielessä noudatamme täysin GDPR:ää kehitystyötä tehdessämme. Emme tarvitse tuotantodataa.

Tästä oli myös odottamatonta hyötyä. Testatessa huomasimme pian, että kykenimme käyttämään tätä luotua dataa testeissämme. Aika siistiä, eikö? Todellakin!

"In this picture, there are 47 people. None of them can be seen."

Seuraavat vaiheet

Projekti on tällä hetkellä MVP-vaiheessa ja on siirtymässä "kenttätesteihin". Toivottavasti loppukäyttäjät pitävät siitä, mitä olemme tehneet. Testaukset toteutetaan kontrolloidusti pienissä ryhmissä. Se tarkoittaa, että käytämme määrättyä, generoitua dataa, joka sopii kullekin testiryhmälle. Lisäksi kontrolloimme MVP-vaiheen PWA-puolta. Tällä hetkellä se toimii parhaiten Androidilla, joten käytämme sitä alustana testeissämme.

"Now, what's to be done? Tell me sir, have you confused your cat recently?"

Kookospähkinästä

Olemme oppineet paljon! Tämä tarkoittaa, että opitut asiat vaikuttavat jo uusiin projekteihin ja jonkin verran myös tapoihin, joilla hoidamme vanhoja projekteja. Aiomme kopioida backend-kaman uuteen API-keskeiseen projektiin ja Docker-jutut ovat kehittyneet jo hyvinkin käytettävään muotoon. Lisäksi avoimen lähdekoodin projektin (Stonehenge) julkaiseminen oli plussaa!

Hienoin osa ainakin minulle on ollut kaiken tämän jakaminen yhä suuremmalla joukolle druideja, jolloin kaikkea opittua voidaan hyödyntää laajemmalla mittakaavalla.

"Wait a minute -- supposing two swallows carried it together?"

Kirjoittajasta

Marko Korhonen
CTO, The Ministry of Silly Walks
Druid.fi